Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: problems with Acegi and WebSphere 6.1

  1. #1

    Default problems with Acegi and WebSphere 6.1

    I've just run into a problem with a Spring/Acegi web app, trying to run it on a WebSphere 6.1.0.5 server. Basically, it appears that WebSphere v6.1.0.5 (and at least v.6.1.0.3) has a bug that generates a 404 error instead of invoking filters on URI requests that aren't actually present in the web app.

    This means that /myapp/j_acegi_security_check returns a 404 instead invoking ANY of the filters for the app (including ones with URI patterns like /*). So Acegi doesn't appear to function with 6.1.0.3/5, which are the versions that I've actually tried.

    This issue is similar to IBM bug PK27620, http://www-1.ibm.com/support/docview...id=swg1PK27620, which describes the same filter issue, only specifically with JSP resources. That bug is supposed to have been fixed in v6.1.0.3.

    It looks like the issue I describe is a variant of that problem. I have submitted a problem report to IBM.

    Has anybody found a workaround to get Acegi working?

    I'm using Acegi 1.0.2/3.

  2. #2

    Default solved

    I got a response from IBM. They ackowledge this problem and gave me a work-around.
    One of our level 2 technicians stated this about the apar...
    "APAR PK27620 changed a lot of the code dealing with filters. We had to
    add a property in our methods to keep certain functionality. While
    fixing some problems it(the apar) has changed the behaviour of certain
    filter functionality. So we had to add a new custom property for
    6.1.0.3+"

    The custom property he is talkin about is;
    com.ibm.ws.webcontainer.invokefilterscompatibility

    The com.ibm.ws.webcontainer.invokefilterscompatibility should be set to
    true
    through Application Servers -> <server> -> Web Container Settings -> Web
    Container -> Custom Properties. Once set, you don't need to remove this
    custom property even if you upgrade the WAS.
    I tried this and it appears to work for me. Here's a similar issue: http://www-1.ibm.com/support/docview...=utf-8&lang=en

    Note, that I have some other apps using Acegi 1.0.2 on WebSphere 6.1.0.3 and they weren't having this issue, so it's not a consistent problem.

  3. #3
    Join Date
    Dec 2006
    Posts
    24

    Default

    I am having the same issue. But the fix doesn't seem to work. It worked once, but then when I tried it on a different machine it didn't work. You mentioned that the issue occurs randomly, any idea why that happens?

    My env is WAS 6.1 with fix pack 6.1.0.3. I added the custom property as well.

  4. #4
    Join Date
    Dec 2006
    Posts
    24

    Default

    Quote Originally Posted by pea1 View Post
    I got a response from IBM. They ackowledge this problem and gave me a work-around.


    I tried this and it appears to work for me. Here's a similar issue: http://www-1.ibm.com/support/docview...=utf-8&lang=en

    Note, that I have some other apps using Acegi 1.0.2 on WebSphere 6.1.0.3 and they weren't having this issue, so it's not a consistent problem.
    There are a lot of fixes available. I installed the 32-bit x86 AMD/Intel AppServer fix. Do I need to install any other?

  5. #5

    Default

    Sorry, all I know is that the fix worked for an Acegi app that previously wasn't working on 6.1.0.3. The mystery to me is that I have other apps running in the same WebSphere cell on the same hardware, but on a different app server instance, that were useing Acegi just fine without the fix.

  6. #6
    Join Date
    Dec 2006
    Posts
    24

    Default

    There were a lot of fixes for the AppServer, Client, HttpServer etc... I used the Appserver fix. is that right? Do I need to install the latest fix as well.

    I might as well get a lottery.

  7. #7

    Default

    All I did was install 6.1.0.3 on the app server and set the custom property. No other fixes were involved.

  8. #8
    Join Date
    Dec 2006
    Posts
    24

    Default

    Tried the same and did not work....

    Anyways, thanks for the responses.

  9. #9

    Talking Fixed

    Hi guys, I had this problem, and now it's fixed. Had to set the com.ibm.ws.webcontainer.invokefilterscompatibility to get the Struts2 and Sitemesh filters to work with 6.1.0.5.

    Thanks heaps for your input!!

    More details here:
    http://www.nabble.com/forum/ViewPost...31115&framed=y

  10. #10
    Join Date
    Nov 2006
    Location
    Belgium
    Posts
    15

    Default what about j_acegi_logout?

    Seems like the fix only works fine for the login part.

    When using Acegi's LogoutFilter (mapped on /j_acegi_logout) it seems that WAS v6.1 calls the logouthandlers set in the logout filter get called twice. As such the session is recreated, and for some other reason the delete of the remember-me cookie gets lost somewhere due to WASv6.1 not handling filter logic as should.

    On WASv6.0, Tomcat4 and Tomcat5.4 the logout works fine.

    Did someone manage to write acegi logout code that actually works on Websphere v6.1?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •