You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/02/11 19:42:10 UTC
Component <> Object (and never will be).
Folks,
Berin is putting up a good fight against the changes (as we present
them) being talked about. Being proposed is JNDI as an alternative.
<footnote>One reason I started EOB was because I wanted a one line
CompMgr style lookup for *anything* and dislike the wieght of JNDI in
its usage</footnote>. Reading Berin's opinion it seems that
ComponentManager is still the preferred tool for Components and that if
there is something else needed, it is for non-components.
Perhaps this is true, and there is no overlap. Perhaps a completely
fresh (not clone) package is required for non-components. It could
serve the needs of Object lookup and be reusable or reimplementable by
Stephen's CORBA work in Cornerstone, EOB (sourceforge) and Peter's needs.
We could roll in some naming contexts. I.e. "jndi:", "phoenix:",
<insert Stephen's needs> <insert Peter's needs>
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Berin,
I didn't read this before replying to your previous mail. I introduced a
few ideas that address some of the same issues you've discussed here,
but I hope you also consider my suggestions.
(: A ;)
Berin Loritsch wrote:
> Berin Loritsch wrote:
>
>> Antti Koivunen wrote:
>
>
>>> Is it intended to replace CM/CS?
>>
>>
>>
>> IMO Yes.
>
>
> At least on a smooth migration path
>
>
> Please take a look at the Resolver package with an updated API. The
> API reflects Antti's well thought out responses.
>
>
>
>>>> Please, I am soliciting feedback on the proposal, so we can see if it
>>>> fits all our needs.
>>>
>>>
>>>
>>> A few ideas...
>>>
>>> 3. I would consider string (e.g. URI) lookups in addition to the
>>> heavier Query structure. Some examples:
>>>
>>> uri://domain.com/services/UserManager
>>>
>>> uri://domain.com/User?id=42
>>> uri://domain.com/User[lastName=Doe,firstName=Jane]
>>>
>>> Service:type=UserMgmt,country=FI (JMX style)
>>
>>
>>
>> Sounds reasonable
>
>
> Looking at this in more detail, it looks as if it can replace the need for
> the Excalibur Resolver package as well as the differentiating between
> Component/Service/Object/etc. I like this approach, and even changed the
> Query object's interface to reflect the URI approach.
>
>
>
>>> (All of these could be represented with an object, if necessary. See
>>> e.g. javax.management.ObjectName)
>>>
>>> 4. In Token: Object[] references() -> Iterator references(), not to
>>> restrict the implementation (e.g. in case there are MANY references).
>>
>>
>>
>> There shouldn't be *that* many references that you retrieve at one time.
>> In practice, I have not seen more than 5-6 external components used.
>> Even then, that is bordering on being too coupled.
>
>
> I added this as another alternative (along with a simple Object return
> value for the more direct resolve uri approach)
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> Antti Koivunen wrote:
>> Is it intended to replace CM/CS?
>
>
> IMO Yes.
At least on a smooth migration path
Please take a look at the Resolver package with an updated API. The
API reflects Antti's well thought out responses.
>>> Please, I am soliciting feedback on the proposal, so we can see if it
>>> fits all our needs.
>>
>>
>> A few ideas...
>>
>> 3. I would consider string (e.g. URI) lookups in addition to the
>> heavier Query structure. Some examples:
>>
>> uri://domain.com/services/UserManager
>>
>> uri://domain.com/User?id=42
>> uri://domain.com/User[lastName=Doe,firstName=Jane]
>>
>> Service:type=UserMgmt,country=FI (JMX style)
>
>
> Sounds reasonable
Looking at this in more detail, it looks as if it can replace the need for
the Excalibur Resolver package as well as the differentiating between
Component/Service/Object/etc. I like this approach, and even changed the
Query object's interface to reflect the URI approach.
>> (All of these could be represented with an object, if necessary. See
>> e.g. javax.management.ObjectName)
>>
>> 4. In Token: Object[] references() -> Iterator references(), not to
>> restrict the implementation (e.g. in case there are MANY references).
>
>
> There shouldn't be *that* many references that you retrieve at one time.
> In practice, I have not seen more than 5-6 external components used.
> Even then, that is bordering on being too coupled.
I added this as another alternative (along with a simple Object return
value for the more direct resolve uri approach)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Berin Loritsch wrote:
> Antti Koivunen wrote:
>
>> Berin Loritsch wrote:
>> > Let's take a quick look at both of these.
>>
>> JNDI is an interface for naming services. It's not meant just for
>> component management, but provides a convenient (and popular) way of
>> handling it.
>
>
> And it can be used to resolve CORBA requests (with the right Context)
Yes, of course.
>> CORBA is meant primarily for managing and sharing objects (including
>> components) in distributed environments.
>>
>> Now, as both of these are commonly used for managing components, it
>> should be made easy to integrate either one in the core Avalon
>> component management.
>>
>> The issue of Component vs. Object really comes down to the following
>> question: should an object be required to implement an empty marker
>> interface to be regarded as a component (thus making integration with
>> other systems more difficult)? I think not.
>
>
> We agree on this point.
Nice to hear :)
>>> That is why I proposed the resolver interfaces, to solicit feedback on
>>> that. Is this something that will satisfy everyone's need? I think it
>>> will be a much better fit than even the current CM/CS approach we have
>>> now.
>>
>>
>> Is it intended to replace CM/CS?
>
>
> IMO Yes.
Ah, good, this clears things up. Something like the Resolver is
definitely needed, thanks for introducing the idea.
AIU, this also means that the system must be capable of handling the
lifecycle states, as well. I wonder if it would make sense to make this
more generic, i.e. to allow some custom handling for certain types of
objects (might be FS).
>> 3. I would consider string (e.g. URI) lookups in addition to the
>> heavier Query structure. Some examples:
>>
>> uri://domain.com/services/UserManager
>>
>> uri://domain.com/User?id=42
>> uri://domain.com/User[lastName=Doe,firstName=Jane]
>>
>> Service:type=UserMgmt,country=FI (JMX style)
>
>
> Sounds reasonable
Good. At some stage, we should probably specify a common syntax.
>> 4. In Token: Object[] references() -> Iterator references(), not to
>> restrict the implementation (e.g. in case there are MANY references).
>
>
> There shouldn't be *that* many references that you retrieve at one time.
> In practice, I have not seen more than 5-6 external components used.
> Even then, that is bordering on being too coupled.
True, if only individual references are returned (as currently implied
by the Query interface). If we don't (ever) intend allow something like
"services/*", this shouldn't be an issue.
In that case, it might be more of a 'NameSet' than a Query, as we only
retrieve 'identifiable' objects (see javax.management.ObjectName and
javax.management.Query). Or even better, we could have something like:
ObjectName name = new ObjectName("query"); // checks the syntax
name.setAttribute("name", "value"); // customize
And have Resolver provide the methods:
Token lookup(ObjectName name);
Token lookup(ObjectName[] names);
Token lookup(String query); // implicit new ObjectName()
Token lookup(String[] queries); // implicit new ObjectName[]
This would also allow attributes to be set on an object level, which I
think is necessary (see the example URIs in question 3. above).
ObjectName would naturally provide efficient implementations for
hashCode() and equals(), so that
name.equals(new ObjectName(name.toString())) == true
>> 5. What are the benefits of differentiating COMPONENT, SERVICE and
>> OBJECT?
>>
>> (: A ;)
>
>
> The main difference is how the key is expected to be resolved. The big
> thing
> is that the Resolver implementation will likely differ lookup to the
> Container.
> This is a good thing. The Container may have different repositories for
> each
> of these. (Although the merging of Component and Service would probably
> work).
> Lastly, it allows a Resolver to lookup Components from the Container,
> Services
> from the Phoenix Kernel, and Objects from whatever is local to the Resolver
> implementation.
I see. It's a good idea, but I can't help thinking that this should
perhaps be a bit more generic, i.e. subject to Resolver configuration.
Especially since the division between objects, components and services
tends to be a little vague (everything returned by Resolver is an
object). The idea could also be combined with the query syntax, e.g. by
using certain prefixes. The JMX approach
[domainName]:property=value[,property=value]*
might work quite nicely here, with the following contracts:
ObjectName : Check the syntax and 'compile' the 'query'.
Resolver : Delegate to the correct 'DomainManager'.
DomainManager : Provide the object (defined by the ObjectName).
This would basically just add the following operation:
DomainManager dm = (DomainManager) managers.get(objName.getDomain());
and allow e.g. "Service:", "Phoenix:", "MySecretPlace:", or whatever...
Thoughts?
(: A ;)
--
Antti Koivunen | "Anrie" [un-ree] <an...@users.sf.net>
---------------------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Component <> Object (and never will be).
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>
> Antti Koivunen wrote:
> > Berin Loritsch wrote:
> > > Let's take a quick look at both of these.
> >
> > JNDI is an interface for naming services. It's not meant just for
> > component management, but provides a convenient (and popular) way of
> > handling it.
>
> And it can be used to resolve CORBA requests (with the right Context)
>
> >
> > CORBA is meant primarily for managing and sharing objects (including
> > components) in distributed environments.
> >
> > Now, as both of these are commonly used for managing components, it
> > should be made easy to integrate either one in the core Avalon
> component
> > management.
> >
> > The issue of Component vs. Object really comes down to the following
> > question: should an object be required to implement an empty marker
> > interface to be regarded as a component (thus making integration with
> > other systems more difficult)? I think not.
>
> We agree on this point.
I think we all agree on this point.
What we don't appear to agree on is the approach to correcting that anomaly.
Berin your proposing a fresh new approach which IMO is substantially heavier
than the current approach - and that makes me feel uncomfortable because the
current CM/SM approach matches my needs very nicely.
> >> That is why I proposed the resolver interfaces, to solicit feedback on
> >> that. Is this something that will satisfy everyone's need? I think it
> >> will be a much better fit than even the current CM/CS approach we have
> >> now.
> >
> > Is it intended to replace CM/CS?
>
> IMO Yes.
IMO No - its something else.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Berin Loritsch <bl...@apache.org>.
Antti Koivunen wrote:
> Berin Loritsch wrote:
> > Let's take a quick look at both of these.
>
> JNDI is an interface for naming services. It's not meant just for
> component management, but provides a convenient (and popular) way of
> handling it.
And it can be used to resolve CORBA requests (with the right Context)
>
> CORBA is meant primarily for managing and sharing objects (including
> components) in distributed environments.
>
> Now, as both of these are commonly used for managing components, it
> should be made easy to integrate either one in the core Avalon component
> management.
>
> The issue of Component vs. Object really comes down to the following
> question: should an object be required to implement an empty marker
> interface to be regarded as a component (thus making integration with
> other systems more difficult)? I think not.
We agree on this point.
>> That is why I proposed the resolver interfaces, to solicit feedback on
>> that. Is this something that will satisfy everyone's need? I think it
>> will be a much better fit than even the current CM/CS approach we have
>> now.
>
> Is it intended to replace CM/CS?
IMO Yes.
>
>> Please, I am soliciting feedback on the proposal, so we can see if it
>> fits all our needs.
>
> A few ideas...
>
> 1. Resolveable -> Resolvable (to make it more English :)
Ok.
>
> 2. resolver(Resolver) -> setResolver(Resolver), to make it more
> intuitive (consider e.g. iterator()).
Ok.
>
> 3. I would consider string (e.g. URI) lookups in addition to the heavier
> Query structure. Some examples:
>
> uri://domain.com/services/UserManager
>
> uri://domain.com/User?id=42
> uri://domain.com/User[lastName=Doe,firstName=Jane]
>
> Service:type=UserMgmt,country=FI (JMX style)
Sounds reasonable
>
> (All of these could be represented with an object, if necessary. See
> e.g. javax.management.ObjectName)
>
> 4. In Token: Object[] references() -> Iterator references(), not to
> restrict the implementation (e.g. in case there are MANY references).
There shouldn't be *that* many references that you retrieve at one time.
In practice, I have not seen more than 5-6 external components used.
Even then, that is bordering on being too coupled.
>
> 5. What are the benefits of differentiating COMPONENT, SERVICE and OBJECT?
>
> (: A ;)
The main difference is how the key is expected to be resolved. The big thing
is that the Resolver implementation will likely differ lookup to the Container.
This is a good thing. The Container may have different repositories for each
of these. (Although the merging of Component and Service would probably work).
Lastly, it allows a Resolver to lookup Components from the Container, Services
from the Phoenix Kernel, and Objects from whatever is local to the Resolver
implementation.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Berin Loritsch wrote:
> My main points have always been that we shouldn't be too hasty just because
> we have a possible solution (out of many).
I totally agree, especially when it comes to framework design, but I
also think we should all be open-minded for new ideas and even
fundamental changes to the API, if it improves the overall quality and
usability of the framework.
> Notice that I also did not put up a fight without proposing a solution.
> It is true that Object != Component (although the reverse is true).
>
> With an ORB, there is another naming and lookup service that is part of
> the CORBA spec--for those, it would be better to handle references through
> that.
>
> I understand the desire, and even need for having one unified way of
> looking up object references--that is simple and elegant, and can differ
> to the heavier JNDI and ORB Naming service.
Let's take a quick look at both of these.
JNDI is an interface for naming services. It's not meant just for
component management, but provides a convenient (and popular) way of
handling it.
CORBA is meant primarily for managing and sharing objects (including
components) in distributed environments.
Now, as both of these are commonly used for managing components, it
should be made easy to integrate either one in the core Avalon component
management.
The issue of Component vs. Object really comes down to the following
question: should an object be required to implement an empty marker
interface to be regarded as a component (thus making integration with
other systems more difficult)? I think not.
> That is why I proposed the resolver interfaces, to solicit feedback on
> that. Is this something that will satisfy everyone's need? I think it
> will be a much better fit than even the current CM/CS approach we have
> now.
Is it intended to replace CM/CS?
> Please, I am soliciting feedback on the proposal, so we can see if it
> fits all our needs.
A few ideas...
1. Resolveable -> Resolvable (to make it more English :)
2. resolver(Resolver) -> setResolver(Resolver), to make it more
intuitive (consider e.g. iterator()).
3. I would consider string (e.g. URI) lookups in addition to the heavier
Query structure. Some examples:
uri://domain.com/services/UserManager
uri://domain.com/User?id=42
uri://domain.com/User[lastName=Doe,firstName=Jane]
Service:type=UserMgmt,country=FI (JMX style)
(All of these could be represented with an object, if necessary. See
e.g. javax.management.ObjectName)
4. In Token: Object[] references() -> Iterator references(), not to
restrict the implementation (e.g. in case there are MANY references).
5. What are the benefits of differentiating COMPONENT, SERVICE and OBJECT?
(: A ;)
--
Antti Koivunen | "Anrie" [un-ree] <an...@users.sf.net>
---------------------------------------------------------
Happiness isn't about having everything you want;
it's about wanting everything you have.
---------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Component <> Object (and never will be).
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
[snip]
> >
> > That is why I proposed the resolver interfaces, to solicit feedback on
> > that. Is this something that will satisfy everyone's need?
>
> Swap "resolve" for "resolver" method name in Resolverable interface ?
> (better English?)
>
> I think for my needs the Query object is overkill. 99% of the time EOB
> will simply lookup a simple string term : "StockQuoteFacade"
Same case here.
The CM/SM simple name lookup, decommissioning and
cascading semantics really suite my needs in the implementatation
cases we are dealing with.
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
>> Berin is putting up a good fight against the changes (as we present
>> them) being talked about. Being proposed is JNDI as an alternative.
>> <footnote>One reason I started EOB was because I wanted a one line
>> CompMgr style lookup for *anything* and dislike the wieght of JNDI in
>> its usage</footnote>. Reading Berin's opinion it seems that
>> ComponentManager is still the preferred tool for Components and that
>> if there is something else needed, it is for non-components.
>>
>> Perhaps this is true, and there is no overlap. Perhaps a completely
>> fresh (not clone) package is required for non-components. It could
>> serve the needs of Object lookup and be reusable or reimplementable
>> by Stephen's CORBA work in Cornerstone, EOB (sourceforge) and Peter's
>> needs.
>>
>> We could roll in some naming contexts. I.e. "jndi:", "phoenix:",
>> <insert Stephen's needs> <insert Peter's needs>
>
>
>
> My main points have always been that we shouldn't be too hasty just
> because
> we have a possible solution (out of many).
>
> Notice that I also did not put up a fight without proposing a solution.
> It is true that Object != Component (although the reverse is true).
My feeling is that although physically Comp is an Obj, it is
intellectually different, given your case. As such if we defined an
Object (rather than Compoent) orientated form of lookup, we should not
deprecate the ComponentManager as the two are different. I.e. this is
not an evolution or a "fix" to an original design, it is different.
> With an ORB, there is another naming and lookup service that is part of
> the CORBA spec--for those, it would be better to handle references
> through
> that.
>
> I understand the desire, and even need for having one unified way of
> looking up object references--that is simple and elegant, and can differ
> to the heavier JNDI and ORB Naming service.
>
> That is why I proposed the resolver interfaces, to solicit feedback on
> that. Is this something that will satisfy everyone's need?
Swap "resolve" for "resolver" method name in Resolverable interface ?
(better English?)
I think for my needs the Query object is overkill. 99% of the time EOB
will simply lookup a simple string term : "StockQuoteFacade"
Could we have an additonal design inspired by URLs (http:// rmi://
jdbc:// ) Perhaps internally it could be run through a factory to make
a Query object. Perhaps that factory is pluggable or chainable.
In EOB, I allow an escape like so "phoenix:web-server" to allow access
to Jo! If there is no prefix, then the assumption is that it is an
internal EOB lookup. Of course it hosts multiple applications (or
multiple versions of the same application) so it is important that it
establishes an application context on the outgoing lookup. Thus for me
(hack) it prepends the application name and a dash to the lookup on the
way to the bean respoitory. It is, so far, a cheap naming convention
solution. Perhaps the impl of the Resolver interface could take a
setContext(..) method.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>>http://www.uoregon.edu/~ftepfer/SchlFacilities/TireSwingTable.html ( I
>>can;t believe there is only one version of this famous cartoon on the web )
>>
>
>ooer - I just aquired some new material for my next meeting ;)
>
It will be too hard to understand for the PHB :-(
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Peter Donald <pe...@apache.org>.
On Wed, 13 Feb 2002 20:03, Paul Hammant wrote:
> http://www.uoregon.edu/~ftepfer/SchlFacilities/TireSwingTable.html ( I
> can;t believe there is only one version of this famous cartoon on the web )
ooer - I just aquired some new material for my next meeting ;)
--
Cheers,
Pete
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Component <> Object (and never will be).
Posted by Stephen McConnell <mc...@apache.org>.
ROTFL.
I just love senior analyst!!
Steve.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Wednesday, 13 February, 2002 10:04
> To: Avalon Developers List
> Subject: Re: Component <> Object (and never will be).
>
>
> Stephen
>
> >I'm didn't want to go down the path of exploring possible solution. I'll
> >restate this again - SM is a very minor generalisation of CM. It isn't
> >introducing any new concepts. In fact the model of CM suits that
> >application cases I'm concerning with - its the implementation
> restriction
> >concerning the Component interface usage which is being addressed.
> >
> I could not agree more. The Query / ObjectName stuff being proposed
> discussed in this thread and related are scaring me. What I want is :
>
> Object methodName(String nameOrSomething) throws SomeException;
>
> http://www.uoregon.edu/~ftepfer/SchlFacilities/TireSwingTable.html ( I
> can;t believe there is only one version of this famous cartoon on
> the web )
>
> - PH
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen
>I'm didn't want to go down the path of exploring possible solution. I'll
>restate this again - SM is a very minor generalisation of CM. It isn't
>introducing any new concepts. In fact the model of CM suits that
>application cases I'm concerning with - its the implementation restriction
>concerning the Component interface usage which is being addressed.
>
I could not agree more. The Query / ObjectName stuff being proposed
discussed in this thread and related are scaring me. What I want is :
Object methodName(String nameOrSomething) throws SomeException;
http://www.uoregon.edu/~ftepfer/SchlFacilities/TireSwingTable.html ( I
can;t believe there is only one version of this famous cartoon on the web )
- PH
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExclaliburComponentManager
Posted by Vincent Tencé <Vi...@gemplus.com>.
You're right. Thx.
I just run some tests with Catalina, and the problem doesn't occur. So I
guess
the context class loader is set properly in Tomcat 4.0.1. This fixes the
problem.
Thx for your help.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, February 13, 2002 11:07 AM
> To: Avalon Developers List
> Subject: Re: ExclaliburComponentManager
>
>
> Vincent Tencé wrote:
> > Unfortunatly
> >
> >
> >>super(this.getClass().getClassLoader());
> >>
> >
> > doesn't work cause It seems I cannot call getClass() before
> the super
> > constructor returns :-/
>
> You can do it through the static method:
>
> ComponentManager.class.getClassLoader();
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExclaliburComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Vincent Tencé wrote:
> Unfortunatly
>
>
>>super(this.getClass().getClassLoader());
>>
>
> doesn't work cause It seems I cannot call getClass() before the super
> constructor returns :-/
You can do it through the static method:
ComponentManager.class.getClassLoader();
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExclaliburComponentManager
Posted by Vincent Tencé <Vi...@gemplus.com>.
Unfortunatly
> super(this.getClass().getClassLoader());
doesn't work cause It seems I cannot call getClass() before the super
constructor returns :-/
Vincent
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, February 13, 2002 9:33 AM
> To: Avalon Developers List
> Subject: Re: ExclaliburComponentManager
>
>
> Vincent Tencé wrote:
>
>
> <snip/>
>
>
> > So far I am very happy with the results! It's a way to
> enforce usage of best
> > practises and patterns
> > in our work and we can leverage the work that has been put
> into Avalon. Thx
> > for that.
> > We are learning a lot from the code we use and we can feel
> the benefits of
> > using patterns like IoC and SoC.
>
> Glad to hear it.
>
> >
> > Now the problem :-) and the question. Somehow with Tomcat
> (maybe only 3.2.3)
> > the context class loader
> > cannot find my classes so we have to use
> getClass().getClassLoader(). It's
> > an issue since in a lot
> > of the excalibur code the context class loader is used by default.
>
> This has to do with actually setting the ContextClassloader.
> Cocoon handles this
> in the Servlet's service() method by explicitly calling
>
> Thread.currentThread().setContextClassLoader(this.classloader);
>
> with every request (handles new threads that are introduced.
>
>
>
> > I guess there are workarounds, and we had to think of one for
> > ExcaliburComponentSelector. We want
> > to use a selector in our roles.xml file but
> ExcaliburComponentSelector
> > cannot find any classes of the
> > webapp.
> > So we overrided ExcaliburComponentManager like this (not
> very clean) and
> > used that class instead:
> >
> > public class DefaultComponentSelector extends
> ExcaliburComponentSelector {
> >
> > private static Class clazz;
> >
> > static {
> > clazz = new HackClass().getClass();
> > }
> >
> > public DefaultComponentSelector() {
> > super(clazz.getClassLoader());
> > }
> >
> > private static class HackClass {
> > }
> > }
>
>
> You can also do this:
>
> super(this.getClass().getClassLoader());
>
> That works as well.
>
>
>
>
> > I wanted to know I you have also experienced that problem
> when using Avalon
> > with servlet containers.
> > Is it a tomcat issue? I am not very familiar with class
> loader issues. Is
> > there a better way
> > to get the same result than the hack code above? What is
> the preferred way
> > of doing things here?
> >
> > Btw, I guess there is mistake in the paper Developping with
> Apache Avalon at
> > bottom of page 39 (pdf format).
> > There is an example of an xml configuration file and it
> says that when you
> > have multiple instances
> > of a component you specify the instance name with the
> "hint" keyword but the
> > code is expecting "name" instead.
> >
> > Thanks for your answers,
> > Vincent
> >
> > Hope everybody will understand my English :)
>
>
> Hopefully my answers helped you :)
>
>
> --
>
> "They that give up essential liberty to obtain a little
> temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExclaliburComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Vincent Tencé wrote:
<snip/>
> So far I am very happy with the results! It's a way to enforce usage of best
> practises and patterns
> in our work and we can leverage the work that has been put into Avalon. Thx
> for that.
> We are learning a lot from the code we use and we can feel the benefits of
> using patterns like IoC and SoC.
Glad to hear it.
>
> Now the problem :-) and the question. Somehow with Tomcat (maybe only 3.2.3)
> the context class loader
> cannot find my classes so we have to use getClass().getClassLoader(). It's
> an issue since in a lot
> of the excalibur code the context class loader is used by default.
This has to do with actually setting the ContextClassloader. Cocoon handles this
in the Servlet's service() method by explicitly calling
Thread.currentThread().setContextClassLoader(this.classloader);
with every request (handles new threads that are introduced.
> I guess there are workarounds, and we had to think of one for
> ExcaliburComponentSelector. We want
> to use a selector in our roles.xml file but ExcaliburComponentSelector
> cannot find any classes of the
> webapp.
> So we overrided ExcaliburComponentManager like this (not very clean) and
> used that class instead:
>
> public class DefaultComponentSelector extends ExcaliburComponentSelector {
>
> private static Class clazz;
>
> static {
> clazz = new HackClass().getClass();
> }
>
> public DefaultComponentSelector() {
> super(clazz.getClassLoader());
> }
>
> private static class HackClass {
> }
> }
You can also do this:
super(this.getClass().getClassLoader());
That works as well.
> I wanted to know I you have also experienced that problem when using Avalon
> with servlet containers.
> Is it a tomcat issue? I am not very familiar with class loader issues. Is
> there a better way
> to get the same result than the hack code above? What is the preferred way
> of doing things here?
>
> Btw, I guess there is mistake in the paper Developping with Apache Avalon at
> bottom of page 39 (pdf format).
> There is an example of an xml configuration file and it says that when you
> have multiple instances
> of a component you specify the instance name with the "hint" keyword but the
> code is expecting "name" instead.
>
> Thanks for your answers,
> Vincent
>
> Hope everybody will understand my English :)
Hopefully my answers helped you :)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExclaliburComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 13 Feb 2002 10:02, Vincent Tencé wrote:
>
>>I wanted to know I you have also experienced that problem when using Avalon
>>with servlet containers.
>>Is it a tomcat issue? I am not very familiar with class loader issues. Is
>>there a better way
>>to get the same result than the hack code above? What is the preferred way
>>of doing things here?
>>
>
> If the avalon jars are in the webapps lib dir (ie
> myapp/WEB-INF/lib/avalon-*.jar) then in theory you should be fine. Your
> servlet container *should* set the context classloader - if it doesn't then
> it is probably buggy.
>
> However if you keep your jars in other places (like in the servlet engines
> common directory or something) then I would expect to see the behaviour you
> describe.
>
> Could you describe where you are placing avalon jars and where the code that
> uses them is placed.
>
>
>
>>Btw, I guess there is mistake in the paper Developping with Apache Avalon
>>at bottom of page 39 (pdf format).
>>There is an example of an xml configuration file and it says that when you
>>have multiple instances
>>of a component you specify the instance name with the "hint" keyword but
>>the code is expecting "name" instead.
>>
>
> Berin - do you wanna pick this up.
I'll apply the patch.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ExclaliburComponentManager
Posted by Vincent Tencé <Vi...@gemplus.com>.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Wednesday, February 13, 2002 3:11 AM
> To: Avalon Developers List
> Subject: Re: ExclaliburComponentManager
>
> ....
>
> If the avalon jars are in the webapps lib dir (ie
> myapp/WEB-INF/lib/avalon-*.jar) then in theory you should be
> fine. Your
> servlet container *should* set the context classloader - if
> it doesn't then
> it is probably buggy.
>
So apparently Tomcat 3.2.3 does not do it. I'll follow Berin suggestions and will try
Thread.currentThread().setContextClassLoader(this.classloader);
in my FrontComponent servlet service method, so I can get rid of the hack.
> However if you keep your jars in other places (like in the
> servlet engines
> common directory or something) then I would expect to see the
> behaviour you
> describe.
>
> Could you describe where you are placing avalon jars and
> where the code that
> uses them is placed.
They are placed in my web app lib dir, not in tomcat lib dir.
Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ExclaliburComponentManager
Posted by Peter Donald <pe...@apache.org>.
On Wed, 13 Feb 2002 10:02, Vincent Tencé wrote:
> I wanted to know I you have also experienced that problem when using Avalon
> with servlet containers.
> Is it a tomcat issue? I am not very familiar with class loader issues. Is
> there a better way
> to get the same result than the hack code above? What is the preferred way
> of doing things here?
If the avalon jars are in the webapps lib dir (ie
myapp/WEB-INF/lib/avalon-*.jar) then in theory you should be fine. Your
servlet container *should* set the context classloader - if it doesn't then
it is probably buggy.
However if you keep your jars in other places (like in the servlet engines
common directory or something) then I would expect to see the behaviour you
describe.
Could you describe where you are placing avalon jars and where the code that
uses them is placed.
> Btw, I guess there is mistake in the paper Developping with Apache Avalon
> at bottom of page 39 (pdf format).
> There is an example of an xml configuration file and it says that when you
> have multiple instances
> of a component you specify the instance name with the "hint" keyword but
> the code is expecting "name" instead.
Berin - do you wanna pick this up.
--
Cheers,
Pete
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
ExclaliburComponentManager
Posted by Vincent Tencé <Vi...@gemplus.com>.
Hi everybody,
I'm new to the world of Avalon and have some questions regarding
ExcaliburComponentManager.
But first a quick introduction.
We are currently developping web server applications that we run in Tomcat
(the version I used
at the moment is 3.2.3, I might jump to 4.x soon). I have been looking to
the Avalon framework
for about a month and I introduced it to my team of developers.
So far I am very happy with the results! It's a way to enforce usage of best
practises and patterns
in our work and we can leverage the work that has been put into Avalon. Thx
for that.
We are learning a lot from the code we use and we can feel the benefits of
using patterns like IoC and SoC.
Now the problem :-) and the question. Somehow with Tomcat (maybe only 3.2.3)
the context class loader
cannot find my classes so we have to use getClass().getClassLoader(). It's
an issue since in a lot
of the excalibur code the context class loader is used by default.
I guess there are workarounds, and we had to think of one for
ExcaliburComponentSelector. We want
to use a selector in our roles.xml file but ExcaliburComponentSelector
cannot find any classes of the
webapp.
So we overrided ExcaliburComponentManager like this (not very clean) and
used that class instead:
public class DefaultComponentSelector extends ExcaliburComponentSelector {
private static Class clazz;
static {
clazz = new HackClass().getClass();
}
public DefaultComponentSelector() {
super(clazz.getClassLoader());
}
private static class HackClass {
}
}
I wanted to know I you have also experienced that problem when using Avalon
with servlet containers.
Is it a tomcat issue? I am not very familiar with class loader issues. Is
there a better way
to get the same result than the hack code above? What is the preferred way
of doing things here?
Btw, I guess there is mistake in the paper Developping with Apache Avalon at
bottom of page 39 (pdf format).
There is an example of an xml configuration file and it says that when you
have multiple instances
of a component you specify the instance name with the "hint" keyword but the
code is expecting "name" instead.
Thanks for your answers,
Vincent
Hope everybody will understand my English :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Component <> Object (and never will be).
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, 11 February, 2002 20:03
> To: Avalon Developers List
> Subject: Re: Component <> Object (and never will be).
>
>
> Paul Hammant wrote:
> > Folks,
> >
> > Berin is putting up a good fight against the changes (as we present
> > them) being talked about. Being proposed is JNDI as an alternative.
> > <footnote>One reason I started EOB was because I wanted a one line
> > CompMgr style lookup for *anything* and dislike the wieght of JNDI in
> > its usage</footnote>. Reading Berin's opinion it seems that
> > ComponentManager is still the preferred tool for Components and that if
> > there is something else needed, it is for non-components.
> >
> > Perhaps this is true, and there is no overlap. Perhaps a completely
> > fresh (not clone) package is required for non-components. It could
> > serve the needs of Object lookup and be reusable or reimplementable by
> > Stephen's CORBA work in Cornerstone, EOB (sourceforge) and
> Peter's needs.
> >
> > We could roll in some naming contexts. I.e. "jndi:", "phoenix:",
> > <insert Stephen's needs> <insert Peter's needs>
>
>
> My main points have always been that we shouldn't be too hasty
> just because we have a possible solution (out of many).
I'm didn't want to go down the path of exploring possible solution. I'll
restate this again - SM is a very minor generalisation of CM. It isn't
introducing any new concepts. In fact the model of CM suits that
application cases I'm concerning with - its the implementation restriction
concerning the Component interface usage which is being addressed.
> Notice that I also did not put up a fight without proposing a solution.
> It is true that Object != Component (although the reverse is true).
>
> With an ORB, there is another naming and lookup service that is part of
> the CORBA spec--for those, it would be better to handle references through
> that.
This has nothing to do with things like the CORBA Naming Service (INS). I'm
concerned about component management used in building applications that deal
with objects beyond the Avalon enclave. INS is way-out-of-scope relative
to CM/SM discussions.
> I understand the desire, and even need for having one unified way of
> looking up object references--that is simple and elegant, and can differ
> to the heavier JNDI and ORB Naming service.
>
> That is why I proposed the resolver interfaces, to solicit feedback on
> that. Is this something that will satisfy everyone's need? I think it
> will be a much better fit than even the current CM/CS approach we have
> now.
The rosolver interfaces are much heavier the CM/SM approaches. That
not the level of complexity I'm looking for. CM provides almost exactly
what I want - except when my components cannot implement the Component
interface (in which case SM addresses my needs completely). I need
anything more complex than CM/SM.
> Please, I am soliciting feedback on the proposal, so we can see if it
> fits all our needs.
Berin - can you outline what you think are the deficiencies you have
with CM/SM.
Cheers, Steve.
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Berin Loritsch <bl...@apache.org>.
Paul Hammant wrote:
> Folks,
>
> Berin is putting up a good fight against the changes (as we present
> them) being talked about. Being proposed is JNDI as an alternative.
> <footnote>One reason I started EOB was because I wanted a one line
> CompMgr style lookup for *anything* and dislike the wieght of JNDI in
> its usage</footnote>. Reading Berin's opinion it seems that
> ComponentManager is still the preferred tool for Components and that if
> there is something else needed, it is for non-components.
>
> Perhaps this is true, and there is no overlap. Perhaps a completely
> fresh (not clone) package is required for non-components. It could
> serve the needs of Object lookup and be reusable or reimplementable by
> Stephen's CORBA work in Cornerstone, EOB (sourceforge) and Peter's needs.
>
> We could roll in some naming contexts. I.e. "jndi:", "phoenix:",
> <insert Stephen's needs> <insert Peter's needs>
My main points have always been that we shouldn't be too hasty just because
we have a possible solution (out of many).
Notice that I also did not put up a fight without proposing a solution.
It is true that Object != Component (although the reverse is true).
With an ORB, there is another naming and lookup service that is part of
the CORBA spec--for those, it would be better to handle references through
that.
I understand the desire, and even need for having one unified way of
looking up object references--that is simple and elegant, and can differ
to the heavier JNDI and ORB Naming service.
That is why I proposed the resolver interfaces, to solicit feedback on
that. Is this something that will satisfy everyone's need? I think it
will be a much better fit than even the current CM/CS approach we have
now.
Please, I am soliciting feedback on the proposal, so we can see if it
fits all our needs.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Component <> Object (and never will be).
Posted by Michael McKibben <mi...@hihat.net>.
Isn't the Component interface just a "marker" interface? Why expose a
marker interface in the api's.? For example, you don't see
java.io.Serializable arguments to the Java Object serialization
methods; they just don't work and throw an exception when a
non-serializable object is used.
The real issue with Component is when you want to write a component
which implements a work interface from another API (e.g. SAX URIResolver.)
Clients that use your component now must do some awkward casting to
release your component: e.g.
URIResolver resolver = (URIResolver)cm.lookup(someRole);
//... this seems ugly...
cm.release((Component)resolver);
Also, notice that if I write a component that implements Component but no
Lifecycle interfaces, the ComponentManager becomes a convenient pluggable
factory!
Just some random thoughts...
Regards,
--mike
On Mon, 11 Feb 2002, Paul Hammant wrote:
> Folks,
>
> Berin is putting up a good fight against the changes (as we present
> them) being talked about. Being proposed is JNDI as an alternative.
> <footnote>One reason I started EOB was because I wanted a one line
> CompMgr style lookup for *anything* and dislike the wieght of JNDI in
> its usage</footnote>. Reading Berin's opinion it seems that
> ComponentManager is still the preferred tool for Components and that if
> there is something else needed, it is for non-components.
>
> Perhaps this is true, and there is no overlap. Perhaps a completely
> fresh (not clone) package is required for non-components. It could
> serve the needs of Object lookup and be reusable or reimplementable by
> Stephen's CORBA work in Cornerstone, EOB (sourceforge) and Peter's needs.
>
> We could roll in some naming contexts. I.e. "jndi:", "phoenix:",
> <insert Stephen's needs> <insert Peter's needs>
>
> - Paul
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>