- This topic has 23 replies, 7 voices, and was last updated 20 years, 8 months ago by
.
-
Posts
-
@support-scott wrote:
The business tier has business logic in a variety of EJB’s, a DAO layer, all that good stuff.
Sorry for the confusion. Just to be clear, the above is traditionally referred to as a three-tier app.
Doh! Sorry, I knew that….
To go through the trouble of actually dividing up the souce tree into three projects is an unnecessary pain. We don’t care to go through the trouble, as we gain nothing by doing so. We want to know how YOU guys recommend we do it in MyEclipse.
Actually, it is required by the Eclipse (not MyEclipse) project structure so that the projects’ classpath and class loading structure can exactly mirror what you’ll see at runtime.
That’ what we have. We have a single source tree that compiles to a single build folder, and the entire thing gets deployed to both web and ejb containers. True, we get some unused servlets in the ejb classpath and some unused ejb’s in the servlet container classpath, but nobody cares to go through the trouble of filtering out or divvying up because……. nobody gains jack by going through the exercise.
With everything under one project, you could easily create an application that compiled correctly but wouldn’t run when deployed because the classloading characteristics would be different.
Haven’t encountered that problem. I guess our apps are very simple, or something. I will need to do some research to figure out how a couple of unused servlets in my weblogic classpath can screw up its classloading process. I have always felt that, since classloading is more or less documented, we have some control over it.
-
1)Take all your library jars and add them to the root level of your EAR project using the Navigator View.
2) For each web or EJB project that needs these libraries
a) Use Properties > Java Build Path > Add Jar… to add each required jar from the EAR project. This allows development-time visibility
b) Modify the Class-Path entry in the project’s MANIFEST.MF file to point to the same jars. This will allow them to be loaded when the application is deployed.
3) Turn off “Smart Deployment” for the web projects since you’ve handled the libraries manually by the above. The ‘Smart Deployment’ feature is really intended to facilite the packaging of two-tier applications only. With common code shared by an EJB layer, it’s really not appropriate.We don’t use ears. We don’t have an “application” style deployment on weblogic, just an “ejb” deployment. And our web servlet is deployed to tomcat. Dev mirrors prod exactly, class for class, jar for jar.
I will study your suggestion. It sounds reasonable. May I ask if there are any plans to
(1) allow web projects to deploy their User Libraries in addition to external jars? I don’t see any technical reason for not allowing this.
(2) allow “clone” or “create new” under the appserver preferences, so that we can switch between several domains easily, for instance?
We don’t use ears. We don’t have an “application” style deployment on weblogic, just an “ejb” deployment.
And our web servlet is deployed to tomcat. Dev mirrors prod exactly, class for class, jar for jar.Ah! Ok. Then I’d simply do what I suggested in the second part of my last post here:
As an alternative, forgetting about the above and simply placing all the common Jars at the top level of the EJB project and common source code in the EJB project itself…..
May I ask if there are any plans to
(1) allow web projects to deploy their User Libraries in addition to external jars? I don’t see any technical reason for not allowing this.The main reason we didn’t do it already is that they are so new to Eclipse 3.0. I’ve added an enhancement request for it.
(2) allow “clone” or “create new” under the appserver preferences, so that we can switch between several domains easily, for instance?
That one is a recently entered enhancement request also, so I added this thread as a +1 for it.
It strikes me that all the information is available for MyEclipse to automatically add Class-Path: attributes to the MANIFEST.MF for EJB projects using dependency libraries from other projects, in the manner described by Scott above. I have just run into the same problem, having switched from Lomboz to MyEclipse. I have a pretty standard scenario of common / utility projects / jars used in a number of unrelated application projects, and therefore cannot / should not be merged, and I have to go down this road of hand editing manifests, and remembering to manually rebuild / copy jars around all over the show. Of course I can create my own ant buildfiles to do this, but everything else is integrated into eclipse and MyEclipse, I think the Class-Path: way of handling dependency packages is standard enough that it could be also.
Brett Connor
Brett,
Good suggestion, I’ll send it along and see waht the team thinks (there may be some confusing use cases that keep us from just ‘slapping this in’)Brett,
It seems that changes like this are going to be addressed slowly as we make the flexible project structure more robust and feature complete. I don’t have an ETA for this but its on our radar.We appreciate your suggestion.
I found a surprisingly simple solution to this problem. I know I am not stating anything new here but here are the steps anyway.
1.Create a ANT script as given below. It is really simple.
Save it in the workspace, I put mine in a build directory that is parallel to the src directory.
2. Right click on your utility project and click on properties.
3. Click on Builders then on New.
4. Choose ANT Build , click OK
5. In the really elaborate dialog box give the builder a name such as jar_builder
6. Click on Build Options(You may have to scroll to the right)
7. Below the Run the builder there are check boxes. Select During Auto builds.
8. Apply and OK.
9. Now every time you change any class auto build will run and so will the jar_builder!
10. Add the reference to this file in your ejb/war manifest file.
11. Post here if you are (un)succesful.
Santosh
Contents of the build.xml
<project default=”jar” name=”utility-jar” >
<property name=”ear-location” value=”../../application-ear”/>
<property name=”root” value=”..”/>
<target name=”jar” depends=”clean_jar”>
<jar destfile=”${ear-location}/utility.jar”
basedir=”${root}”/>
</target>
<target name=”clean_jar”>
<delete file=”${ear-location}/utility.jar”/>
</target>
</project>
