[Curtis J Reinke]

I have the following scenario:

o We’ve created a jar of multiple EJBs (of various types) in a separate process outside of Eclipse and MyEclipse

o The output of this process is a jar that includes the necessary deployment descriptors and container extensions, i.e., atdEJB_raw.jar.

o We want to import that jar into our Enterprise Application workspace, and have it part of and deployed with that application.

o We’re using Weblogic 8.1 and we do this today with an Ant task that generates the necessary EJB components for the set of EJBs in the jar, i.e., Weblogic ejbc. The Ant target is as follows. This task creates a deployable EJB jar, i.e., atdEJB.jar from a a raw jar. The raw jar has the necessary classes and deployment descriptors, but does not contain the code generated by either ejbc or appc.

o Additionally, we may want to extract the contents of that jar (all class files and the deployment descriptors), change the deployment desriptors. Essentially, this is similar to using third party EJB jars, where you want to have the EJB(s) (provided in a jar) as part of your deployment, but want to change the deployment descriptors (both standard and extended) as necessary to meet your requirements.

Q: Do you have any suggestions as to how to go about doing this with MyEclipse? We could not find it in the documentation. We know we can do it with Ant, but we don’t get the automation we like with MyEclipse, i.e., build the EAR and Deploy. Also, if this is not currently something you provide, can we extend what you provide to do this? We’ll also need to do this with Websphere 5.1.2.

[Riyad Kalla]

I am researching this…

[Curtis J Reinke]

Sorry. I forgot to attach the Ant target to invoke appc. appc takes a “raw” jar, performs a generation of stubs and skeletons necessary for client/server communication, and re-jars the complete package for deployment and use.

<target
name=”compileejb” >

<exec
dir=”${build.dir}”
executable=”${build.fflib.dir}/sun/j2se/jdk/bin/java”
failonerror=”yes”>

<arg
line=”-classpath ${ejbc.classpath} weblogic.ejbc -d ${build.fflib.dir}/atd/frameworks/atdEJB.jar ${build.fflib.dir}/atd/frameworks/atdEJB_raw${debug.label}.jar” />
</exec>

</target>

I’ve also attached an Ant for making the “raw” jar.

<target
name=”makeejb”>

<mkdir
dir=”${build.dir}/META-INF” />

<copy
overwrite=”yes”
preservelastmodified=”yes”
todir=”${build.dir}/META-INF”>

<fileset
dir=”${build.dir}/misc/deploymentDescriptors”
includes=”*.xml” />
</copy>

<copy
overwrite=”yes”
preservelastmodified=”yes”
file=”${build.dir}/META-INF/atd-ejb-jar.xml”
tofile=”${build.dir}/META-INF/ejb-jar.xml” />

<copy
overwrite=”yes”
preservelastmodified=”yes”
file=”${build.dir}/META-INF/atd-weblogic-ejb-jar.xml”
tofile=”${build.dir}/META-INF/weblogic-ejb-jar.xml” />

<jar
jarfile=”${build.fflib.dir}/atd/frameworks/atdEJB_raw${debug.label}.jar”
manifest=”${build.dir}/manifest”>

<fileset
dir=”${build.dir}/build/dependencies”
includes=”VersionDump.class” />

<fileset
dir=”${build.dir}”
includes=”META-INF/ejb-jar.xml, META-INF/weblogic-ejb-jar.xml, *.txt” />

<fileset
dir=”${build.dir}/classes”
includesfile=”${build.dir}/build/dependencies/ejblist.txt” />
</jar>

</target>

[Riyad Kalla]

Sorry for the delay (I got your PM), I was waiting for a reply from another person I contacted about this, but I think this should work:
Since these 3-rd party EJBs are already in binary form and won’t change you can place them in the root of a top-level Enterprise Project and they will automatically be packaged and deployed when you deploy the EAR.

Now your original post mentioned processing a “Raw” EJB into a “Deployable” EJB, MyEclipse cannot assist or be part of that process, so the best idea I can think of is make a plain Java project that contains your EJB code and processing script and always take the output EJB and dump it in the EAP so it is deployed… this should work.

Does this fit your use case?

[Curtis J Reinke]

Using MyEclipse for J2EE Development

This is a continuation of the thread. We tried what you suggested, but this approached was not enough. Hopefully, the following is a better explanation of what we had and need to do.

One of the main reasons we are considering using MyEclipse is for corporate J2EE development with WebLogic 8. We had planned to roll this out to ~ 200 developers over time and are trying to get the process down. Whereas we like many of the MyEclipse features, we’re finding it not to be as seamless as we’d like in terms of hot deployment and EAR building/deploying. The following is what we needed to do to make MyEclipse build and deploy in our environment as well as a discussion on what we’d like to see happen.

· To work around the following, we needed to build separate Eclipse Java projects and custom Ant scripts to build the necessary classes and jars and move those classes and jars to the appropriate location in the EAR. These scripts are fairly trivial in nature and appeared to be the simplest way for us to meet our basic EAR requirement for deployment with WebLogic 8.

In these Ant scripts, we took advantage of a WebLogic specific extension for class loading, where the EAR class loader uses classes and libraries placed in the EAR’s APP-INF/classes and APP-INF/lib directories respectively when loading a class. The sequence of events (the standard class loading scenario) is as follows:

o The WAR Loader tries to load a class and it is not in cache
o The WAR Loader asks his parent, the EAR Loader, if it is in cache and it isn’t
o The EAR Loader asks his parent, the System Loader, if it is in its cache and it isn’t and so on up the
parent chain until there is no parent
o When there are no parents in the chain, the top loader, tries to load the class using classes and libraries
in its classpath
o If the top loader cannot load the class it calls upon the next child to load the class and if still not found,
its child and so on until there are no more children in the chain
o So, for this example, the System Loader determine if the class is in it’s classpath and if not asks its child
loader, the EAR Loader to load the class
o With WebLogic, their EAR Loader now searches classes and libraries in APP-INF/classes and APP-INF/lib
respectively, before moving down to the WAR loader that also loads it classes from WAR specific
locations

The reason WebLogic provides this feature is to eliminate the need to modify various manifest files in all the jars that are part of the project to include each other. There doesn’t appear to be any tool support in MyEclipse and we’ve toyed with modifying various manifests by hand, but have come to the conclusion that this is problematic without tool support.

In the prototype we constructed we needed the following:

o APP-INF/classes
· Various classes that overwrote classes in APP-INF/lib jars
· Properties (placed in a properties.jar) that were loaded as streams

o APP-INF/lib
· Utility jars
· Resource bundles

o Base of EAR
· Third party EJB’s with deployment descriptors modified as necessary for the EAR

In our environment, we have developed custom frameworks and services, either as libraries or as third party EJBs that are used by multiple applications. It is difficult to go into all the details of the various frameworks and services, but suffice it to say that these frameworks and services are used in each EAR and most need access to the classes, libraries, and third party jars listed above. I can pass along a workplace containing the prototype that provides more detail.

What we’d like to be able to do is make the process more seamless, whereby, we can “add custom builders” onto your standard EAR builder that could support some of our customized requirements. The only thing we currently see is the ability to associate other Java project with an EAR, where the EAR builder builds a jar from the output directory of the Java project and places that jar in the base of the EAR. This will not solve our problem.

· The second problem we run into has to do with deploying Exploded EARs. Whereas MyEclipse appears to
build and deploy the exploded EAR correctly, WebLogic gives us the weird error of: [J2EE:160034]Module
atdEJB not Found in path C:\bea\user_projects\domains\cookBookDomain\applications\cookbook when
we try to deploy it. It is still unclear why the when changing this from a packaged to an exploded
deployment (with no other changes) that this is happening. We are thinking this is a WebLogic problem
and are looking into this from that standpoint. However, if you have any insight we’d appreciate what
you might have.

The thing is, it looks like we need to do exploded EARs for hot deployment. When attempting to
change/save various WAR classes, we get hot deploy errors and are forced to rebuild and redeploy the
EAR. This leads to making the develop/test/develop/test iterative cycle less productive.

[Scott Anderson]

The reason WebLogic provides this feature is to eliminate the need to modify various manifest files in all the jars that are part of the project to include each other. There doesn’t appear to be any tool support in MyEclipse and we’ve toyed with modifying various manifests by hand, but have come to the conclusion that this is problematic without tool support.

Actually, we have tool support to regenerate all the manifests for your dependent project for you. You can read about it in our Enterprise Project Quickstart, from the documentation section, here:
http://myeclipseide.com/enterpriseworkbench/help/index.jsp?topic=/com.genuitec.myeclipse.doc/html/quickstarts/earprojects/index.html
Please scroll down and read just under Figure 30.

APP-INF/lib

Please note that any libraries in APP-INF/lib will also be deployed automatically by our deployment tooling. However, any solution that uses these custom extensions that WLS provides will naturally not work on WebSphere, as you desired.

What we’d like to be able to do is make the process more seamless, whereby, we can “add custom builders” onto your standard EAR builder that could support some of our customized requirements.

Actually, if you’d like to do that all you really need to write is custom Java project builders like we do. We’ll deploy whatever is in the project at deployment time, but it’s the Java builders that get it into the deployable state and they’ll run first.

The second problem we run into has to do with deploying Exploded EARs. Whereas MyEclipse appears to
build and deploy the exploded EAR correctly, WebLogic gives us the weird error of: [J2EE:160034]Module
atdEJB not Found in path C:\bea\user_projects\domains\cookBookDomain\applications\cookbook when
we try to deploy it.

I’d verify that your application.xml is correct, and see if the problem persists after a complete weblogic shutdown and restart, versus just aftet a hot exploded deployment. If changing deployment types (packaged to exploded) WLS might be locking a jar or something.

The thing is, it looks like we need to do exploded EARs for hot deployment.

That is correct.

When attempting to
change/save various WAR classes, we get hot deploy errors and are forced to rebuild and redeploy the
EAR.

That can occur because not every java change is legal for hot redeployment, based on the JPDA Spec (http://java.sun.com/j2se/1.4.2/docs/guide/jpda/) Basically, no changes that alter the “shape” of a class are permitted. That is, you can’t add/remove methods, member variables, etc. This is likely what you’re running into and there isn’t anything we can do since it’s controlled by the specification and the JDK and Eclipse implementation of it.

[Dylan O’Mahony]

I’m struggling with largely the same problem. Specifically I want to layout my source-code per the BEA recommendations outlined here: http://e-docs.bea.com/wls/docs81/programming/environment.html#IntroducingtheSplitDevelopmentDirectoryStructure. Most importantly, I want to just place my 3rd-party JARs into a APP-INF/lib directory where they will be picked up by WebLogic Server automatically and I don’t need to play around with any/multiple MANIFEST.MF files (I’m trying to keep the development process as simple as possible for my team).

If I follow the recommendations from this thread and in the My Eclipse Enterprise Application tutorial, however, and just create APP-INF as a standard Java project:

1. I end up with all of my 3rd-party JARs in the root of the exploded EAR and WLS will not recognize these – the only way around this is the MANIFEST.MF entries which I want to avoid

2. A new JAR called app-inf.jar is added to the root of the EAR. This I don’t want.

I guess my question is based on this quote:

Please note that any libraries in APP-INF/lib will also be deployed automatically by our deployment tooling. However, any solution that uses these custom extensions that WLS provides will naturally not work on WebSphere, as you desired.

While this is true, the libraries/JARs appear in the root of the EAR and APP-INF is not created as a directory in the EAR when I set it up as a standard Java project, per the recommendations. Is there any way to override the default behaviour and just have APP-INF be copied as-is to the deployment directory?

To illustrate, I want c:\bea\user_projects\domains\MyDomain\applications to contain a myEar directory, which in turn contains:

/APP-INF/lib
/Web1
/Web2
/EJB1

Is this possible using My Eclipse? Thanks in advance…

[Scott Anderson]

If I follow the recommendations from this thread and in the My Eclipse Enterprise Application tutorial, however, and just create APP-INF as a standard Java project:

Don’t do that. Simply create the APP-INF/lib folders as plain folders in your enterprise project and place the external jars into it.
They’ll be packaged automatically.

To illustrate, I want c:\bea\user_projects\domains\MyDomain\applications to contain a myEar directory, which in turn contains:

Pretty much. Create you EJB1, Web1, and Web2 projects as standard MyEclipse EJB and Web projects, respectively. Then, creatd an Enerprise project, called whatever you like, and reference the existing projects (rather than creating new ones) in the Enterprise project creation wizard. Once it’s been created, add APP-INF/lib as described above and place your jars within it in your Enterprise Project.

[Dylan O’Mahony]

This worked perfectly, thanks for the quick reply.

The APP-INF/lib JARs were placed exactly where I wanted them. Also, by copying the WLS app DD (weblogic-application.xml) to the META-INF source folder in my EAR project, this also got deployed correctly and was picked up by Weblogic.

Did I miss this in the documentation, or is this just a really useful side-effect? In either case, it might be worth calling it out in your EAR tutorial – it’s an absolute life-saver!

Thanks again…

[Scott Anderson]

Glad that sorted it out for you. You’re right about updating the tutorial. In the interim I’ve marked this thread “sticky” so it will hang
around and be easier for others to find.

[Author]

Posts