You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2004/03/31 11:56:57 UTC
[Kernel2.2] Source Resolving
I just had some quick looks at the new kernel 2.2 and the
first topic to discuss is source resolving :)
Cocoon uses the excalibur source resolving package to resolve
any resources (file, http, cocoon pipelines etc.).
The kernel currently uses a similar construct
but with new interfaces and implementations.
In order to reuse what we already have and to be
"more compatible" to Cocoon 2.0/2.1, I would suggest to use
the sourcer resolver package here as well.
Another reason is that we need a Source Resolver for the sitemap
components anyway. Most sitemap components get the source resolver
as a parameter in the setup (or act etc.) method.
Now, I know that the original kernel should be as small as possible
and if possible without references to any other projects which is
in general great and ok, but I think for Cocoon it's better to use
existing parts whereever possible.
Ah, and if you think that one problem is that the sourceresolver
package is hosted at avalon, we can/should solve this as well.
WDYT?
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/
Re: [Kernel2.2] Source Resolving
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 31 Mar 2004, at 17:29, Stefano Mazzocchi wrote:
> Carsten Ziegeler wrote:
>> Gianugo Rabellino wrote:
>>> Carsten Ziegeler wrote:
>>>
>>>
>>>> Now, I know that the original kernel should be as small as possible
>>>> and if possible without references to any other projects
>>>
>>> which is in
>>>> general great and ok, but I think for Cocoon it's better to use
>>>> existing parts whereever possible.
>>>
>>> Well, the balance will be hard to find, but I think that avalon
>>> source resolving cannot be used without importing all the heck of
>>> Avalon itself and its dependencies, so how would you plan to import
>>> it in the new environment without an almost complete rewrite?
>>>
>> Ah, ok, I wasn't very clear :)
>> First, I think we should use the interfaces (SourceResolver and
>> SOurce)
>> from excalibur. Apart from the package name they have no dependency
>> to anything else at Avalon. And I think using these interfaces is
>> the key concern.
>> Then most of the implementation is "avalon free" as well.
>> Third, the package will be put to sleep over at avalon anyway as it
>> doesn't comply to the Merlin component standard, so it makes sense
>> to take over this source anyway.
>
> -1
>
> I think the kernel should be *clean* of avalon stuff and there will be
> an avalon sandbox for legacy.
>
> Look at the good side of this: you can cleanup those interfaces with
> the knowledge we aquired from excalibur.
So, would you like that that the resolver provided by the framework
could actually resolve "http:...", "ftp:...", "cocoon:..." and
"block:wiring:..." or your preference is to keep it lean over there and
only have "wiring:..." whilst having something ELSE to resolve the real
protocols?
Pier
Re: [Kernel2.2] Source Resolving
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Gianugo Rabellino wrote:
>
>>Carsten Ziegeler wrote:
>>
>>
>>>Now, I know that the original kernel should be as small as possible
>>>and if possible without references to any other projects
>>
>>which is in
>>
>>>general great and ok, but I think for Cocoon it's better to use
>>>existing parts whereever possible.
>>
>>Well, the balance will be hard to find, but I think that
>>avalon source resolving cannot be used without importing all
>>the heck of Avalon itself and its dependencies, so how would
>>you plan to import it in the new environment without an
>>almost complete rewrite?
>>
>
> Ah, ok, I wasn't very clear :)
>
> First, I think we should use the interfaces (SourceResolver and SOurce)
> from excalibur. Apart from the package name they have no dependency
> to anything else at Avalon. And I think using these interfaces is
> the key concern.
>
> Then most of the implementation is "avalon free" as well.
>
> Third, the package will be put to sleep over at avalon anyway as it
> doesn't comply to the Merlin component standard, so it makes sense
> to take over this source anyway.
-1
I think the kernel should be *clean* of avalon stuff and there will be
an avalon sandbox for legacy.
Look at the good side of this: you can cleanup those interfaces with the
knowledge we aquired from excalibur.
--
Stefano.
RE: [Kernel2.2] Source Resolving
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Gianugo Rabellino wrote:
>
> Carsten Ziegeler wrote:
>
> > Now, I know that the original kernel should be as small as possible
> > and if possible without references to any other projects
> which is in
> > general great and ok, but I think for Cocoon it's better to use
> > existing parts whereever possible.
>
> Well, the balance will be hard to find, but I think that
> avalon source resolving cannot be used without importing all
> the heck of Avalon itself and its dependencies, so how would
> you plan to import it in the new environment without an
> almost complete rewrite?
>
Ah, ok, I wasn't very clear :)
First, I think we should use the interfaces (SourceResolver and SOurce)
from excalibur. Apart from the package name they have no dependency
to anything else at Avalon. And I think using these interfaces is
the key concern.
Then most of the implementation is "avalon free" as well.
Third, the package will be put to sleep over at avalon anyway as it
doesn't comply to the Merlin component standard, so it makes sense
to take over this source anyway.
Carsten
Re: [Kernel2.2] Source Resolving
Posted by Gianugo Rabellino <gi...@apache.org>.
Carsten Ziegeler wrote:
> Now, I know that the original kernel should be as small as possible
> and if possible without references to any other projects which is
> in general great and ok, but I think for Cocoon it's better to use
> existing parts whereever possible.
Well, the balance will be hard to find, but I think that avalon source
resolving cannot be used without importing all the heck of Avalon itself
and its dependencies, so how would you plan to import it in the new
environment without an almost complete rewrite?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)
Re: [Kernel2.2] Source Resolving
Posted by Gianugo Rabellino <gi...@apache.org>.
Pier Fumagalli wrote:
>>>> general great and ok, but I think for Cocoon it's better to use
>>>> existing parts whereever possible.
>
> Only "issue" I might see with that is that Excalibur's Source doesn't
> have the "isDirectory()" and "children()" methods, so, well, I don't
> absolutely like it because it's prone to hacks.
>
> Maybe a union of the two might be better?
Uh? It's in TraversableSource, a subinterface, yes, but it's there...
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)
Re: [Kernel2.2] Source Resolving
Posted by Sylvain Wallez <sy...@apache.org>.
Gianugo Rabellino wrote:
> Pier Fumagalli wrote:
>
>>>> Only "issue" I might see with that is that Excalibur's Source
>>>> doesn't have the "isDirectory()" and "children()" methods,
>>>> so, well, I don't absolutely like it because it's prone to hacks.
>>>>
>>> Ah, this is in a sub interface of Source (TraversableSource or
>>> something
>>> like that).
>>
>>
>>
>> On 31 Mar 2004, at 13:09, Gianugo Rabellino wrote:
>>
>>> Uh? It's in TraversableSource, a subinterface, yes, but it's there...
>>
>>
>>
>> I still prefer something like:
>>
>> if (!source.isDirectory()) throw Exception("I need a directory");
>>
>> rather than
>>
>> if (!(source instanceof TraversableSource)) throw Exception("I need a
>> directory");
>>
>> I don't see the point of two interfaces (and as I did, it's easy to
>> miss).
>
>
> Well, I think that this is due to historical reasons, but in any case
> I can also see a point in having the subinterface concept: for quite a
> bit of sources the concept of traversal just doesn't apply (oh, by the
> way, please drop "file" and "directory" for "resource" and
> "collection"... pretty please :-)), so it makes quite some sense to
> use plain polymorphism in this specific case.
Yep. The basic Source interface is just a read-only access point to a
stream (bytes or XML) of data, which represents the vast majority of
uses. This is a minimal common denominator. Later came TraversableSource
(parent/child relationship), ModifiableSource (can be written to) an
some other things in the "repository" block (versioned, inspectable, etc).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Kernel2.2] Source Resolving
Posted by Gianugo Rabellino <gi...@apache.org>.
Pier Fumagalli wrote:
>>> Only "issue" I might see with that is that Excalibur's Source
>>> doesn't have the "isDirectory()" and "children()" methods,
>>> so, well, I don't absolutely like it because it's prone to hacks.
>>>
>> Ah, this is in a sub interface of Source (TraversableSource or something
>> like that).
>
>
> On 31 Mar 2004, at 13:09, Gianugo Rabellino wrote:
>
>> Uh? It's in TraversableSource, a subinterface, yes, but it's there...
>
>
> I still prefer something like:
>
> if (!source.isDirectory()) throw Exception("I need a directory");
>
> rather than
>
> if (!(source instanceof TraversableSource)) throw Exception("I need a
> directory");
>
> I don't see the point of two interfaces (and as I did, it's easy to miss).
Well, I think that this is due to historical reasons, but in any case I
can also see a point in having the subinterface concept: for quite a bit
of sources the concept of traversal just doesn't apply (oh, by the way,
please drop "file" and "directory" for "resource" and "collection"...
pretty please :-)), so it makes quite some sense to use plain
polymorphism in this specific case.
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)
RE: [Kernel2.2] Source Resolving
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Pier Fumagalli wrote:
>
> I'm thinking that blocks should always be distributed as
> "zip" files (note, not JAR archives), containing a
> "block.xml" file (block
> descriptor) and the different JARs required by it (its
> libraries) or its directories...
>
> This zip should be expanded by a Library implementation so
> that a Loader can instantiate a Block, and this expansion can
> (should) be done in the temp directory...
>
Ah, yes, I remember - we discussed this long time ago. Right. Sorry.
> >> If we want to build the full resolver inside the framework itself,
> >> and therefore the "resolve" method in "Wirings" and "Wire" will
> >> accept "block:wiring:/path" instead of only
> "wiring:/path", then yes,
> >> I agree with you that source resolution should be closer
> (or same as)
> >> Excalibur's SourceResolver.
> >
> > Currently, I don't know which way is better :) Perhaps I have to
> > understand the whole thing before I should comment on just some
> > parts...
>
> In my requirement for the framework as VNU I don't personally
> need the "extended" (a-la SourceResolver) resolution, but
> it's trivial to implement, although it poses some questions
> on how to implement it...
> I'll leave this up to you guys to decide what's better...
:)
>
> >> Only "issue" I might see with that is that Excalibur's
> Source doesn't
> >> have the "isDirectory()" and "children()" methods, so,
> well, I don't
> >> absolutely like it because it's prone to hacks.
> >>
> > Ah, this is in a sub interface of Source (TraversableSource or
> > something like that).
>
> On 31 Mar 2004, at 13:09, Gianugo Rabellino wrote:
>
> > Uh? It's in TraversableSource, a subinterface, yes, but
> it's there...
>
> I still prefer something like:
>
> if (!source.isDirectory()) throw Exception("I need a directory");
>
> rather than
>
> if (!(source instanceof TraversableSource)) throw
> Exception("I need a directory");
>
> I don't see the point of two interfaces (and as I did, it's
> easy to miss).
>
Yes, that's true. Ok, so time will tell what's best :)
Thanks!
Carsten
Re: [Kernel2.2] Source Resolving
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 31 Mar 2004, at 13:25, Carsten Ziegeler wrote:
> Pier Fumagalli wrote:
>>
>> I don't think there are going to be more, as blocks libraries
>> themselves can be represented as a directory (File) and a JAR
>> archive (JarFile)... So, for resolution of sources _between_
>> block, nothing else should get in the way...
> Hmm, what if Cocoon is deployed as a war file and the servlet
> container doesn't unpack the war to the file system?
Uh, careful... Libraries provide resources AND classes.
The servlet container provides a single monolithic classloader, so, at
the end it would be insufficent for class loading.
In those environments, I'd think that we should expand each block
contained in the WAR into the temporary directory exposed by the
servlet container, and base all blocks loading from there.
I'm thinking that blocks should always be distributed as "zip" files
(note, not JAR archives), containing a "block.xml" file (block
descriptor) and the different JARs required by it (its libraries) or
its directories...
This zip should be expanded by a Library implementation so that a
Loader can instantiate a Block, and this expansion can (should) be done
in the temp directory...
>> If we want to build the full resolver inside the framework
>> itself, and therefore the "resolve" method in "Wirings" and
>> "Wire" will accept "block:wiring:/path" instead of only
>> "wiring:/path", then yes, I agree with you that source
>> resolution should be closer (or same as) Excalibur's SourceResolver.
>
> Currently, I don't know which way is better :) Perhaps I have to
> understand the whole thing before I should comment on just some
> parts...
In my requirement for the framework as VNU I don't personally need the
"extended" (a-la SourceResolver) resolution, but it's trivial to
implement, although it poses some questions on how to implement it...
I'll leave this up to you guys to decide what's better...
>> Only "issue" I might see with that is that Excalibur's Source
>> doesn't have the "isDirectory()" and "children()" methods,
>> so, well, I don't absolutely like it because it's prone to hacks.
>>
> Ah, this is in a sub interface of Source (TraversableSource or
> something
> like that).
On 31 Mar 2004, at 13:09, Gianugo Rabellino wrote:
> Uh? It's in TraversableSource, a subinterface, yes, but it's there...
I still prefer something like:
if (!source.isDirectory()) throw Exception("I need a directory");
rather than
if (!(source instanceof TraversableSource)) throw Exception("I need a
directory");
I don't see the point of two interfaces (and as I did, it's easy to
miss).
Pier
RE: [Kernel2.2] Source Resolving
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Pier Fumagalli wrote:
>
> I don't think there are going to be more, as blocks libraries
> themselves can be represented as a directory (File) and a JAR
> archive (JarFile)... So, for resolution of sources _between_
> block, nothing else should get in the way...
Hmm, what if Cocoon is deployed as a war file and the servlet
container doesn't unpack the war to the file system?
>
> If we want to build the full resolver inside the framework
> itself, and therefore the "resolve" method in "Wirings" and
> "Wire" will accept "block:wiring:/path" instead of only
> "wiring:/path", then yes, I agree with you that source
> resolution should be closer (or same as) Excalibur's SourceResolver.
Currently, I don't know which way is better :) Perhaps I have to
understand the whole thing before I should comment on just some
parts...
>
> Only "issue" I might see with that is that Excalibur's Source
> doesn't have the "isDirectory()" and "children()" methods,
> so, well, I don't absolutely like it because it's prone to hacks.
>
Ah, this is in a sub interface of Source (TraversableSource or something
like that).
Carsten
Re: [Kernel2.2] Source Resolving
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 31 Mar 2004, at 12:18, Carsten Ziegeler wrote:
> Pier Fumagalli wrote:
>> On 31 Mar 2004, at 10:56, Carsten Ziegeler wrote:
>>
>>> I just had some quick looks at the new kernel 2.2 and the
>> first topic
>>> to discuss is source resolving :)
>>>
>>> Cocoon uses the excalibur source resolving package to resolve any
>>> resources (file, http, cocoon pipelines etc.).
>>> The kernel currently uses a similar construct but with new
>> interfaces
>>> and implementations.
>>>
>>> In order to reuse what we already have and to be "more
>> compatible" to
>>> Cocoon 2.0/2.1, I would suggest to use the sourcer resolver package
>>> here as well.
>>> Another reason is that we need a Source Resolver for the sitemap
>>> components anyway. Most sitemap components get the source
>> resolver as
>>> a parameter in the setup (or act etc.) method.
>>>
>>> Now, I know that the original kernel should be as small as possible
>>> and if possible without references to any other projects
>> which is in
>>> general great and ok, but I think for Cocoon it's better to use
>>> existing parts whereever possible.
>>>
>>> Ah, and if you think that one problem is that the sourceresolver
>>> package is hosted at avalon, we can/should solve this as well.
>>>
>>> WDYT?
>>
>> Carsten, i think I introduced a little bit of confusion
>> calling a couple of things "Resource" and "Resolver"...
>> Careful, those are "resource" resolution for infra-block
>> wirings. What does it mean? That
>> Wirings.resolve(String) or Wire.resolve(String) will NEVER
>> resolve things like "http:...." or "ftp:...", not even
>> "cocoon:...." unless those names are names of wirings
>> specified in a block descriptor.
>>
>> A sourceresolver must be implemented on top of this
>> interface, providing resolution for "http:...", "ftp:...",
>> "cocoon:..." <and> a new protocol called "block:..." which
>> will fall back on the framework resource resolvers.
>>
>> As Stefano said in his original [RT] on blocks, any
>> source-resolved resource which need to fall back on blocks
>> resolution will have to be something like:
>>
>> block:wiringname:...
>>
>> The SourceResolver will have to look at the beginning
>> (block:) and understand that in needs to resolve the resource
>> on the block's resolver as "wiringname:...". If it begins
>> with something else (cocoon:
>> for example) it will have to resolve in a different way...
>>
>> The Resolver interface specifies that there's no contract
>> between name and the resource, maybe we could implement this
>> in the o.a.c.k.DeployedWirings class, change the interface,
>> or whatever! :-)
>>
> Ah, ok, I see. Good :)
> But couldn't the source resolver (the interfaces and the impl.)
> not also be used for this as well? I saw, you have an impl. for
> jars and one for files. This is more or less code duplication,
> I think. Of course, if there are only these two and not more
> than it might be ok. Hmmm :)
I don't think there are going to be more, as blocks libraries
themselves can be represented as a directory (File) and a JAR archive
(JarFile)... So, for resolution of sources _between_ block, nothing
else should get in the way...
If we want to build the full resolver inside the framework itself, and
therefore the "resolve" method in "Wirings" and "Wire" will accept
"block:wiring:/path" instead of only "wiring:/path", then yes, I agree
with you that source resolution should be closer (or same as)
Excalibur's SourceResolver.
Only "issue" I might see with that is that Excalibur's Source doesn't
have the "isDirectory()" and "children()" methods, so, well, I don't
absolutely like it because it's prone to hacks.
Maybe a union of the two might be better?
Pier
RE: [Kernel2.2] Source Resolving
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Pier Fumagalli wrote:
>
> On 31 Mar 2004, at 10:56, Carsten Ziegeler wrote:
>
> > I just had some quick looks at the new kernel 2.2 and the
> first topic
> > to discuss is source resolving :)
> >
> > Cocoon uses the excalibur source resolving package to resolve any
> > resources (file, http, cocoon pipelines etc.).
> > The kernel currently uses a similar construct but with new
> interfaces
> > and implementations.
> >
> > In order to reuse what we already have and to be "more
> compatible" to
> > Cocoon 2.0/2.1, I would suggest to use the sourcer resolver package
> > here as well.
> > Another reason is that we need a Source Resolver for the sitemap
> > components anyway. Most sitemap components get the source
> resolver as
> > a parameter in the setup (or act etc.) method.
> >
> > Now, I know that the original kernel should be as small as possible
> > and if possible without references to any other projects
> which is in
> > general great and ok, but I think for Cocoon it's better to use
> > existing parts whereever possible.
> >
> > Ah, and if you think that one problem is that the sourceresolver
> > package is hosted at avalon, we can/should solve this as well.
> >
> > WDYT?
>
> Carsten, i think I introduced a little bit of confusion
> calling a couple of things "Resource" and "Resolver"...
> Careful, those are "resource" resolution for infra-block
> wirings. What does it mean? That
> Wirings.resolve(String) or Wire.resolve(String) will NEVER
> resolve things like "http:...." or "ftp:...", not even
> "cocoon:...." unless those names are names of wirings
> specified in a block descriptor.
>
> A sourceresolver must be implemented on top of this
> interface, providing resolution for "http:...", "ftp:...",
> "cocoon:..." <and> a new protocol called "block:..." which
> will fall back on the framework resource resolvers.
>
> As Stefano said in his original [RT] on blocks, any
> source-resolved resource which need to fall back on blocks
> resolution will have to be something like:
>
> block:wiringname:...
>
> The SourceResolver will have to look at the beginning
> (block:) and understand that in needs to resolve the resource
> on the block's resolver as "wiringname:...". If it begins
> with something else (cocoon:
> for example) it will have to resolve in a different way...
>
> The Resolver interface specifies that there's no contract
> between name and the resource, maybe we could implement this
> in the o.a.c.k.DeployedWirings class, change the interface,
> or whatever! :-)
>
Ah, ok, I see. Good :)
But couldn't the source resolver (the interfaces and the impl.)
not also be used for this as well? I saw, you have an impl. for
jars and one for files. This is more or less code duplication,
I think. Of course, if there are only these two and not more
than it might be ok. Hmmm :)
Carsten
Re: [Kernel2.2] Source Resolving
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 31 Mar 2004, at 10:56, Carsten Ziegeler wrote:
> I just had some quick looks at the new kernel 2.2 and the
> first topic to discuss is source resolving :)
>
> Cocoon uses the excalibur source resolving package to resolve
> any resources (file, http, cocoon pipelines etc.).
> The kernel currently uses a similar construct
> but with new interfaces and implementations.
>
> In order to reuse what we already have and to be
> "more compatible" to Cocoon 2.0/2.1, I would suggest to use
> the sourcer resolver package here as well.
> Another reason is that we need a Source Resolver for the sitemap
> components anyway. Most sitemap components get the source resolver
> as a parameter in the setup (or act etc.) method.
>
> Now, I know that the original kernel should be as small as possible
> and if possible without references to any other projects which is
> in general great and ok, but I think for Cocoon it's better to use
> existing parts whereever possible.
>
> Ah, and if you think that one problem is that the sourceresolver
> package is hosted at avalon, we can/should solve this as well.
>
> WDYT?
Carsten, i think I introduced a little bit of confusion calling a
couple of things "Resource" and "Resolver"... Careful, those are
"resource" resolution for infra-block wirings. What does it mean? That
Wirings.resolve(String) or Wire.resolve(String) will NEVER resolve
things like "http:...." or "ftp:...", not even "cocoon:...." unless
those names are names of wirings specified in a block descriptor.
A sourceresolver must be implemented on top of this interface,
providing resolution for "http:...", "ftp:...", "cocoon:..." <and> a
new protocol called "block:..." which will fall back on the framework
resource resolvers.
As Stefano said in his original [RT] on blocks, any source-resolved
resource which need to fall back on blocks resolution will have to be
something like:
block:wiringname:...
The SourceResolver will have to look at the beginning (block:) and
understand that in needs to resolve the resource on the block's
resolver as "wiringname:...". If it begins with something else (cocoon:
for example) it will have to resolve in a different way...
The Resolver interface specifies that there's no contract between name
and the resource, maybe we could implement this in the
o.a.c.k.DeployedWirings class, change the interface, or whatever! :-)
Sorry for the confusion...
Pier