You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Geoff Howard <co...@leverageweb.com> on 2003/10/26 00:11:22 UTC
Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching Matcher.java
CookieMatcher.java
ghoward@apache.org wrote:
>ghoward 2003/10/25 14:59:50
>
> Modified: src/java/org/apache/cocoon/matching Matcher.java
> CookieMatcher.java
> Log:
> start fortressizing Matchers. lots of open questions already,
>
> so I'll pause here.
>
>
I'm hoping someone with more confidence in the changes needed can check
out the simple changes below. Such a paradigm shift to give up the
marker interfaces (and I'm mourning the loss of content assist. Don't
suppose an eclipse plugin for meta info yet?)
Open questions:
- What do sitemap components get for @x-avalon-info? A new made up
string like cookie-matcher? The @name/type from the default sitemap in
2.1?
- Will this mean we no longer have to declare sitemap components in the
sitemap?
- What about other lifecycle interfaces like: Contextualizable,
Parameterizable, Disposable?
Geoff
> Revision Changes Path
> 1.2 +2 -3 cocoon-2.2/src/java/org/apache/cocoon/matching/Matcher.java
>
> Index: Matcher.java
> ===================================================================
> RCS file: /home/cvs/cocoon-2.2/src/java/org/apache/cocoon/matching/Matcher.java,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- Matcher.java 9 Mar 2003 00:09:33 -0000 1.1
> +++ Matcher.java 25 Oct 2003 21:59:50 -0000 1.2
> @@ -50,7 +50,6 @@
> */
> package org.apache.cocoon.matching;
>
> -import org.apache.avalon.framework.component.Component;
> import org.apache.avalon.framework.parameters.Parameters;
> import org.apache.cocoon.sitemap.PatternException;
>
> @@ -61,7 +60,7 @@
> * @author <a href="mailto:Giacomo.Pati@pwr.ch">Giacomo Pati</a>
> * @version CVS $Id$
> */
> -public interface Matcher extends Component {
> +public interface Matcher {
>
> String ROLE = Matcher.class.getName();
>
>
>
>
> 1.3 +6 -1 cocoon-2.2/src/java/org/apache/cocoon/matching/CookieMatcher.java
>
> Index: CookieMatcher.java
> ===================================================================
> RCS file: /home/cvs/cocoon-2.2/src/java/org/apache/cocoon/matching/CookieMatcher.java,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- CookieMatcher.java 16 Mar 2003 17:49:15 -0000 1.2
> +++ CookieMatcher.java 25 Oct 2003 21:59:50 -0000 1.3
> @@ -66,6 +66,11 @@
> *
> * @author <a href="mailto:maciejka@tiger.com.pl">Maciek Kaminski</a>
> * @version CVS $Id$
> + *
> + * @avalon.component
> + * @avalon.service type="Matcher"
> + * @x-avalon.lifestyle type="pooled"
> + * @x-avalon.info name="cookie-matcher"
> */
> public class CookieMatcher extends AbstractLogEnabled implements Matcher {
>
>
>
>
>
>
>
>
>
Re: Questions about Meta Info (was Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching
Matcher.java CookieMatcher.java)
Posted by Berin Loritsch <bl...@apache.org>.
Geoff Howard wrote:
>>
>> It takes away the need for a separate ROLES file.
>
>
> Right, but we don't have our sitemap components in a roles file. We
> have them in <map:components> and it's not clear to me
> how this concept changes in 2.2.
It doesn't change a ton of things, but to be clear, you do have a roles
file embeded in the TreeBuilder definition for the sitemap components.
One thing that may make people happy (or not depending on your POV), is
that you will no longer *need* to include the "class" attribute for your
components. You can if you want, but it is not necessary. If the class
attribute is used, then it would take precedence over what was defined
in the meta info.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Questions about Meta Info (was Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching
Matcher.java CookieMatcher.java)
Posted by Geoff Howard <co...@leverageweb.com>.
Berin Loritsch wrote:
> Geoff Howard wrote:
>
>> I'm hoping someone with more confidence in the changes needed can
>> check out the simple changes below. Such a paradigm shift to give up
>> the marker interfaces (and I'm mourning the loss of content assist.
>> Don't suppose an eclipse plugin for meta info yet?)
>
>
> Content assist?
>
> Eclipse plugin: not at this time.
What I meant by content assist is that with marker interfaces, normal
java ide support got you content assist (auto completion, plus in
eclipse javadoc on hover)
for the Avalon stuff because interfaces are pure java. The meta-info
takes that away - just a minor annoyance really.
>> Open questions:
>> - What do sitemap components get for @x-avalon-info? A new made up
>> string like cookie-matcher? The @name/type from the default sitemap
>> in 2.1?
>
>
> The @x-avalon-info name="cookie-matcher" line lets you define your
> components
> like this:
>
> <cookie-matcher name="foo">
> <internal>configuration</internal>
> </cookie-matcher>
>
> It takes away the need for a separate ROLES file.
Right, but we don't have our sitemap components in a roles file. We
have them in <map:components> and it's not clear to me
how this concept changes in 2.2.
>> - Will this mean we no longer have to declare sitemap components in
>> the sitemap?
>
>
> More it means that there is no reason to have a ROLES file, which also
> means taht you can incorporate any component into Cocoon using a friendly
> configuration name without resorting to specifying user roles files or
> even internal roles files.
>
>> - What about other lifecycle interfaces like: Contextualizable,
>> Parameterizable, Disposable?
>
>
> They haven't changed. They actually have a reason to exist. They
> provide
> information or invoke an event on the component--unlike the marker
> interfaces
> that did nothing but mess with the class hierarchy.
gotcha.
Geoff
Re: Questions about Meta Info
Posted by Sylvain Wallez <sy...@apache.org>.
Berin Loritsch wrote:
> Sylvain Wallez wrote:
>
>> Berin Loritsch wrote:
>>
>>>> - What do sitemap components get for @x-avalon-info? A new made up
>>>> string like cookie-matcher? The @name/type from the default
>>>> sitemap in 2.1?
>>>
>>>
>>> The @x-avalon-info name="cookie-matcher" line lets you define your
>>> components
>>> like this:
>>>
>>> <cookie-matcher name="foo">
>>> <internal>configuration</internal>
>>> </cookie-matcher>
>>
>>
>> I must say that I'm not really convinced by this notation, as it
>> makes finding the various implementations or a service in an xconf
>> file somehow difficult, and even make the xconf file hardly
>> understandable unless you know the shortname for each and every
>> service implementation.
>
>
> How is it so different than what you see now in ECM based
> configurations, really? There is no real difference.
>
>> In the ECM, the hints were visible only _within_ a selector defining
>> the scope of these hints, e.g.:
>> <datasources>
>> <jdbc name="foo">...</jdbc>
>> <j2ee name="bar">...</j2ee>
>> </datasources>
>
>
> How many other component types are named "jdbc" or "j2ee"? It really
> isn't that hard.
>
>> If Fortress configurations are flat configurations with hints (or
>> x-avalon-info), knowing what kind of component an element declares
>> can be tricky. Furthermore, there's a non negligible probability of
>> name clashes on large systems.
>
>
> By default, but we can adapt it to handle the configuration file
> however you want. If it makes it easier for you to deal with
> <datasources> and a bunch of internal components, that can easily be
> accomodated.
AFAIU, this is required to keep the current format of <map:components>.
> Also if you adopt a few naming conventions there will be no real issue.
>
> For instance, the default naming convention for Fortress based
> components takes the Class Name (minus the package) and trnasform it
> into an "XML" name. Essentially an all lowercase name with hyphens to
> separate words.
> For example:
> CookieMatcher -> cookie-matcher
> FileGenerator -> file-generator
>
> It's not that difficult.
Agree, but maybe it's just too much automagic...
> Is there potential for name clashes? Absolutely. In practice
> however, the potential is a lot lower than you think.
And what happens in that case? An exception should be raised, otherwise
I guess the user will have no more hairs on his head when she finally
finds that the system doesn't behave as expected because the used class
isn't the one she expected...
> This style of managing component meta-info has been around for a
> while, and it is new to you. Give it a chance.
Yeah, I'm ok to give it a chance, but I'm wondering about the "too much
magic kills the confidence" syndrome : too much of today's xconf
structure is disappearing at once. And I think I'll miss the "class"
attribute...
>> Something that would be more readable IMO, is to have the hint as an
>> additional attribute, e.g.
>> <datasource type="jdbc" name="foo">...</datasource>
>> <datasource type="j2ee" name="bar">...</datasource>
>>
>> and accordingly:
>> <matcher type="cookie-matcher" name="foo">...</matcher>
>
>
> We can adapt the CocoonContainer type to handle this mapping--but is
> it really more readable? It is more verbose than say:
>
> <jdbc-datasource name="foo"/>
> <j2ee-datasource name="bar"/>
>
> Which is what is the more normal convention.
Mmmh... Yep, that's better than just "jdbc" or "j2ee". And you're right
that most often an implementation class name ends with the name of the
service interface it implements.
We'll see... But I'm still afraid that, although containing less class
names, the "flat bag" organization of the new xconf file will frighten
users to touch it even more than the current one that is full of class
names.
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Questions about Meta Info
Posted by Berin Loritsch <bl...@apache.org>.
Geoff Howard wrote:
> Berin Loritsch wrote:
>
>>> What this means is that the @x-avalon-info should be considered
>>> differently for service interfaces (element name) and for classes
>>> ("type" attribute).
>>
>>
>>
>> No, it means that your interpretation of the configuration to get
>> at the short name would be different.
>
>
>
> Is there an easy way to find out what real class a given shortcut/role
> is associated with (resolving to)? In
> digging into things in Cocoon now I and I'm sure others grep through the
> roles file and cocoon.xconf to find
> where to look for a given implementation. I'm thinking it would be good
> to provide some way to trace back
> from a hint name or service type back to the concrete class.
When Fortress starts up, it spits out all that info in the log file.
However look at this as a strength. Not too long ago I refactored some
libraries for my GUIApp application to put all the code in a different package.
With ECM, I would have to change the packages, change the roles file, and
hope that there were no conflicts between role files. If the class name
were listed in a configuration file, then I would have to change that as well.
With Fortress, I only had to use the IDE's move refactoring support and the
same configuration worked with the new code--no other edits necessary.
It truly does bring more benefits than liabilities.
> Also, the roles file defines default implementation which can be
> overridden in xconf. Is this the same in fortress? If I want to replace
> the default implementation of transient-store with my own souped up
> version (you'll need to
> momentarily suspend your disbelief that I'm capable of coming up with
> one ;) ) how do I do that?
> Geoff
Yes, the xconf does allow you to override things--but what real-world
requirements would require that to happen? I've been doing this for
years, and I can't really think of a reason.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Questions about Meta Info
Posted by Geoff Howard <co...@leverageweb.com>.
Berin Loritsch wrote:
>> What this means is that the @x-avalon-info should be considered
>> differently for service interfaces (element name) and for classes
>> ("type" attribute).
>
>
> No, it means that your interpretation of the configuration to get
> at the short name would be different.
Is there an easy way to find out what real class a given shortcut/role
is associated with (resolving to)? In
digging into things in Cocoon now I and I'm sure others grep through the
roles file and cocoon.xconf to find
where to look for a given implementation. I'm thinking it would be good
to provide some way to trace back
from a hint name or service type back to the concrete class.
Also, the roles file defines default implementation which can be
overridden in xconf. Is this the same in fortress?
If I want to replace the default implementation of transient-store with
my own souped up version (you'll need to
momentarily suspend your disbelief that I'm capable of coming up with
one ;) ) how do I do that?
Geoff
Re: Questions about Meta Info
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Berin Loritsch wrote:
>
>>> - What do sitemap components get for @x-avalon-info? A new made up
>>> string like cookie-matcher? The @name/type from the default sitemap
>>> in 2.1?
>>
>> The @x-avalon-info name="cookie-matcher" line lets you define your
>> components
>> like this:
>>
>> <cookie-matcher name="foo">
>> <internal>configuration</internal>
>> </cookie-matcher>
>
> I must say that I'm not really convinced by this notation, as it makes
> finding the various implementations or a service in an xconf file
> somehow difficult, and even make the xconf file hardly understandable
> unless you know the shortname for each and every service implementation.
How is it so different than what you see now in ECM based configurations,
really? There is no real difference.
> In the ECM, the hints were visible only _within_ a selector defining the
> scope of these hints, e.g.:
> <datasources>
> <jdbc name="foo">...</jdbc>
> <j2ee name="bar">...</j2ee>
> </datasources>
How many other component types are named "jdbc" or "j2ee"? It really
isn't that hard.
> If Fortress configurations are flat configurations with hints (or
> x-avalon-info), knowing what kind of component an element declares can
> be tricky. Furthermore, there's a non negligible probability of name
> clashes on large systems.
By default, but we can adapt it to handle the configuration file however
you want. If it makes it easier for you to deal with <datasources>
and a bunch of internal components, that can easily be accomodated.
Also if you adopt a few naming conventions there will be no real issue.
For instance, the default naming convention for FOrtress based components
takes the Class Name (minus the package) and trnasform it into an "XML"
name. Essentially an all lowercase name with hyphens to separate words.
For example:
CookieMatcher -> cookie-matcher
FileGenerator -> file-generator
It's not that difficult.
Is there potential for name clashes? Absolutely. In practice however,
the potential is a lot lower than you think. This style of managing
component meta-info has been around for a while, and it is new to you.
Give it a chance.
> Something that would be more readable IMO, is to have the hint as an
> additional attribute, e.g.
> <datasource type="jdbc" name="foo">...</datasource>
> <datasource type="j2ee" name="bar">...</datasource>
>
> and accordingly:
> <matcher type="cookie-matcher" name="foo">...</matcher>
We can adapt the CocoonContainer type to handle this mapping--but is
it really more readable? It is more verbose than say:
<jdbc-datasource name="foo"/>
<j2ee-datasource name="bar"/>
Which is what is the more normal convention.
> What this means is that the @x-avalon-info should be considered
> differently for service interfaces (element name) and for classes
> ("type" attribute).
No, it means that your interpretation of the configuration to get
at the short name would be different.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Questions about Meta Info (was Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching
Matcher.java CookieMatcher.java)
Posted by Sylvain Wallez <sy...@apache.org>.
Berin Loritsch wrote:
> Geoff Howard wrote:
>
>> ghoward@apache.org wrote:
>>
>>> ghoward 2003/10/25 14:59:50
>>>
>>> Modified: src/java/org/apache/cocoon/matching Matcher.java
>>> CookieMatcher.java
>>> Log:
>>> start fortressizing Matchers. lots of open questions already, so
>>> I'll pause here.
>>
>>
>> I'm hoping someone with more confidence in the changes needed can
>> check out the simple changes below. Such a paradigm shift to give up
>> the marker interfaces (and I'm mourning the loss of content assist.
>> Don't suppose an eclipse plugin for meta info yet?)
>
>
> Content assist?
>
> Eclipse plugin: not at this time.
>
>> Open questions:
>> - What do sitemap components get for @x-avalon-info? A new made up
>> string like cookie-matcher? The @name/type from the default sitemap
>> in 2.1?
>
>
> The @x-avalon-info name="cookie-matcher" line lets you define your
> components
> like this:
>
> <cookie-matcher name="foo">
> <internal>configuration</internal>
> </cookie-matcher>
I must say that I'm not really convinced by this notation, as it makes
finding the various implementations or a service in an xconf file
somehow difficult, and even make the xconf file hardly understandable
unless you know the shortname for each and every service implementation.
In the ECM, the hints were visible only _within_ a selector defining the
scope of these hints, e.g.:
<datasources>
<jdbc name="foo">...</jdbc>
<j2ee name="bar">...</j2ee>
</datasources>
If Fortress configurations are flat configurations with hints (or
x-avalon-info), knowing what kind of component an element declares can
be tricky. Furthermore, there's a non negligible probability of name
clashes on large systems.
Something that would be more readable IMO, is to have the hint as an
additional attribute, e.g.
<datasource type="jdbc" name="foo">...</datasource>
<datasource type="j2ee" name="bar">...</datasource>
and accordingly:
<matcher type="cookie-matcher" name="foo">...</matcher>
What this means is that the @x-avalon-info should be considered
differently for service interfaces (element name) and for classes
("type" attribute).
> It takes away the need for a separate ROLES file.
>
>> - Will this mean we no longer have to declare sitemap components in
>> the sitemap?
>
>
> More it means that there is no reason to have a ROLES file, which also
> means taht you can incorporate any component into Cocoon using a
> friendly configuration name without resorting to specifying user roles
> files or even internal roles files.
>
>> - What about other lifecycle interfaces like: Contextualizable,
>> Parameterizable, Disposable?
>
>
> They haven't changed. They actually have a reason to exist. They
> provide information or invoke an event on the component--unlike the
> marker interfaces that did nothing but mess with the class hierarchy.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Questions about Meta Info
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Berin:
>
> What is you plan concerning migration to the @avalon tags?
> http://avalon.apache.org/meta/tools/tags/
>
Take it one step at a time.
1) Get Cocoon 2.2 to a workable state with Fortress as is.
2) Finish upgrades to Fortress to allow meta tags integration.
3) With all the meta info already available for each component
finish the upgrade process seamlessly.
At that time, there should be far less dependence on any one container
(though there still will be some).
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Questions about Meta Info
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Geoff Howard wrote:
>
>> ghoward@apache.org wrote:
>>
>>> ghoward 2003/10/25 14:59:50
>>>
>>> Modified: src/java/org/apache/cocoon/matching Matcher.java
>>> CookieMatcher.java
>>> Log:
>>> start fortressizing Matchers. lots of open questions already,
>>> so I'll pause here.
>>>
>>>
>>
>> I'm hoping someone with more confidence in the changes needed can
>> check out the simple changes below. Such a paradigm shift to give up
>> the marker interfaces (and I'm mourning the loss of content assist.
>> Don't suppose an eclipse plugin for meta info yet?)
>
>
> Content assist?
>
> Eclipse plugin: not at this time.
>
>>
>> Open questions:
>> - What do sitemap components get for @x-avalon-info? A new made up
>> string like cookie-matcher? The @name/type from the default sitemap
>> in 2.1?
>
>
> The @x-avalon-info name="cookie-matcher" line lets you define your
> components
> like this:
>
> <cookie-matcher name="foo">
> <internal>configuration</internal>
> </cookie-matcher>
>
> It takes away the need for a separate ROLES file.
Berin:
What is you plan concerning migration to the @avalon tags?
http://avalon.apache.org/meta/tools/tags/
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Questions about Meta Info (was Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching
Matcher.java CookieMatcher.java)
Posted by Berin Loritsch <bl...@apache.org>.
Geoff Howard wrote:
> ghoward@apache.org wrote:
>
>> ghoward 2003/10/25 14:59:50
>>
>> Modified: src/java/org/apache/cocoon/matching Matcher.java
>> CookieMatcher.java
>> Log:
>> start fortressizing Matchers. lots of open questions already,
>> so I'll pause here.
>>
>>
>
> I'm hoping someone with more confidence in the changes needed can check
> out the simple changes below. Such a paradigm shift to give up the
> marker interfaces (and I'm mourning the loss of content assist. Don't
> suppose an eclipse plugin for meta info yet?)
Content assist?
Eclipse plugin: not at this time.
>
> Open questions:
> - What do sitemap components get for @x-avalon-info? A new made up
> string like cookie-matcher? The @name/type from the default sitemap in
> 2.1?
The @x-avalon-info name="cookie-matcher" line lets you define your components
like this:
<cookie-matcher name="foo">
<internal>configuration</internal>
</cookie-matcher>
It takes away the need for a separate ROLES file.
> - Will this mean we no longer have to declare sitemap components in
> the sitemap?
More it means that there is no reason to have a ROLES file, which also
means taht you can incorporate any component into Cocoon using a friendly
configuration name without resorting to specifying user roles files or
even internal roles files.
> - What about other lifecycle interfaces like: Contextualizable,
> Parameterizable, Disposable?
They haven't changed. They actually have a reason to exist. They provide
information or invoke an event on the component--unlike the marker interfaces
that did nothing but mess with the class hierarchy.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin