Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Third party libraries and WSAD 5.1.0

 
Sean Sullivan
Ranch Hand
Posts: 427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 361
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sean,
I personally like option 3 myself.
Regards,
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34095
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Sean Sullivan
Ranch Hand
Posts: 427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 34095
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 34095
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 34095
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 34095
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic