I am using Log4j 1.2.8 and Websphere Studio Application Developer 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?
Thanks in advance,
-
Websphere Studio 5.1.0 and third party libraries (11 messages)
- Posted by: Sean Sullivan
- Posted on: February 20 2004 16:35 EST
Threaded Messages (11)
- Websphere Studio 5.1.0 and third party libraries by Paul Strack on February 20 2004 20:13 EST
- There is another option by Colin Williams on February 21 2004 16:17 EST
- Unable to deploy war file in Web Sphere 5.1 by Naveen Kilaru on April 14 2004 10:57 EDT
- Websphere Studio 5.1.0 and third party libraries by Kapil Israni on February 22 2004 00:14 EST
- Websphere Studio 5.1.0 and third party libraries by Sean Sullivan on February 22 2004 13:57 EST
- Websphere Studio 5.1.0 and third party libraries by Sean Sullivan on February 24 2004 16:38 EST
- Websphere Studio 5.1.0 and third party libraries by Paul Strack on February 25 2004 19:07 EST
- Websphere Studio 5.1.0 and third party libraries by Sean Sullivan on February 27 2004 14:17 EST
- Websphere Studio 5.1.0 and third party libraries by Paul Strack on February 27 2004 23:50 EST
- Websphere Studio 5.1.0 and third party libraries by Zed Sardar on December 10 2004 13:13 EST
- Re: Websphere Studio 5.1.0 and third party libraries by Tristan Collins on April 21 2008 19:26 EDT
-
Websphere Studio 5.1.0 and third party libraries[ Go to top ]
- Posted by: Paul Strack
- Posted on: February 20 2004 20:13 EST
- in response to Sean Sullivan
It depends on what your target server environment is.
If you know for certain that your target server already has Log4J installed, use Option 3 to put it in your project classpath.
If you have any doubts, use Option 4 and but it in your WEB-INF/lib. That is the safest approach. -
There is another option[ Go to top ]
- Posted by: Colin Williams
- Posted on: February 21 2004 16:17 EST
- in response to Paul Strack
This one doesnt get mentioned often.
You can drop the jar into you EAR project. Do copy of the jar file in the filesystem, the right click on the EAR project and do paste.
This will automagically make the jar file available to any projects associated with the EAR project. So once jar is in your EAR project, right click on any of the associated projects and do click properties. Under dependant jars, the jar that you added to the EAR project can be selected as a dependant jar.
This will add it to the build path of the project, and if you deploy you projects as EAR files, the jar will be deployed to the server also, so the jar does not need to be added to the servers classpath. -
Unable to deploy war file in Web Sphere 5.1[ Go to top ]
- Posted by: Naveen Kilaru
- Posted on: April 14 2004 10:57 EDT
- in response to Paul Strack
hi guys I am unable to deploy a WAR file into WAS 5.1 . Can any one help me out. -
Websphere Studio 5.1.0 and third party libraries[ Go to top ]
- Posted by: Kapil Israni
- Posted on: February 22 2004 00:14 EST
- in response to Sean Sullivan
Option 3 is the best, IMHO.
That way it becomes part of your environment. And can be used by multiple projects, web/EAR or non-web projects. -
Websphere Studio 5.1.0 and third party libraries[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: February 22 2004 13:57 EST
- in response to Sean Sullivan
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. -
Websphere Studio 5.1.0 and third party libraries[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: February 24 2004 16:38 EST
- in response to Sean Sullivan
I received an email reply from Tim deBoer (IBM):
> 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. -
Websphere Studio 5.1.0 and third party libraries[ Go to top ]
- Posted by: Paul Strack
- Posted on: February 25 2004 19:07 EST
- in response to Sean Sullivan
Hi Sean,
My apologies for not continuing the conversation. I am so used to you *answering* questions rather than answering them, that when I saw your later postes I assumed that was what you were doing. It took me a while to notice that the original question was yours :)
Here is another possibility:
Go with Option 3 (Log4J in the WSAD classpath) and put your Log4J jar in the same place for all your projects. Then, write Ant build scripts to add the jar to the generated WAR or EAR in the "build" or "dist" task of your script.
This cuts down on all the duplicate copies of Log4J in your development enviroment, but puts independent copies of Log4J in your deployable archives. -
Websphere Studio 5.1.0 and third party libraries[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: February 27 2004 14:17 EST
- in response to Sean Sullivan
My development environment is more complex that the basic
scenarios described in the WSAD product documentation.
This is my scenario:
Project 1 is a Java project that contains a package called
com.mycorp.util
Project #1 is dependent upon two 3rd party libraries: foo.jar
and bar.jar
Project #2 is an Enterprise Application Project.
Project #3 is a Web Application Project. This Web project
is associated with Project #2.
Project #3 is dependent upon Project #1.
Project #4 is an Enterprise Application Project.
Project #5 is a Web Application Project. This Web project
is associated with Project #4.
Project #5 is dependent upon Project #1.
Note: There are multiple EAR's. Each EAR contains one WAR.
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 Project 1's Java build path
4) bar.jar is included in Project 1's Java build path
5) foo.jar and bar.jar is included in the WEB-INF/lib folder of
both Web applications
6) When I use WSAD's EAR Export feature, I want to
the exported EAR to have foo.jar and bar.jar
embedded inside the WAR's WEB-INF/lib directory
I prefer a solution where I don't have to create multiple physical
copies of the JAR's.
As far as I can tell, WSAD 5.1.0 is requires that I create
multiple physical copies of foo.jar and bar.jar
Is there a better way?
-Sean -
Websphere Studio 5.1.0 and third party libraries[ Go to top ]
- Posted by: Paul Strack
- Posted on: February 27 2004 23:50 EST
- in response to Sean Sullivan
I prefer to handle these kinds of issues with build scripts.
Put all of your Jars in one place (on a web server). Write an Ant build target that uses the <get> task to download all the jars.
In the build targets that generate your EAR, copy the JARs to the right place. If you have cross-project dependencies, your "dist" target can update the master copy of the JAR via FTP or something.
You do end up with lots of copies of your Jars, but since they are all pulled from one master location, this is not a big issue. Plus, it means that when you get a new developer (or need to rebuild your IDE), all you need to do is run the Ant script and get all of the correct jars.
Look at the repository approach of Maven for a hyper-sophisticated variation on this theme (which is where I got the idea), and then do something similar but simpler.
I use the trick in the build file for the Chrysalis project, if you want to see some sample code: http://chrysalis.sourceforge.net -
Websphere Studio 5.1.0 and third party libraries[ Go to top ]
- Posted by: Zed Sardar
- Posted on: December 10 2004 13:13 EST
- in response to Sean Sullivan
Has anyone experienced logging conflicts when using Log4J with multiple projects? At one point or another we've tried options 1, 3, and 4 - and have consistently found that if multiple projects were running on a server instance, the Log4J configs for whichever Log4J dependent project was accessed first - those configs would be used for the others (despite having different log4j.properties files for each). -
Re: Websphere Studio 5.1.0 and third party libraries[ Go to top ]
- Posted by: Tristan Collins
- Posted on: April 21 2008 19:26 EDT
- in response to Zed Sardar
Has anyone experienced logging conflicts when using Log4J with multiple projects? At one point or another we've tried options 1, 3, and 4 - and have consistently found that if multiple projects were running on a server instance, the Log4J configs for whichever Log4J dependent project was accessed first - those configs would be used for the others (despite having different log4j.properties files for each).
Yes!! I have this exact problem! Did you find a resolution to it?