--- Leszek Gawron <[EMAIL PROTECTED]> schrieb:
> Does it mean I will be forced to have xalan/xerces
> in cocoon's
> web-inf/lib directory? Right now the only place is
> jetty/lib/endorsed.
No, but if you put it into web-inf/lib they will be
used, independently what the system classloader or th
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
As described in the comment above, classes in [block]/COB-INF/classes are added
to the classpath. The information, which blocks are added, is read out from
wiring.xml.
While doing this, I've (hopefully) cleaned up our classloading abit as I've
m
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Not so much against, but I think that adding a class loader on a block level
makes it unnecessary to have global cocoon class loader, isn't it?
Hmm, yes, nearly - but I think we can make use of it in the
bootstrapping phase, e.g. to avoid problem
Vadim Gritsenko wrote:
>
> Not so much against, but I think that adding a class loader on a block level
> makes it unnecessary to have global cocoon class loader, isn't it?
>
Hmm, yes, nearly - but I think we can make use of it in the
bootstrapping phase, e.g. to avoid problems with different ve
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
The problem is, that going for what you propose would mean that each
block has to get its own classloader. In Amsterdam we only talked
about *one global* classloader for Cocoon, but maybe I'm wrong here.
Somebody has a pic
Vadim Gritsenko wrote:
Each block will use the exact jars it depends on.
Now, I think the paranoid class loader does do more good than harm, so I
think we should just use it. What situations do you have in mind where
the paranoid class loader would not work for you?
Well let's try it then - b
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
This can be avoided if javac knew how to work with class loader - as jdt does.
So, as we are using jdt, we can remove these settings, right?
Unfortunately we still support javac and other compilers. And talking about
cocoon fat, some other com
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
The problem is, that going for what you propose would mean that each block has
to get its own classloader. In Amsterdam we only talked about *one global*
classloader for Cocoon, but maybe I'm wrong here.
No, you're right - I was refering to "re
Reinhard Poetz wrote:
>
> The problem is, that going for what you propose would mean that each block
> has
> to get its own classloader. In Amsterdam we only talked about *one global*
> classloader for Cocoon, but maybe I'm wrong here.
>
No, you're right - I was refering to "real blocks" with
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
AFAIU this is the usecase that makes OSGi shine. Shall we really implement this?
Can you please elaborate a little bit on this? Of course, if there is
already something helping us we should use it.
The problem is, that going for what you propo
Reinhard Poetz wrote:
>
> AFAIU this is the usecase that makes OSGi shine. Shall we really implement
> this?
>
Can you please elaborate a little bit on this? Of course, if there is
already something helping us we should use it.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://w
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Hmm, yes, but with real blocks you have paranoid class loading anyway.
Each block will use the exact jars it depends on.
hmm, I wouldn't formulate it this way. The build system (M2) will make sure that
there is only o
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>
>
>>Hmm, yes, but with real blocks you have paranoid class loading anyway.
>>Each block will use the exact jars it depends on.
>
>
> hmm, I wouldn't formulate it this way. The build system (M2) will make sure
> that
> there is only one include
Carsten Ziegeler wrote:
Hmm, yes, but with real blocks you have paranoid class loading anyway.
Each block will use the exact jars it depends on.
hmm, I wouldn't formulate it this way. The build system (M2) will make sure that
there is only one include of e.g. log4j deployed as all blocks that
Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>
>>In addition, we could define extra class paths in web.xml (containing
>>directories/jars I think) which were added to the class path as well
>
>
> IIRC, those were *not* added to the classpath, but on the contrary - it was a
> way to indicate
Carsten Ziegeler wrote:
In addition, we could define extra class paths in web.xml (containing
directories/jars I think) which were added to the class path as well
IIRC, those were *not* added to the classpath, but on the contrary - it was a
way to indicate to the java compiler (used in xsp, fo
Reinhard Poetz wrote:
> The only problem that we should get then is with "standard" libraries, citing
> Sylvain:
>
> "Such a strong shielding can have some minor inconveniences, however: if a
> class
> is given by the servlet engine (e.g. a JNDI context) and the same class
> exists
> in the
Carsten Ziegeler wrote:
My point was using it for the whole webapp including the bootstrapping
phase of Cocoon before the sitemap engine kicks in.
IMO we should use, as proposed by Carsten, the paranoid classloader combined
with the reloading-classloader as default and get following hierarchy
Carsten Ziegeler wrote:
I hope that we can remove some of the old class loader/class path
handling in 2.2 and make everything simpler.
In 2.1.x we had a boolean parameter (in web.xml) which could be used to
set the Cocoon class loader (the one used to instantiate Cocoon) as the
thread context cl
Torsten Curdt wrote:
>
>
> We are already using the paranoid classloader
> from within the sitemap if there is a map:classpath
> element. It is being used for the hot reloading
> of classes, components and javaflow.
>
> Did you leave before my presentation?
>
Yepp, I had to :(
But I knew that :
In addition, we could define extra class paths in web.xml (containing
directories/jars I think) which were added to the class path as
well and
finally we have parameters to force load classes (e.g. for jdbc
drivers).
With real blocks I think we should always add our class loader as the
thre
I hope that we can remove some of the old class loader/class path
handling in 2.2 and make everything simpler.
In 2.1.x we had a boolean parameter (in web.xml) which could be used to
set the Cocoon class loader (the one used to instantiate Cocoon) as the
thread context class loader.
In addition,
Reinhard Poetz wrote:
>
> As described in the comment above, classes in [block]/COB-INF/classes are
> added
> to the classpath. The information, which blocks are added, is read out from
> wiring.xml.
>
> While doing this, I've (hopefully) cleaned up our classloading abit as I've
> moved all t
[EMAIL PROTECTED] wrote:
Author: reinhard
Date: Sun Oct 9 05:17:33 2005
New Revision: 307410
URL: http://svn.apache.org/viewcvs?rev=307410&view=rev
Log:
rework classloading:
- add all [block]/COB-INF/classes directories to the classpath
(information is read out from wiring.xml)
- do classl
24 matches
Mail list logo
