J2EE packaging issues


General J2EE: J2EE packaging issues

  1. J2EE packaging issues (5 messages)

    We are currently working on a J2EE application, business logic being archived as jar and web-application archived as war files.

    This structure looks fine, till we try and include a custom utility classes which needs to work along with the business logic as well as with the web-application. As J2EE does not clearly defines a proper place for this utility package, we have to package it along with the war file. This is clearly a disadvantage for us, as the classpath has to be modified to call these utility classes seperately.

    Also, structurally, web-archive classloader is a child of application classloader and not vice versa. Hence jars deployed inside the lib folder of web-archive are not visible to application. Therefore, this causes a major confusion and classpaths issues.

    Our Suggestion: Can we have a lib folder at the application level similar to the lib folder under webapp so that, anyone can include their custom libraries at the application level and it will be automatically visible to entire ear, therefore no classpath changes are required.

    Anyone, facing similar issues??

    Threaded Messages (5)

  2. J2EE packaging issues[ Go to top ]

    I guess it may depend on what application server you are using. If you want a jar to be global it is usually possible to start the server with the jar in its classpath. (At least with weblogic - I dont see why it shouldnt be possible for any server.) Find the script that starts the server and add something like
    export CLASSPATH=$CLASSPATH:somelibrary.jar for a Unixbased system.
  3. J2EE packaging issues[ Go to top ]

    I think the best option would be to put add a manifest entry for the utility jar file. This manifest file entry can be put in manifest file of the war file or the ejbs. This way the utilities can be shared across both the web classloader and application classloader. I mean the utilities will be loaded as part of the application classloader (parent of the web classloader).
    EAR should be self contained, hence I would put util.jar inside the ear and not in the system classpath. This 'manifest entry' approach is much more flexible.
  4. J2EE packaging issues[ Go to top ]

    In WebLogic 8.1 (7.0 too? I'm not sure), putting your shared
    jars and classes in APP-INF makes to globably available to the entire

    So the structure would look like

  5. J2EE packaging issues[ Go to top ]

    This seems to be an ideal solution for this nature of problems. But, this makes web application, application server specific. I guess only Weblogic 8 support this feature of creating APP-INF apart from WEB-INF.

    We looked into the J2EE 1.4 specs, but there also this has not been addressed. We hope J2EE specs committee do look into this issue and incorporate this solution.

    Other traditional solution, which other people also suggested are modifying application deployment classpaths or modifying INF files. These solution does not make your application portable across other application servers and deployments scenarios.
  6. Isnt it good enough? if so why not, I haven't seen comments on this