You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/01/30 10:09:08 UTC
Unblocking Blocks - microstep 1
Starting the blocks walk done with microchanges.
microstep 1: loading of components from blocks
--------------------------------------------------
goal
------
The goal is that if I specify:
<map:blocks>
<map:block name="batik"/>
</map:blocks>
then the sitemap processor will
* look in WEB_INF/blocks for the block jars
* load the batik-block.jar classes
* load the avalon components therein specified in a
cocoon.xconf file in the block jar
Note: All other features like versioning, download (of the block and
realted jars), etc will be another microstep.
benefits
----------
No more need to recreate the cocoon.jar after the blocks build. This
will make cocoon.jar really indipendent from the blocks.
issues
---------
Small step, but already there are issues.
1. when we will enable versioning, we can have that a block uses
a version of some libraries, and others another.
This mean that we have to load the blocks with different
classloaders, right?
2. Where does the treeprocessor actually create these components? ;-P
It seems that methods are calling methods that are... you get the
picture... I've got not much time to dwelve into that code, but
I looked at the DefaultTreeBuilder.java, but still I'm puzzled.
Can someone please help me and explain how Cocoon uses-handles
the ComponentManager(s), and how the TreeProcessor works?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
>
> Sylvain Wallez wrote:
<snip/>
>> But if you look at SitemapLanguage, which is a subclass of
>> DefaultTreeBuilder, you will notice that its createComponentManager()
>> method creates a new CocoonComponentManager and configures it with
>> <map:components>. So <map:components> defines components of the
>> sitemap just a cocoon.xconf defines them for the Cocoon object.
>
>
> Yeah, this is it! So I need to change the CocoonComponentManager to be
> able to handle the creation of stuff from the loaded blocks.
>
>> Adding a custom classloader to the sitemap to handle blocks should
>> thus be just a matter of giving that custom classloader to the
>> created CM.
>
>
> Ok. Since we will have a map:blocks section, what do you propose to do
> in code? IE where to load the blocks? Probably simply pass also that
> info to the CocoonComponentManager?
CocoonComponentManager (CCM) -- actually ECM, its parent class --
already has a constructor with the ClassLoader that's to be used to load
components. We just have to write a BlockClassLoader that extends
ParanoidClassLoader and give it to CCM.
Cut, paste, glue, and we're done ;-)
>> Does this answer your question ?
>
>
> Thanks :-D
>
> http://wiki.cocoondev.org/Wiki.jsp?page=InterpretedSitemapInternals
Thanks ! I should have done it myself and just replied with this link ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Nicola Ken Barozzi wrote:
>
> <snip/>
>
>>>> 2. Where does the treeprocessor actually create these components? ;-P
>>>> It seems that methods are calling methods that are... you get the
>>>> picture... I've got not much time to dwelve into that code, but
>>>> I looked at the DefaultTreeBuilder.java, but still I'm puzzled.
>>>>
>>>> Can someone please help me and explain how Cocoon uses-handles
>>>> the ComponentManager(s), and how the TreeProcessor works?
>>>
>>>
>>>
>>> On that, I can't help you mate, but once you figure something out, I can
>>> help you writing some code for it! :-)
>>
>>
>>
>> Sylvain? (the Source ;-)
>>
> Sorry for the delay, I was away for 2 days...
Ahh, bad boy, bad boy ;-P
> The TreeProcessor works by creating an evaluation tree of
> ProcessingNodes corresponding to sitemap statements. It asks a
> TreeBuilder to create this tree and then handles requests with it.
Yup, got to that.
> The TreeBuilder reads the sitemap file (in an Avalon Configuration
> object) and builds this tree by invoking a ProcessingNodeBuilder for
> each element encountered in the sitemap. The ProcessingNodeBuilder in
> turn creates an appropriate ProcessingNode that will be used at runtime
> to "execute" the sitemap
Ok.
> The ProcessingNode isn't created directly from the sitemap element,
> since some sitemap elements don't always lead to identical processing
> depending either on their attributes (e.g. <map:call resource=""> and
> <map:call function="">) or the used components (e.g. <map:match> which
> is different for regular Matcher and PreparedMatcher).
Ahhh, now it's getting interesting...
> The DefaultTreeBuilder has a createComponentManager() method that
> creates - guess what? - the CM that is to be used within the processing
> tree to lookup components. In that default implementation, this is just
> the "current" one (i.e. the one passed to "compose()").
Ok.
> But if you look at SitemapLanguage, which is a subclass of
> DefaultTreeBuilder, you will notice that its createComponentManager()
> method creates a new CocoonComponentManager and configures it with
> <map:components>. So <map:components> defines components of the sitemap
> just a cocoon.xconf defines them for the Cocoon object.
Yeah, this is it! So I need to change the CocoonComponentManager to be
able to handle the creation of stuff from the loaded blocks.
> Adding a custom classloader to the sitemap to handle blocks should thus
> be just a matter of giving that custom classloader to the created CM.
Ok. Since we will have a map:blocks section, what do you propose to do
in code? IE where to load the blocks? Probably simply pass also that
info to the CocoonComponentManager?
> Does this answer your question ?
Thanks :-D
http://wiki.cocoondev.org/Wiki.jsp?page=InterpretedSitemapInternals
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
<snip/>
>>> 2. Where does the treeprocessor actually create these components? ;-P
>>> It seems that methods are calling methods that are... you get the
>>> picture... I've got not much time to dwelve into that code, but
>>> I looked at the DefaultTreeBuilder.java, but still I'm puzzled.
>>>
>>> Can someone please help me and explain how Cocoon uses-handles
>>> the ComponentManager(s), and how the TreeProcessor works?
>>
>>
>> On that, I can't help you mate, but once you figure something out, I can
>> help you writing some code for it! :-)
>
>
> Sylvain? (the Source ;-)
>
Sorry for the delay, I was away for 2 days...
The TreeProcessor works by creating an evaluation tree of
ProcessingNodes corresponding to sitemap statements. It asks a
TreeBuilder to create this tree and then handles requests with it.
The TreeBuilder reads the sitemap file (in an Avalon Configuration
object) and builds this tree by invoking a ProcessingNodeBuilder for
each element encountered in the sitemap. The ProcessingNodeBuilder in
turn creates an appropriate ProcessingNode that will be used at runtime
to "execute" the sitemap
The ProcessingNode isn't created directly from the sitemap element,
since some sitemap elements don't always lead to identical processing
depending either on their attributes (e.g. <map:call resource=""> and
<map:call function="">) or the used components (e.g. <map:match> which
is different for regular Matcher and PreparedMatcher).
The DefaultTreeBuilder has a createComponentManager() method that
creates - guess what? - the CM that is to be used within the processing
tree to lookup components. In that default implementation, this is just
the "current" one (i.e. the one passed to "compose()").
But if you look at SitemapLanguage, which is a subclass of
DefaultTreeBuilder, you will notice that its createComponentManager()
method creates a new CocoonComponentManager and configures it with
<map:components>. So <map:components> defines components of the sitemap
just a cocoon.xconf defines them for the Cocoon object.
Adding a custom classloader to the sitemap to handle blocks should thus
be just a matter of giving that custom classloader to the created CM.
Does this answer your question ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Nicola Ken Barozzi" <ni...@apache.org> wrote:
> Pier Fumagalli wrote:
>>
>> Somehow, well, yes, but at the same time, no... WEB-INF is (IMO) a hack
>
> <snipped-detailed-explanation/>
>
> Yes, the reliance on web.xml is really ugly and stook because we really
> only used it as a servlet for so much time. We have mused sometimes over
> fixing it, but the barrier2start it was too high, given our needs in
> using it as a servlet.
>
> Your analysis is detailed and correct. If you start moving stuff from
> web.xml out of there, I'm +1 for it.
I'll send out a proposal...
> One thing also: we have a cocoon.xconf that talks about both Cocoon
> "core" components and "non-core" ones. The ones that are non-core should
> move to blocks.
>
> This will give us the issue about changing configuration for
> block-loaded Avalon components later on.
I didn't catch up with the entire Avalon stuff quite enough to understand
the full extent of what you're saying... Sorry :-(
>> Hm... I was actually thinking whether we wanted it or not last night... I'm
>> thinking, I don't know if cocoon-blocks should be allowed to "rely" on a
>> particular version of a given library... If two blocks use the same lib,
>> they should be using the same version, and both should be using the latest
>> version... I don't know.
>
> I will always use the latest version, but that's me. In real life you
> will always find blocks that are not managed by us being used, and they
> can rely on any kind of version of a package. It would be a nightmare
> not to make separation possible.
Micro-Step #2 then? :-)
>> If needed, anyohow, I can throw in a ClassLoader
>> implementation (I use it for a thing called "OracleObjects" here at VNU and
>> it does more or less what you need)...
>
> Ok :-)
WHAT THE HELL AM I SAYING? It's already in CVS (and I spent 3 days rewriting
one for my stuff): org.apache.cocoon.servlet.ParanoidClassLoader
Pier (dumb code-that-already-exists-rewriter)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Pier Fumagalli wrote:
> "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
>>Pier Fumagalli wrote:
>>
>>>The only thing I have "against" this is to start thinking about making
>>>"WEB-INF" an optional feature (all throughout the code)... It should be a
>>>configurable feature.
>>>
>>>The "web application" concept collides with a "full-server" concept...
>>>Web-Applications were designed to allow multiple web-applications in the
>>>same container...
>>>
>>>With blocks, web applications are "redundant" (not to say, obsolete). Sooo,
>>>let's try to think about a possible non-web-application layout...
>>
>>Suggestions?
>>
>>The fact is that cocoon.xconf was moved to WEB-INF for security reasons.
>>In that servlet environment I would surely move the blocks under
>>WEB-INF. IMHO it's simple enough to imagine that in all other
>>environments we have a COCOON-INF dir that mimics the WEB_INF one.
>
>
> Somehow, well, yes, but at the same time, no... WEB-INF is (IMO) a hack
<snipped-detailed-explanation/>
Yes, the reliance on web.xml is really ugly and stook because we really
only used it as a servlet for so much time. We have mused sometimes over
fixing it, but the barrier2start it was too high, given our needs in
using it as a servlet.
Your analysis is detailed and correct. If you start moving stuff from
web.xml out of there, I'm +1 for it.
One thing also: we have a cocoon.xconf that talks about both Cocoon
"core" components and "non-core" ones. The ones that are non-core should
move to blocks.
This will give us the issue about changing configuration for
block-loaded Avalon components later on.
>>>>issues
>>>>---------
>>>>
>>>>Small step, but already there are issues.
>>>>
>>>>1. when we will enable versioning, we can have that a block uses
>>>> a version of some libraries, and others another.
>>>> This mean that we have to load the blocks with different
>>>> classloaders, right?
>>>
>>>Correct... And each classloader should work in the "web-application" mode:
>>>check _HERE_ first, and _THEN_ go to the parent classloader... It's not a
>>>big issue though, it could be a problem if we want to start "live reloading"
>>>of blocks, or pass instances of the same class around between different
>>>blocks...
>>
>>yup, let's KISS for now.
>
>
> Hm... I was actually thinking whether we wanted it or not last night... I'm
> thinking, I don't know if cocoon-blocks should be allowed to "rely" on a
> particular version of a given library... If two blocks use the same lib,
> they should be using the same version, and both should be using the latest
> version... I don't know.
I will always use the latest version, but that's me. In real life you
will always find blocks that are not managed by us being used, and they
can rely on any kind of version of a package. It would be a nightmare
not to make separation possible.
> If needed, anyohow, I can throw in a ClassLoader
> implementation (I use it for a thing called "OracleObjects" here at VNU and
> it does more or less what you need)...
Ok :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Nicola Ken Barozzi" <ni...@apache.org> wrote:
> Pier Fumagalli wrote:
>>
>> The only thing I have "against" this is to start thinking about making
>> "WEB-INF" an optional feature (all throughout the code)... It should be a
>> configurable feature.
>>
>> The "web application" concept collides with a "full-server" concept...
>> Web-Applications were designed to allow multiple web-applications in the
>> same container...
>>
>> With blocks, web applications are "redundant" (not to say, obsolete). Sooo,
>> let's try to think about a possible non-web-application layout...
>
> Suggestions?
>
> The fact is that cocoon.xconf was moved to WEB-INF for security reasons.
> In that servlet environment I would surely move the blocks under
> WEB-INF. IMHO it's simple enough to imagine that in all other
> environments we have a COCOON-INF dir that mimics the WEB_INF one.
Somehow, well, yes, but at the same time, no... WEB-INF is (IMO) a hack,
done for web-applications to be self-contained. If the servlet spec instead
of defining this layout:
$(WEBAPP_ROOT} <- all content goes here
${WEBAPP_ROOT}/WEB-INF <- this is supposed to be "protected"
${WEBAPP_ROOT}/WEB-INF/web.xml <- the configuration file
$(WEBAPP_ROOT}/WEB-INF/classes <- free-range classes
$(WEBAPP_ROOT}/WEB-INF/lib <- libraries
Relied on a "different" (and IMO, more sensitive) layout like:
$(WEBAPP_ROOT} <- this _is_ protected, as...
${WEBAPP_ROOT}/content <- this is where you put all content
${WEBAPP_ROOT}/web.xml <- the configuration file
$(WEBAPP_ROOT}/classes <- free-range classes
$(WEBAPP_ROOT}/lib <- libraries
You'd see how things would change dramatically from the security point of
view: the "default servlet" wouldn't have to do the usual "trick" of
if (getRequestURI().startsWith("/WEB-INF/")) then send a 404...
But simply, to serve files, it would do "getResourceAsStream("content"+...)
therefore enhancing security...
And then operating system you go, file-system you find (I can't tell you how
many problems there _always_ are when you have to see if WEB-INF is
upper/lower-case, what does the filesystem support? If someone on Windows
called its "WEB-INF" "Web-Inf", should that be protected?
IT IS A MESS :-) Basically every servlet which relies on getResource...()
literally has to protect itself from a possible WEB-INF attack... If you
reverse the problem, you just have to add "content" at the beginning of your
served resource, and you're done :-) :-)
Ok, enough ranting about why WEB-INF (IMO) is the wrong hack, now, getting
back to Cocoon, in the webapp's WEB-INF directory I see:
- cocoon.xconf/logkit.xconf/instrumentation.xconf
Ok, it's sensible to have them here, as you never know what servlet
container you have under your butt, and therefore, you might end up with
someone serving you the files ANYHOW... In WEB-INF it should be allright.
My vision? Those are configuration files, so, it might be sensible to have
them completely outside from the web-application directory, see my last
patch to CocoonServlet that enables you to specify a full-filesystem path
for it: first "getResource()" is tried with the WEB-INF path in front of it
(in case we're using Cocoon as a web-application), then a real filesystem
call is done (cool if I want to keep jetty.xml and cocoon.xconf in the same
directory).
- web.xml/classes/lib
Those are "specific" for a web application: web.xml configures the webapp
itself, and in case of -for example- Jetty with direct-servlet-mapping, we
don't need it. Classes and Lib should be used only by the classloader, but
oh, well, we also need them to compile Java Code, as so far, no Java
compiler relies on its classloader, but rather on files (Doesn't Pizza does
that????). IMO, if we provide a "classpath" entry to our compilation
framework, we should make those two directories configurable somehow.
- db/deli/entities/logs
Those are "Cocoon" specific, so they should be made configurable again (why
keeping those in there???)
Of course all those paths should default to lookups using
"getResource("/WEB-INF/...")" (maybe even keeping WEB-INF configurable
somehow?) and then, if not found doing a file-system search using
properties, or another getResource-like call.
That, IMO, will help us not only when Cocoon is used in servlet-only based
containers (such as Jetty), where we can really do some beautiful nasty
tricks if we could have a little bit of control (nasty in the term that
noone thought about them before, more security first of all)
So far, "WEB-INF" is hardcoded into those files:
- src/blocks:
hsqldb/java/org/apache/cocoon/components/hsqldb/ServerImpl.java
- src/java:
org/apache/cocoon/components/language/generator/ProgramGeneratorImpl.java
org/apache/cocoon/components/resolver/ResolverImpl.java
org/apache/cocoon/components/treeprocessor/sitemap/PipelineNode.java
org/apache/cocoon/environment/http/HttpContext.java
org/apache/cocoon/Main.java
org/apache/cocoon/servlet/BootstrapServlet.java
org/apache/cocoon/servlet/CocoonServlet.java
org/apache/cocoon/servlet/ParanoidCocoonServlet.java
- src/scratchpad
src/org/apache/cocoon/ant/CocoonTask.java
src/org/apache/cocoon/components/axis/SoapServerImpl.java
src/org/apache/cocoon/components/repository/impl/SlideRepository.java
And another bunch of non-java files... (XMLs, XSLs mainly):
./src/blocks/fop/conf/fop.xmap
./src/blocks/linkrewriter/samples/sitedemo/README.txt
./src/documentation/cocoon.xconf
./src/documentation/xdocs/ctwig/ctwig-basic03.xml
./src/documentation/xdocs/developing/deli.xml
./src/documentation/xdocs/developing/httprequest.xml
./src/documentation/xdocs/dtd/README
./src/documentation/xdocs/faq/faq-configure-c2.xml
./src/documentation/xdocs/faq/faq-databases.xml
./src/documentation/xdocs/faq/faq-install.xml
./src/documentation/xdocs/howto/howto-flow-debugger.xml
./src/documentation/xdocs/howto/howto-html-pdf-publishing.xml
./src/documentation/xdocs/howto/howto-paginator-transformer.xml
./src/documentation/xdocs/installing/index.xml
./src/documentation/xdocs/plan/catalog.xml
./src/documentation/xdocs/tutorial/tutorial-develop-webapp.xml
./src/documentation/xdocs/tutorial/tutorial-generator.xml
./src/documentation/xdocs/tutorial/tutorial-rmi-generator.xml
./src/documentation/xdocs/userdocs/concepts/catalog.xml
./src/documentation/xdocs/userdocs/concepts/index.xml
./src/documentation/xdocs/userdocs/concepts/validation.xml
./src/documentation/xdocs/userdocs/generators/jsp-generator.xml
./src/java/org/apache/cocoon/components/flow/flow.xconf
./src/java/org/apache/cocoon/components/resolver/resolver.xconf
./src/resources/dev/emacs/prj.el.in
./src/scratchpad/schecoon/ChangeLog
./src/scratchpad/src/org/apache/cocoon/ant/readme.txt
./src/scratchpad/webapp/samples/slide/README
./src/scratchpad/webapp/samples/slide/web.xml
./src/test/CatalogManager.properties
./src/webapp/cocoon.xconf.moved
./src/webapp/samples/common/style/xsl/html/error2html.xsl
./src/webapp/samples/docs/samples/sample-dynamic.xml
./src/webapp/samples/flow/docs/book.xml
./src/webapp/samples/flow/docs/continuations.xml
./src/webapp/samples/flow/docs/how-does-it-work.xml
./src/webapp/samples/flow/docs/index.xml
./src/webapp/samples/flow/docs/invalidContinuation.xml
./src/webapp/samples/flow/docs/samples.xml
./src/webapp/samples/stylesheets/system/error2html.xsl
./src/webapp/WEB-INF/classes/CatalogManager.properties
./src/webapp/WEB-INF/cocoon.xconf
./src/webapp/WEB-INF/deli/config/deliConfig.xml
./src/webapp/WEB-INF/deli/config/legacyDevice.xml
./src/webapp/WEB-INF/logkit.xconf
./src/webapp/WEB-INF/web.xml
>>> issues
>>> ---------
>>>
>>> Small step, but already there are issues.
>>>
>>> 1. when we will enable versioning, we can have that a block uses
>>> a version of some libraries, and others another.
>>> This mean that we have to load the blocks with different
>>> classloaders, right?
>>
>> Correct... And each classloader should work in the "web-application" mode:
>> check _HERE_ first, and _THEN_ go to the parent classloader... It's not a
>> big issue though, it could be a problem if we want to start "live reloading"
>> of blocks, or pass instances of the same class around between different
>> blocks...
>
> yup, let's KISS for now.
Hm... I was actually thinking whether we wanted it or not last night... I'm
thinking, I don't know if cocoon-blocks should be allowed to "rely" on a
particular version of a given library... If two blocks use the same lib,
they should be using the same version, and both should be using the latest
version... I don't know. If needed, anyohow, I can throw in a ClassLoader
implementation (I use it for a thing called "OracleObjects" here at VNU and
it does more or less what you need)...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Pier Fumagalli wrote:
> On 30/1/03 9:09, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
>>Starting the blocks walk done with microchanges.
>
>
> Yeah! :-)
>
>
>>microstep 1: loading of components from blocks
>>--------------------------------------------------
>>
>>goal
>>------
>>
>>The goal is that if I specify:
>>
>><map:blocks>
>> <map:block name="batik"/>
>></map:blocks>
>>
>>then the sitemap processor will
>>
>>* look in WEB_INF/blocks for the block jars
>>* load the batik-block.jar classes
>>* load the avalon components therein specified in a
>> cocoon.xconf file in the block jar
>>
>>Note: All other features like versioning, download (of the block and
>>realted jars), etc will be another microstep.
>
>
> The only thing I have "against" this is to start thinking about making
> "WEB-INF" an optional feature (all throughout the code)... It should be a
> configurable feature.
>
> The "web application" concept collides with a "full-server" concept...
> Web-Applications were designed to allow multiple web-applications in the
> same container...
>
> With blocks, web applications are "redundant" (not to say, obsolete). Sooo,
> let's try to think about a possible non-web-application layout...
Suggestions?
The fact is that cocoon.xconf was moved to WEB-INF for security reasons.
In that servlet environment I would surely move the blocks under
WEB-INF. IMHO it's simple enough to imagine that in all other
environments we have a COCOON-INF dir that mimics the WEB_INF one.
>>benefits
>>----------
>>
>>No more need to recreate the cocoon.jar after the blocks build. This
>>will make cocoon.jar really indipendent from the blocks.
>
> Shall we think about layering better the build system?
It's not the build system, it's that cocoon.jar now needs that all
Avalon components be inserted in a property file in cocoon.jar. This is
why I want to do this microstep ;-)
>>issues
>>---------
>>
>>Small step, but already there are issues.
>>
>>1. when we will enable versioning, we can have that a block uses
>> a version of some libraries, and others another.
>> This mean that we have to load the blocks with different
>> classloaders, right?
>
> Correct... And each classloader should work in the "web-application" mode:
> check _HERE_ first, and _THEN_ go to the parent classloader... It's not a
> big issue though, it could be a problem if we want to start "live reloading"
> of blocks, or pass instances of the same class around between different
> blocks...
yup, let's KISS for now.
>>2. Where does the treeprocessor actually create these components? ;-P
>> It seems that methods are calling methods that are... you get the
>> picture... I've got not much time to dwelve into that code, but
>> I looked at the DefaultTreeBuilder.java, but still I'm puzzled.
>>
>> Can someone please help me and explain how Cocoon uses-handles
>> the ComponentManager(s), and how the TreeProcessor works?
>
> On that, I can't help you mate, but once you figure something out, I can
> help you writing some code for it! :-)
Sylvain? (the Source ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Unblocking Blocks - microstep 1
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 30/1/03 9:09, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> Starting the blocks walk done with microchanges.
Yeah! :-)
> microstep 1: loading of components from blocks
> --------------------------------------------------
>
> goal
> ------
>
> The goal is that if I specify:
>
> <map:blocks>
> <map:block name="batik"/>
> </map:blocks>
>
> then the sitemap processor will
>
> * look in WEB_INF/blocks for the block jars
> * load the batik-block.jar classes
> * load the avalon components therein specified in a
> cocoon.xconf file in the block jar
>
> Note: All other features like versioning, download (of the block and
> realted jars), etc will be another microstep.
The only thing I have "against" this is to start thinking about making
"WEB-INF" an optional feature (all throughout the code)... It should be a
configurable feature.
The "web application" concept collides with a "full-server" concept...
Web-Applications were designed to allow multiple web-applications in the
same container...
With blocks, web applications are "redundant" (not to say, obsolete). Sooo,
let's try to think about a possible non-web-application layout...
> benefits
> ----------
>
> No more need to recreate the cocoon.jar after the blocks build. This
> will make cocoon.jar really indipendent from the blocks.
Shall we think about layering better the build system?
> issues
> ---------
>
> Small step, but already there are issues.
>
> 1. when we will enable versioning, we can have that a block uses
> a version of some libraries, and others another.
> This mean that we have to load the blocks with different
> classloaders, right?
Correct... And each classloader should work in the "web-application" mode:
check _HERE_ first, and _THEN_ go to the parent classloader... It's not a
big issue though, it could be a problem if we want to start "live reloading"
of blocks, or pass instances of the same class around between different
blocks...
> 2. Where does the treeprocessor actually create these components? ;-P
> It seems that methods are calling methods that are... you get the
> picture... I've got not much time to dwelve into that code, but
> I looked at the DefaultTreeBuilder.java, but still I'm puzzled.
>
> Can someone please help me and explain how Cocoon uses-handles
> the ComponentManager(s), and how the TreeProcessor works?
On that, I can't help you mate, but once you figure something out, I can
help you writing some code for it! :-)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org