wood burning stoves 2.0*
The moose likes Websphere and the fly likes Third party libraries and WSAD 5.1.0 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Products » Websphere
Bookmark "Third party libraries and WSAD 5.1.0" Watch "Third party libraries and WSAD 5.1.0" New topic
Author

Third party libraries and WSAD 5.1.0

Sean Sullivan
Ranch Hand

Joined: Sep 09, 2001
Posts: 427
I am using Log4j 1.2.8 and WSAD 5.1.0
Log4j provides a pre-built jar: log4j-1.2.8.jar
What is the best approach for integrating this pre-built
JAR in WSAD?
Option 1:
=========
Create a Java project called "Log4j"
Use "Import ---> Filesystem" to import the JAR into the
project.
Web projects that need Log4j will reference the Log4j
project.
Option 2:
=========
Create a Java project called "Log4j"
Use "Import ---> Zip file" to import the JAR into the
project.
Log4j's class files will sit inside the Log4j project.
Web projects that need Log4j will reference the Log4j
project.
Option 3
========
Workspace --> Java --> Classpath Variables
Declare a Classpath Variable called MYCORP_LOG4J
Projects that need Log4j can reference the Classpath Variable.
Option 4
========
For each Web project, drop a copy of log4j-1.2.8.jar
in the WEB-INF/lib directory.

What is the best approach?
Howard Kushner
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 361
Hi Sean,
I personally like option 3 myself.
Regards,


Howard Kushner<br />IBM Certified Enterprise Developer - WebSphere Studio Application Developer V5.0<br />IBM Certified Advanced System Administrator - WebSphere Application Server V5.0<br />IBM Certified Solution Developer - Web Services with WebSphere Studio V5.1<br /><a href="http://www.amazon.com/exec/obidos/tg/detail/-/1931182108/" target="_blank" rel="nofollow">Developing J2EE Applications with WebSphere Studio</a> my Certification Study Guide for IBM Test 287
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30764
    
156

I think options three and four are best. Since the code is distributed as a jar, it is best to leave it as a jar.
I like option four better than option three because different projects in the workspace may choose to upgrade the library at different times.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Jeanne has given good advice. Option 4 is the best option in my opinion. The issue with option 3 is that while it solves your problem at build time, it doesn't solve the runtime problem, nor does it solve the issue of what happens when you deploy your app onto WebSphere.
However, I may make one suggestion. If you are using EJB-JARs and WARs together in the same EAR, then put log4j in the root of the EAR and make sure it's on the classpath of the WARs and JARs rather than putting it in each individual EJB-JAR and WAR file.
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Sean Sullivan
Ranch Hand

Joined: Sep 09, 2001
Posts: 427
Let me add the following:
We have multiple projects in WSAD.
1) Java projects (standalone Java libraries)
2) Web application projects (WAR's)
3) Enterprise application projects (EAR's)
We want to be able to use Log4j in our Java projects (#1) as well
as in the Web application projects (#2).
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30764
    
156

Sean,
You can still use the technique in option 4. WARs and EARs word as Kyle described. For java projects, you probably want to have a copy of the jar within the project (like in a lib directory) so the library can be distributed separately.
Sean Sullivan
Ranch Hand

Joined: Sep 09, 2001
Posts: 427
I received an email reply from Tim deBoer (an IBM employee):
> Since you won't be making changes to the log4j jar, there's no point in
> creating a separate Java utility project. So, don't use 1 or 2.
>
> Option 3 only handles build time. You'd have to add the jar to the
> server's
> classpath as well to make it work at runtime, so I'd leave this one out
> too.
>
> Option 4 is the most clean and self contained, but as you said it will
> require a separate copy of log4j in each Web module. If you only have a
> few
> Web modules that use it, or they are in separate EARs, I would still take
> this path. If you have many Web modules, but they are in the same EAR, you
> can put the jar into the EAR project instead. Then you'll need to use
> "Edit
> Module Dependancies" on each of the Web modules that need to make use of
> log4j. This will add it to the Java build path of the Web modules (build
> time) and to the manifest file of the Web module (runtime classpath). This
> cuts down on the number of copies of log4j, but still keeps it
> self-contained within the EAR and makes it easy to deploy your
> application.
>
> Thanks,
> Tim deBoer
> WebSphere Tools - IBM Canada Ltd.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Sean Sullivan:
I received an email reply from Tim deBoer (an IBM employee):

And that makes me what, chopped liver?
Glad (but hardly surprised) that Tim agrees with me, though...
Kyle
Sean Sullivan
Ranch Hand

Joined: Sep 09, 2001
Posts: 427
I am using Websphere Studio Application Developer 5.1.0
Consider this scenario:
Project 1 is a Java project that contains a package called
com.mycorp.util
Project 2 is an Enterprise Application Project.
Project 3 is a Web Application Project. This Web project
is associated with Project #2.
Project 4 is an Enterprise Application Project.
Project 5 is a Web Application Project. This Web project
is associated with Project #4.
Project #1 is dependent upon two 3rd party libraries: foo.jar and bar.jar
Project #3 is dependent upon Project #1.
Project #5 is dependent upon Project #1.
I want to configure my workspace such that:
1) there is only 1 physical copy of foo.jar
2) there is only 1 physical copy of bar.jar
3) foo.jar is included in the Java build path
4) bar.jar is included in the Java build path
5) foo.jar and bar.jar is included in the WEB-INF/lib folder of
both Web applications
6) When use WSAD's EAR Export feature, I want to
the the exported EAR to have foo.jar and bar.jar
embedded inside the WAR's WEB-INF/lib directory
My development environment is slightly more complex than what
is described here. My environment has 7 EAR's and 10 third
party libraries. I prefer a solution where I don't have to
create multiple physical copies of the JAR's.
Given these constraints, what is the best way to setup my projects?
-Sean
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30764
    
156

Sean,
You cannot setup a workspace given those constraints. Numbers 1 and 2 directly contradict numbers 5 and 6.
Given the advice above, why do you want to have only one physical copy of the jar files? It makes sense to give each EAR its own copy.
Sean Sullivan
Ranch Hand

Joined: Sep 09, 2001
Posts: 427
1) I want the WSAD workspace to have only 1 physical copy
of foo.jar and bar.jar
2) When I export an EAR, I want WSAD to automatically store a
copy of the jars in the exported EAR.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30764
    
156

Sean,
1) I want the WSAD workspace to have only 1 physical copy
of foo.jar and bar.jar

Why do you want it this way? I am asking because it is not the default way of accomplishing things. It's good for each ear to be able to stand alone. Therefore, it is useful for each ear to have it's own copy.
It sounds like you want shortcuts to the jars so it looks like you have multiple jars without actually having multiple jars. WSAD does not support this as it is file based.
Sean Sullivan
Ranch Hand

Joined: Sep 09, 2001
Posts: 427
I have 7 EAR's and 11 third party libraries. I would like for WSAD
to automatically managed these 11 JAR's for me. I don't want to create
7 copies of each JAR in my workspace.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30764
    
156

Sean,
I have around that many jars. It's not such a big deal to make the copies. And there are many benefits (as enumerated above.) WSAD does not automatically manage third party jars. Maybe there is an Eclipse plugin that does that, but it's not in WSAD. And I still think that I wouldn't want it to be.
 
Consider Paul's rocket mass heater.
 
subject: Third party libraries and WSAD 5.1.0