Re: [2.2] Support for per sitemap classloading?
* Carsten Ziegeler: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. Hello, Just to try and sum up the discussion, are we still able to reload classes on a per-sitemap basis? I guess it is an improvement (written by Sylvain) that is an interesting feature to keep until we change the blocks architecture. WDYT? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [2.2] Support for per sitemap classloading?
Jean-Baptiste Quenot wrote: * Carsten Ziegeler: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. Hello, Just to try and sum up the discussion, are we still able to reload classes on a per-sitemap basis? I guess it is an improvement (written by Sylvain) that is an interesting feature to keep until we change the blocks architecture. No, this was disabled due to the blocks-fw implementation and I removed the code some days ago after it turned out during this discussion that a) the blocks-fw is there soon and b) this feature will be replaced by the blocks-fw. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler wrote:
One remaining question: currently we have several places where the
thread context classloader is used (for example to create new
instances). I guess that with the blocks-fw in place that the thread
context class loader is not the correct one.
why do you think so? (just curious, I haven't had the idea yet that this could
be a problem)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler wrote:
And one additional question :) In 2.1.x you can configure extra
classpath in the web.xml; I think we should remove that feature for
blocks-fw as well, right?
yes, those hacks are not required with blocks any more
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Daniel Fagerstrom wrote:
What the blocks fw eventually will support depends on what you and
others want it to support and are prepared to implement ;)
Yes, that's the plan. Adding it to
org.apache.cocoon.blocks.servlet.BlocksManager (module:
cocoon-blocks-fw-servlet-impl) shouldn't be too difficult, especially
for you ;-)
But as said in my other response to Carsten's mail, adding it to the
OSGi framework (Equinox and/or Felix) will be more difficult.
I haven't evaluated all the details, but IMHO the difficulty of adding
dynamic classloading in OSGi depends on what you what to achieve. In
OSGi classes in the main classloader of a bundle are imported, exported
or internal. For classes that a bundle export dynamic class loading is
more complicated as all bundles that import the class must be refreeshed
when the class is updated.
But dynamic classloading in Cocoon has always been about isolated, e.g.
sitemap local class loading. As long as we are happy with bundle
internal classloading, it shouldn't be much different from the sitemap
local dynamic classloading of today.
ok
For inter bundle (block) dependencies, you can always stop, update, and
restart a bundle and refresh the OSGi framework, and the application
will work again with the new code (given that all services are dynamic
aware).
I think, what we need is a hook that the stop, update and restart process is
done automatically, if the system is in development mode. I just don't want to
do it myself.
If you have some time, it would be really great if you could have a
look at it. IMO the ReloadingClassloader is one of the most important
features that we should add (developing [web]apps without it, isn't
fun anymore for me).
It should also be noted that Eclipse is based on OSGi and is rather
dynamic :) So it should be possible to achieve a high degree of dynamism
in OSGi based Cocoon, and we can possibly reuse some Eclipse bundles for
convenient application development.
yes, in the meantime I'm very optimistic that we will find ways to add RAD
capabilities :-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz wrote: Carsten Ziegeler wrote: One remaining question: currently we have several places where the thread context classloader is used (for example to create new instances). I guess that with the blocks-fw in place that the thread context class loader is not the correct one. why do you think so? (just curious, I haven't had the idea yet that this could be a problem) Blocks provide isolated class loading, so every block has it's own class loader. Now, unless you want to change the thread context class loader on each method invokation between blocks (like we currently do for the environment stack with internal pipeline calls), then the thread context class loader is rarely the class loader for the current block. We currently use the thread context class loader to get cocoon's classloader which might be different (in 2.1.x) to the webapp class loader. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
One remaining question: currently we have several places where the
thread context classloader is used (for example to create new
instances). I guess that with the blocks-fw in place that the thread
context class loader is not the correct one.
why do you think so? (just curious, I haven't had the idea yet that this could
be a problem)
Blocks provide isolated class loading, so every block has it's own class
loader. Now, unless you want to change the thread context class loader
on each method invokation between blocks (like we currently do for the
environment stack with internal pipeline calls), then the thread context
class loader is rarely the class loader for the current block.
We currently use the thread context class loader to get cocoon's
classloader which might be different (in 2.1.x) to the webapp class loader.
IIUC the classloading as you describe it here isn't in place, right? Currently
we have one global classloader for *all* blocks (see the BlocksManager). The
build system (= Maven 2) takes care that only one version of each artifact is
added to the global classloader.
This will change with the introduction of the OSGi-based blocks-fw. Then OSGi
will take care of it and that's the reason why we should wait before we come up
with our own solutions (which hopefully won't be ncessary).
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz wrote: IIUC the classloading as you describe it here isn't in place, right? Yupp. Currently we have one global classloader for *all* blocks (see the BlocksManager). The build system (= Maven 2) takes care that only one version of each artifact is added to the global classloader. Ok. This will change with the introduction of the OSGi-based blocks-fw. Then OSGi will take care of it and that's the reason why we should wait before we come up with our own solutions (which hopefully won't be ncessary). Ok, yes, I see your point to wait for OSGi, I was just wondering if we could anticipate the outcome and do something today. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Support for per sitemap classloading?
On 04.03.2006, at 01:54, Carsten Ziegeler wrote: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). I guess it is just disabled by default because it is a new feature Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. That's how the class auto-compiling reloading works in trunk ...does/will the block framework support that then? cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler wrote:
Some time ago the support for per sitemap classloaders has been added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
Now the question is, do we want to support this or is this obsolete when
we have the blocks implementation soon? In this case we can simply
remove the classpath handling code, I guess.
yes, you can remove it. Classloading will become a concern of the blocks-fw;
though I have no idea how to add the ReloadingClassloader to the OSGi-based
blocks-fw as this will probably mean extending the functionality of the OSGi
framework that we use. Maybe somebody can pick up this task and find out how
this can be done.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Torsten Curdt wrote:
On 04.03.2006, at 01:54, Carsten Ziegeler wrote:
Some time ago the support for per sitemap classloaders has been added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
I guess it is just disabled by default because it is a new feature
Now the question is, do we want to support this or is this obsolete when
we have the blocks implementation soon? In this case we can simply
remove the classpath handling code, I guess.
That's how the class auto-compiling reloading works in trunk
...does/will the block framework support that then?
Yes, that's the plan. Adding it to
org.apache.cocoon.blocks.servlet.BlocksManager (module:
cocoon-blocks-fw-servlet-impl) shouldn't be too difficult, especially for you ;-)
But as said in my other response to Carsten's mail, adding it to the OSGi
framework (Equinox and/or Felix) will be more difficult. If you have some time,
it would be really great if you could have a look at it. IMO the
ReloadingClassloader is one of the most important features that we should add
(developing [web]apps without it, isn't fun anymore for me).
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz wrote: Carsten Ziegeler wrote: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. yes, you can remove it. Great :) One remaining question: currently we have several places where the thread context classloader is used (for example to create new instances). I guess that with the blocks-fw in place that the thread context class loader is not the correct one. Is there anything I can do today to prepare the correct behaviour? Like getting the class loader from the spring bean factory? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz wrote: Carsten Ziegeler wrote: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. yes, you can remove it. Classloading will become a concern of the blocks-fw; though I have no idea how to add the ReloadingClassloader to the OSGi-based blocks-fw as this will probably mean extending the functionality of the OSGi framework that we use. Maybe somebody can pick up this task and find out how this can be done. And one additional question :) In 2.1.x you can configure extra classpath in the web.xml; I think we should remove that feature for blocks-fw as well, right? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler skrev: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. In the absence of blocks we have developed subsitemaps to handle application modularization. With blocks we have a better concept for modularization, and it is IMO better to focus the role of sitemaps by removing classloading and maybe even deprecating the configuration of components in sitemaps. /Daniel
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz skrev: Torsten Curdt wrote: On 04.03.2006, at 01:54, Carsten Ziegeler wrote: Some time ago the support for per sitemap classloaders has been added to 2.2; this feature is currently disabled (for making the implementation for blocks easier I guess). I guess it is just disabled by default because it is a new feature Now the question is, do we want to support this or is this obsolete when we have the blocks implementation soon? In this case we can simply remove the classpath handling code, I guess. That's how the class auto-compiling reloading works in trunk ...does/will the block framework support that then? What the blocks fw eventually will support depends on what you and others want it to support and are prepared to implement ;) Yes, that's the plan. Adding it to org.apache.cocoon.blocks.servlet.BlocksManager (module: cocoon-blocks-fw-servlet-impl) shouldn't be too difficult, especially for you ;-) But as said in my other response to Carsten's mail, adding it to the OSGi framework (Equinox and/or Felix) will be more difficult. I haven't evaluated all the details, but IMHO the difficulty of adding dynamic classloading in OSGi depends on what you what to achieve. In OSGi classes in the main classloader of a bundle are imported, exported or internal. For classes that a bundle export dynamic class loading is more complicated as all bundles that import the class must be refreeshed when the class is updated. But dynamic classloading in Cocoon has always been about isolated, e.g. sitemap local class loading. As long as we are happy with bundle internal classloading, it shouldn't be much different from the sitemap local dynamic classloading of today. For inter bundle (block) dependencies, you can always stop, update, and restart a bundle and refresh the OSGi framework, and the application will work again with the new code (given that all services are dynamic aware). If you have some time, it would be really great if you could have a look at it. IMO the ReloadingClassloader is one of the most important features that we should add (developing [web]apps without it, isn't fun anymore for me). It should also be noted that Eclipse is based on OSGi and is rather dynamic :) So it should be possible to achieve a high degree of dynamism in OSGi based Cocoon, and we can possibly reuse some Eclipse bundles for convenient application development. /Daniel
