Rewrite & Weblogic, useful info and bugfix

Splash Forums Rewrite Users Rewrite & Weblogic, useful info and bugfix

This topic contains 9 replies, has 3 voices, and was last updated by  Lincoln Baxter III 2 years, 5 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #25826

    0swald
    Participant

    Hi, there is an interesting behavior of Weblogic regarding class scanning – Weblogic does not explode war’s /WEB-INF/classes/ “as-is”, it archives all the classes into a jar and places it in the /WEB-INF/lib/ somewhere in the domain folder structure. This leads to the following:

    1. You will need org.ocpsoft.rewrite.annotation.SCAN_LIB_DIRECTORY set to ‘true’ to get your classes scanned.
    2. But even with SCAN_LIB_DIRECTORY set, you will still get exceptions during deployment, because the Rewrite’s WebClassesFinder expects classes to be present in /WEB-INF/classes/. As one can not turn on SCAN_LIB_DIRECTORY with WebClassesFinder disabled, the deployment will end up with an IllegalArgumentException: “Unable to build path relative to ‘/WEB-INF/classes/’ from:”, followed by a long and crazy deployment path on the server.

    I’ve slightly modified WebClassesFinder.java so it could handle such situations, works fine both on the GF4 and WL12c, but it needs more intensive tests. The file is attached.

    PS: There is another approach, even more simple, few lines of code – a single initial check whether the /WEB-INF/classes/ resource is empty.

    • This topic was modified 2 years, 6 months ago by  0swald.
    #25829

    Hey 0swald,

    thanks for letting us know about this. This is really very weird behavior.

    Could you please explain what you changed WebClassesFinder? The file you attached has been reformatted, so it is very difficult to diff it to see what changed.

    Thanks

    Christian

    #25830

    0swald
    Participant

    Hi Christian,

    I’m afraid I wont be able to explain what I’ve changed)) I spent several hours understanding the code in vain, and finally decided to rewrite the recursion from scratch. I think there is a bug in calculating relative path, most probably because it’s always been doing with respect to /WEB-IN/classes/ folder. I just reproduced the recursion and left comments on code variables and their resulting values. As I said, it works correctly for both WL and GF, but definitely requires more thorough testing, involving other server platforms. I’d appreciate it very much if you (we) could solve this issue. Either by testing and implementing my source code or, and this’d be pure WL bugfix, by using your code with a simple preliminary check on /WEB-IN/classes/ right in the public void findClasses(ClassVisitor visitor) – empty or not, if empty then exit w/o recursion.

    Regards,
    Osw.

    #25831

    Just to understand the issue completely. You say that the content of /WEB-INF/classes is packaged into a JAR and put into /WEB-INF/lib by Weblogic? So do you think that annotation scanning would work if SCAN_LIB_DIRECTORY is active and the WebClassesFinder wouldn’t throw an exception and instead skip the entry if it doesn’t match the /WEB-INF/classes pattern?

    #25832

    0swald
    Participant

    No quite. Rewrite wont work at all if SCAN_LIB_DIRECTORY isn’t set to true, but, in addition to SCAN_LIB_DIRECTORY = true, the bug should be fixed, WebClassesFinder dies with an IllegalStateException when /WEB-INF/classes/ is empty.

    Now what WL does. It takes all the client classes, leaving /WEB-INF/classes/ completely empty, and packages them into the /WEB-INF/lib/_wl_cls_gen.jar, to be exact.
    Google says many frameworks are suffering from such behavior, but this is not the case with Rewrite – just make WebClassesFinder skip empty classes folder, let users know that SCAN_LIB_DIRECTORY should be activated for WL, and we’re all happy))

    #25835

    Hey Oswald,

    Does the file you attached contain the fix? What did you change? (Yes I could download and compare it, sorry!) Any chance we could get you to send a pull request against the rewrite github repo master branch? Should be fairly easy to test against all the servers at that point, since we have a good number of automated builds set up:

    https://travis-ci.org/ocpsoft/rewrite

    Cheers,
    Lincoln

    #25836

    Unfortunately we don’t have a Weblogic CI build available (It’s closed source,) so when we merge the change, if you could verify that the change fixes your problem, it would be much appreciated!

    #25837

    0swald
    Participant

    Hi Lincoln!
    Sure, I’ll reformat styling (braces), add more comments and send the pull request. You’ll see that the code is 100% the same when it comes to class handling, but with a different package recursion algorithm.

    We dont have a commercial WL CI either, we were just considering to migrate from buggy GF, so the Rewrie was tested as a part of migration tests against the evaluation version of WL – http://www.oracle.com/technetwork/middleware/weblogic/downloads/index.html And yes, there will no problem for me to test the Rewrite against it as many times as needed, I’m mostly worried about other server platforms – Tomcat, JBoss, etc which I’m not familiar with. Hope tests will be ok.

    Regards,
    Osw.

    #25838

    Awesome, thank you! What I’ll do is merge your PR, let the tests run on all servers, and then we’ll be able to review the results. I don’t expect any problems, but if we see them, we’ll know we need to make additional changes.

    Note that you can actually run the tests on other servers yourself using the following profiles:

    mvn clean install -PJBOSS_AS_MANAGED_7.X
    mvn clean install -PGLASSFISH_MANAGED_3.1
    mvn clean install -PTOMEE_MANAGED_1.5
    mvn clean install -PWILDFLY_MANAGED_8
    mvn clean install -PGLASSFISH_MANAGED_4.0

    The servers will automatically be downloaded, then started and stopped for each test. It’s a bit slower, but it works very reliably.

    #25852

    This patch has been merged and released as of 2.0.11.Final

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

Comments are closed.