Problem with log4java (was: Branching for release)

[Santiago Gala <sg...@hisitech.com>]

Johnny Cass wrote:

> Santiago Gala wrote:
> 
>>
>>Also, I'm seeing funny things with current CVS.
>>
>>- jetspeed.jar is not in the war, at least not in WEB-INF/lib ???
>>
> 
> The current build system does not add jetspeed.jar to the war. Instead,
> the jetspeed classes are compiled into the 'classes' directory which
> *is* distributed with the war. As far as I know, the net effect should
> be the same (both are added to the classpath of the webapp).
> 


OK. Since I had two errors mixed up, I will try without jetspeed.jar to 
see if/how it works.

The problem I see with this setup is that we can no longer build and 
then move the jetspeed.jar to the tomcat directory. How do you manage 
incremental builds? Do we have a target where we can specify a webapp 
target directory for ant to copy the compiled files (and maybe content) 
there, w/o building and expanding the war under tomcat?

Expanding the war destroys any permanent changes done by customization, 
the cache, etc.


> 
>>- I get a catastrophic error about log4java (seems like updating
>>turbine.jar is not enough).
>>
>>After I added the jetspeed.jar to the webapp and changed the log4java
>>1.0.4 files by log4java 1.1 (coming from Turbine HEAD), it seems to work
>>again.
>>
>>
> 
> Hmmm...not sure why this is happening, anybody else having the same
> problem?
> 


The cause is probably this: David changed turbine.jar, to prepare for 
the turbine release. Possibly he forgot to switch log4java versions:

> taylor      01/06/04 00:08:51
> 
>   Added:       lib      turbine-2.2-dev.jar velocity-1.0.jar
>   Removed:     lib      turbine-TDKa13.jar velocity-1.0b2-dev.jar
>   Log:
>   upgraded to TDK 2.2
>   
>   Revision  Changes    Path
>   1.1                  jakarta-jetspeed/lib/turbine-2.2-dev.jar
>   
>   	<<Binary file>>
> 1.1                  jakarta-jetspeed/lib/velocity-1.0.jar
>   
>   	<<Binary file>>
> 


I will not commit the change until David does it, or else says there is 
a reason for not doing it (or tells me please do it :-) ). It should be 
noticed for cvs checkouts after June 4th. If nobody removed the 
webapps/jetspeed directory, to have the war expanded, you will still run 
with the old turbine and velocity jars.




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

Re: Problem with log4java (was: Branching for release)

[Johnny Cass <jo...@epiuse.com>]

Santiago Gala wrote:
> 
> Johnny Cass wrote:
> 
> > Santiago Gala wrote:
> >
> >>
> >>Also, I'm seeing funny things with current CVS.
> >>
> >>- jetspeed.jar is not in the war, at least not in WEB-INF/lib ???
> >>
> >
> > The current build system does not add jetspeed.jar to the war. Instead,
> > the jetspeed classes are compiled into the 'classes' directory which
> > *is* distributed with the war. As far as I know, the net effect should
> > be the same (both are added to the classpath of the webapp).
> >
> 
> OK. Since I had two errors mixed up, I will try without jetspeed.jar to
> see if/how it works.
> 
> The problem I see with this setup is that we can no longer build and
> then move the jetspeed.jar to the tomcat directory. 

The 'jar' target creates a jetspeed.jar. So, you could use 'war' to
create the webapp, copy this to ${tomcat.home}/webapps, run tomcat to
expand the war, delete the 'classes' directory, and then copy the
jetspeed.jar created by target 'jar' into WEB-INF/lib on subsequent
builds. Alternatively, you could simply replace the classes directory
for the jetspeed webapp in tomcat with the one under
${jetspeed.cvs.root}/bin/classes.

Having said this, I must admit that it sounds like way too much trouble.
I usually use soft links to accomplish the same effect.

> How do you manage
> incremental builds? Do we have a target where we can specify a webapp
> target directory for ant to copy the compiled files (and maybe content)
> there, w/o building and expanding the war under tomcat?
> 

I usually set a soft link from ${jetspeed.cvs.root}/webapp to
${tomcat.home}/webapps/jetspeed and one from
${jetspeed.cvs.root}/bin/classes to
${jetspeed.cvs.root}/webapp/WEB-INF/classes. So, in effect, I am running
Jetspeed direct from my CVS repository. I'm sure somebody can educate me
on the perils of this approach! ;).

> Expanding the war destroys any permanent changes done by customization,
> the cache, etc.
> 

I'm open for suggestions, it doesn't really make a difference either
way. We will need to have a 'classes' directory regardless of the
approach taken since the 'cactus.properties' file needs to be in the
webapp's classpath.

- Johnny

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org