You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/02/12 19:42:49 UTC
Resolver package--Please post your thoughts
I have tried to address all the shortcommings of the ComponentManager/ComponentSelector
approach in the Resolver package. (located in Avalon Framework src/proposals directory).
If you find that this package does *not* support your needs, or appears clumsy/difficult
to use, please air your grievances now.
Please either take the approach of fine-tuning the interfaces or of providing an alternative.
It also helps when you state the reasons why you beleive your alternative is better :)
Since everyone is keen on removing the necessity of marker interfaces sooner than later,
I want a smooth migration path. That means that we need a replacement for Component
resolution (without the Component interface).
It also means that we should do the following:
* Promote ComponentHandler interface and implementations to Framework
* Provide standard mechanism for registering a Component with a handler
- ComponentInfo? (like BlockInfo)
- Manifest entries?
- Other?
* Finalize Resolver framework, or whatever the replacement ends up being
If this seems like a winning migration path, and we really like this approach, we can make
it a part of Framework 4.2 or something like that. It is important that we have working
implementations though.
--
"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: Resolver package--Please post your thoughts
Posted by Peter Donald <pe...@apache.org>.
On Thu, 14 Feb 2002 02:08, Berin Loritsch wrote:
> >>It also means that we should do the following:
> >>
> >>* Promote ComponentHandler interface and implementations to Framework
> >
> > -1 - a concern of the container
>
> Not necessarily. It is a concern of the Component Developer. A Container
> cannot divine that the Component Developer intended when he created the
> Component. We had marker interfaces that provided hints--but this is a
> tenuous contract.
>
> We *need* a way to specify how a Container should handle the Component
> instances. If a Component is not Threadsafe--which a large number aren't--
> we need to specify a policy for them. Many components can be instantiated
> one per thread, but still others must be fully pooled so that a unique
> instance is returned *per*request*.
>
> If we are going to remove lifestyle interfaces, we must have a replacement
> mechanism. This mechanism is simple and workable.
Right - but it is container specific. Different containers will use different
strategies for implementing this. Some could do it via handlers or factorys,
others may specify it via configuration files, others may do it by info
objects etc.
> > While I would like to see a basic container that leveraged existing
> > designs - I don't think it should be in framework that this is done - at
> > least not until it is thouroughly specced out and very mature. Keep it in
> > excalibur toill then.
>
> The Container will remain there as long as necessary. I am talking about
> the ComponentHandler interface, and a mechanism for the Component developer
> to associate their Component with a Handler that will perform correctly for
> it.
>
> If there are N different containers, each with their own unique association
> strategy, then we have N different association strategies. The Component
> developer will be driven mad!
>
> This is not good.
Perhaps not but we have to come to a conclusion of which strategy to use
before we promote one into the framework.
--
Cheers,
Pete
---------------------------------
I think not; therefore I ain't...
---------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Resolver package--Please post your thoughts
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer inline
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, February 13, 2002 4:08 PM
>
> Peter Donald wrote:
> > On Wed, 13 Feb 2002 05:42, Berin Loritsch wrote:
>
> ...
>
>
> And we can go back to this. As I put it together, I realized
> that it would
> be *possible* to obtain the reference to multiple objects at with
> one call.
> It can be more efficient, and support cleaner client code.
> (Something that
> JNDI cannot boast).
It is more complex and quite often it does not work because:
- You might need to get some specific component before being sure
of which other components you really need next;
- It might happen that some component is not there and then you
might either:
- Want the others anyway;
- Abort.
> My thinking behind the Token is to allow a single release point
> for all components
> attached to it, thus making the finally clause simpler.
And the CM does all the component tracking instead of each app
using the CM, which tends to avoid oportunities for error.
> If we are going to remove lifestyle interfaces, we must have a replacement
> mechanism. This mechanism is simple and workable.
Component factories could provide that lifecycle...
> The Container will remain there as long as necessary. I am talking about
> the ComponentHandler interface, and a mechanism for the Component
> developer
> to associate their Component with a Handler that will perform
> correctly for it.
I am not sure a Handler really helps that much. I droped mine.
> If there are N different containers, each with their own unique
> association
> strategy, then we have N different association strategies. The Component
> developer will be driven mad!
Maybe not. Maybe each app really wants its own association strategy,
key strategy, etc. Maybe you don't mix apps so often and in such
amounts that it gets confusing.
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 13 Feb 2002 05:42, Berin Loritsch wrote:
>
>>I have tried to address all the shortcommings of the
>>ComponentManager/ComponentSelector approach in the Resolver package.
>>(located in Avalon Framework src/proposals directory). If you find that
>>this package does *not* support your needs, or appears clumsy/difficult to
>>use, please air your grievances now.
>>
>
> will do ;)
>
> Waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay too complex. The reason
> for CM to initially exist was that it was a much simpler interface than any
> of the other naming/directory APIs. I would much prefer to use an existing
> standard API (ie JNDI) than this because the standard while a little complex
> is standard and much easier for new develoeprs to adopt.
>
> This is not simple. Initially when you were taslking about this I thought it
> would be something as simple as
>
> interface ComponentManager
> {
> Object lookup(String role);
> Object lookup(Query query);
> }
>
> class Query
> {
> Query(String role) {}
> void addAttribute( String name, String value );
> }
>
> Such that
>
> lookup( MyService.ROLE ) is equivelent to lookup( new Query(MyService.ROLE) )
And we can go back to this. As I put it together, I realized that it would
be *possible* to obtain the reference to multiple objects at with one call.
It can be more efficient, and support cleaner client code. (Something that
JNDI cannot boast).
My thinking behind the Token is to allow a single release point for all components
attached to it, thus making the finally clause simpler.
> If you wanted other attributes to use in lookup you would use something like
>
> query = new Query(MyService.ROLE);
> query.setAttribute( "timeToLive", "3" );
> lookup( query )
>
> This I think is acceptable because in most cases the users will never need to
> use the more complex construction but if they have to they can.
True. We can do that (That is what discussion is for).
>>Since everyone is keen on removing the necessity of marker interfaces
>>sooner than later, I want a smooth migration path. That means that we need
>>a replacement for Component resolution (without the Component interface).
>>
>
> I am all for the minimal change as possible - basically the ServiceManager
> stuff the Stephen proposed.
>
>
>>It also means that we should do the following:
>>
>>* Promote ComponentHandler interface and implementations to Framework
>>
>
> -1 - a concern of the container
Not necessarily. It is a concern of the Component Developer. A Container
cannot divine that the Component Developer intended when he created the
Component. We had marker interfaces that provided hints--but this is a
tenuous contract.
We *need* a way to specify how a Container should handle the Component
instances. If a Component is not Threadsafe--which a large number aren't--
we need to specify a policy for them. Many components can be instantiated
one per thread, but still others must be fully pooled so that a unique
instance is returned *per*request*.
If we are going to remove lifestyle interfaces, we must have a replacement
mechanism. This mechanism is simple and workable.
>>* Provide standard mechanism for registering a Component with a handler
>> - ComponentInfo? (like BlockInfo)
>> - Manifest entries?
>> - Other?
>>
>
> -1 - a concern of the container
Again, I disagree. See above.
> While I would like to see a basic container that leveraged existing designs -
> I don't think it should be in framework that this is done - at least not
> until it is thouroughly specced out and very mature. Keep it in excalibur
> toill then.
The Container will remain there as long as necessary. I am talking about
the ComponentHandler interface, and a mechanism for the Component developer
to associate their Component with a Handler that will perform correctly for
it.
If there are N different containers, each with their own unique association
strategy, then we have N different association strategies. The Component
developer will be driven mad!
This is not good.
--
"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: Resolver package--Please post your thoughts
Posted by Peter Donald <pe...@apache.org>.
On Wed, 13 Feb 2002 05:42, Berin Loritsch wrote:
> I have tried to address all the shortcommings of the
> ComponentManager/ComponentSelector approach in the Resolver package.
> (located in Avalon Framework src/proposals directory). If you find that
> this package does *not* support your needs, or appears clumsy/difficult to
> use, please air your grievances now.
will do ;)
Waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay too complex. The reason
for CM to initially exist was that it was a much simpler interface than any
of the other naming/directory APIs. I would much prefer to use an existing
standard API (ie JNDI) than this because the standard while a little complex
is standard and much easier for new develoeprs to adopt.
This is not simple. Initially when you were taslking about this I thought it
would be something as simple as
interface ComponentManager
{
Object lookup(String role);
Object lookup(Query query);
}
class Query
{
Query(String role) {}
void addAttribute( String name, String value );
}
Such that
lookup( MyService.ROLE ) is equivelent to lookup( new Query(MyService.ROLE) )
If you wanted other attributes to use in lookup you would use something like
query = new Query(MyService.ROLE);
query.setAttribute( "timeToLive", "3" );
lookup( query )
This I think is acceptable because in most cases the users will never need to
use the more complex construction but if they have to they can.
> Since everyone is keen on removing the necessity of marker interfaces
> sooner than later, I want a smooth migration path. That means that we need
> a replacement for Component resolution (without the Component interface).
I am all for the minimal change as possible - basically the ServiceManager
stuff the Stephen proposed.
> It also means that we should do the following:
>
> * Promote ComponentHandler interface and implementations to Framework
-1 - a concern of the container
> * Provide standard mechanism for registering a Component with a handler
> - ComponentInfo? (like BlockInfo)
> - Manifest entries?
> - Other?
-1 - a concern of the container
While I would like to see a basic container that leveraged existing designs -
I don't think it should be in framework that this is done - at least not
until it is thouroughly specced out and very mature. Keep it in excalibur
toill then.
--
Cheers,
Pete
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Antti Koivunen <an...@users.sourceforge.net>.
OK, I missed that thread. This approach looks fine to me.
(: Anrie ;)
Berin Loritsch wrote:
> For the time being, I think we settled on the direct approach:
>
> interface ServiceManager
> {
> /**
> * Return component for the specified role. If there are more than
> * one components for the role, return the default.
> */
> Object lookup(String role);
>
> /**
> * Return component for the specified role. If there are more than
> * one components for the role, use the supplied parameters to
> determine
> * which one. If the parameters do not help, return the default.
> */
> Object lookup(String role, Parameters params);
>
> /**
> * Returns true if the ServiceManager has at least one instance of a
> * role.
> */
> boolean hasComponent( String role );
>
> /**
> * Release a sepecific component.
> */
> void release(Object component);
> }
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Resolver package--Please post your thoughts
Posted by Paulo Gaspar <pa...@krankikom.de>.
> No. All we need to check is that there is at least one implementation of
> a role. If there is none that are specialized, the default implmentation
> is returned.
Are you sure that all implementations will "be happy" with that rule?
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, February 13, 2002 9:42 PM
> To: Avalon Developers List
> Subject: Re: Resolver package--Please post your thoughts
>
>
> Sylvain Wallez wrote:
> > Berin Loritsch wrote:
> > >
> > To have the equivalent of ComponentSelector.hasComponent(Object hint),
> > you also need :
> >
> > boolean hasComponent( String role, Parameters params);
>
> No. All we need to check is that there is at least one implementation of
> a role. If there is none that are specialized, the default implmentation
> is returned.
>
> >
> > This also applies to Stephen's last proposal in the "[VOTE] Re:
> > ComponentManager interface" thread. I also like better his replacement
> > of Parameter by Map because, being an interface, Map allows the use of
> > efficient specialized implementations, e.g. singleton Map for CS hints.
>
>
> Sounds good.
>
>
>
>
> --
>
> "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: Resolver package--Please post your thoughts
Posted by Paulo Gaspar <pa...@krankikom.de>.
I have similar problems. For me hasComponent() makes all the sense.
BTW, hasXxxxx() makes sense EVERYWHERE (Context, etc) although its
use might not be so frequent. Checking for exceptions is a kludge.
Besides, the more I see the arguments on
lookup(String role, Parameters params)
versus
lookup(Query query)
or whatever, the more I like
lookup(Object someKey)
Although I have several specialized versions of Maps (e.g.:
NamedMap, InstanceMap, etc.) that might accept and be limited to
different kinds of keys, the underlying implementation tends to
always be the old HashMap and its java.lang.Object key.
So, if you are talking generic, do it _really_ generic and then
specialize.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: Wednesday, February 13, 2002 9:57 PM
> To: Avalon Developers List
> Subject: Re: Resolver package--Please post your thoughts
>
>
> Berin Loritsch wrote:
>
> > Sylvain Wallez wrote:
> >
> >> Berin Loritsch wrote:
> >> > To have the equivalent of ComponentSelector.hasComponent(Object
> >> hint), you also need :
> >>
> >> boolean hasComponent( String role, Parameters params);
> >
> >
> > No. All we need to check is that there is at least one
> implementation of
> > a role. If there is none that are specialized, the default
> implmentation
> > is returned.
>
> Mmmh... Let's consider a very practical case (sorry for cocoon-dev
> flooding on avalon-dev ;) : in a Cocoon sitemap, we have e.g. a
> <map:generate type="file">. How can we check at sitemap load time if
> there actually exists a "file" specialization for the Generator role and
> that this statement is valid ? De we have to resort to a
> lookup()/release() and see if no exception occurs ?
>
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
>
>
>
> --
> 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: Resolver package--Please post your thoughts
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
> Sylvain Wallez wrote:
>
>> Berin Loritsch wrote:
>> > To have the equivalent of ComponentSelector.hasComponent(Object
>> hint), you also need :
>>
>> boolean hasComponent( String role, Parameters params);
>
>
> No. All we need to check is that there is at least one implementation of
> a role. If there is none that are specialized, the default implmentation
> is returned.
Mmmh... Let's consider a very practical case (sorry for cocoon-dev
flooding on avalon-dev ;) : in a Cocoon sitemap, we have e.g. a
<map:generate type="file">. How can we check at sitemap load time if
there actually exists a "file" specialization for the Generator role and
that this statement is valid ? De we have to resort to a
lookup()/release() and see if no exception occurs ?
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Berin Loritsch wrote:
> >
> To have the equivalent of ComponentSelector.hasComponent(Object hint),
> you also need :
>
> boolean hasComponent( String role, Parameters params);
No. All we need to check is that there is at least one implementation of
a role. If there is none that are specialized, the default implmentation
is returned.
>
> This also applies to Stephen's last proposal in the "[VOTE] Re:
> ComponentManager interface" thread. I also like better his replacement
> of Parameter by Map because, being an interface, Map allows the use of
> efficient specialized implementations, e.g. singleton Map for CS hints.
Sounds good.
--
"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: Resolver package--Please post your thoughts
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
> Antti Koivunen wrote:
>
>> 4. Loose Token?
>>
>> As I see it, it's mainly a matter of
>>
>> Token token = resolver.lookup(MY_URI);
>> MyComponent mc = (MyComponent) token.reference();
>> token.release();
>>
>> vs.
>>
>> MyComponent mc = (MyComponent) resolver.lookup(MY_URI);
>> resolver.release(MY_URI, mc);
>>
>> And the same thing for String[] + Object[]. Which one do you like best?
>
>
>
> For the time being, I think we settled on the direct approach:
>
> interface ServiceManager
> {
> /**
> * Return component for the specified role. If there are more than
> * one components for the role, return the default.
> */
> Object lookup(String role);
>
> /**
> * Return component for the specified role. If there are more than
> * one components for the role, use the supplied parameters to
> determine
> * which one. If the parameters do not help, return the default.
> */
> Object lookup(String role, Parameters params);
>
> /**
> * Returns true if the ServiceManager has at least one instance of a
> * role.
> */
> boolean hasComponent( String role );
>
> /**
> * Release a sepecific component.
> */
> void release(Object component);
> }
To have the equivalent of ComponentSelector.hasComponent(Object hint),
you also need :
boolean hasComponent( String role, Parameters params);
This also applies to Stephen's last proposal in the "[VOTE] Re:
ComponentManager interface" thread. I also like better his replacement
of Parameter by Map because, being an interface, Map allows the use of
efficient specialized implementations, e.g. singleton Map for CS hints.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Berin Loritsch <bl...@apache.org>.
Antti Koivunen wrote:
> 4. Loose Token?
>
> As I see it, it's mainly a matter of
>
> Token token = resolver.lookup(MY_URI);
> MyComponent mc = (MyComponent) token.reference();
> token.release();
>
> vs.
>
> MyComponent mc = (MyComponent) resolver.lookup(MY_URI);
> resolver.release(MY_URI, mc);
>
> And the same thing for String[] + Object[]. Which one do you like best?
For the time being, I think we settled on the direct approach:
interface ServiceManager
{
/**
* Return component for the specified role. If there are more than
* one components for the role, return the default.
*/
Object lookup(String role);
/**
* Return component for the specified role. If there are more than
* one components for the role, use the supplied parameters to determine
* which one. If the parameters do not help, return the default.
*/
Object lookup(String role, Parameters params);
/**
* Returns true if the ServiceManager has at least one instance of a
* role.
*/
boolean hasComponent( String role );
/**
* Release a sepecific component.
*/
void release(Object component);
}
--
"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: Resolver package--Please post your thoughts
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Leo Sutic wrote:
>>-----Original Message-----
>>From: Antti Koivunen [mailto:anryoshi@users.sourceforge.net]
>>
>>
>>Leo Sutic wrote:
>><skip/>
>>
>>>public class Token extends java.rmi.server.UID {}
>>>
>>new java.rmi.server.UID() is a very expensive operation, so it's not
>>really suitable for something like this.
>>
>
> Only if it is more expensive than *all* the calls you intend to make
> through the obtained interface before you release it.
Right, as it's created once per component lifecycle. That example just
first struck me as a method level transaction, but of course that's not
the case.
> But I realized that it is enough to have:
>
> public class Token {}
>
> Since we can use object identity.
That'd be even better.
(: A ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Resolver package--Please post your thoughts
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Antti Koivunen [mailto:anryoshi@users.sourceforge.net]
>
>
> Leo Sutic wrote:
> <skip/>
> >
> > public class Token extends java.rmi.server.UID {}
>
> new java.rmi.server.UID() is a very expensive operation, so it's not
> really suitable for something like this.
Only if it is more expensive than *all* the calls you intend to make
through the obtained interface before you release it.
If you grab everything in compose() and release it in dispose(), it should
not
be a problem.
But I realized that it is enough to have:
public class Token {}
Since we can use object identity.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Leo Sutic wrote:
<skip/>
>
> public class Token extends java.rmi.server.UID {}
new java.rmi.server.UID() is a very expensive operation, so it's not
really suitable for something like this.
(: 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: Resolver package--Please post your thoughts
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> Berin,
>
> I've taken a look at the resolver package. It is very nice and general,
> but I fear that it is also too much as it is in CVS and there are issues
> with
> it that I do not understand.
>
> public interface Resolver {
> Token lookup( Query query )
> }
>
> public interface Token {
> Object[] references();
> ...
> }
>
> As I see it, the gain is that you can look up several components
> with one single call to Resolver.resolve, and then release them all
> simultaneously.
>
> Briefly, consider those two advantages completely separate. We can have
> none, one or both of them.
>
> LOOKUP OF SEVERAL COMPONENTS AT ONCE
> ------------------------------------
>
> Why? I fail to see the point of this. The usage would be
>
> 1) Fill in a query object.
> 2) lookup(query)
> 3) Extract the components from the Token based on their index in the
> returned array of Objects.
>
> I see no gain in number of lines of code: To lookup N components, you
> need to fill in a query object = N lines, resolve = 1 line, extract = N
> lines.
> In effect, the number of lines of code has doubled. Better to provide an
> easy
> interface for lookups and do N lookup(Query) calls.
Yes, but the advantage in the code sample in the package.html file shown
was the ability to prefill the Query with the constructor. After we
discover if there are any objects that cannot be resolved, we remove them
from the query.
From that point on, we can alter the attributes at runtime, and merely
do a Resolver.resolve(Query) in the critical section.
However, it is a common argument that the multiple lookup feature may be
too much solution for not enough problem. With that said, I have no
problems with limiting it to only one object per query.
At this point, the Query object itself becomes superfluous, because its
advantages are now lost. We can perform the same thing with a call that
has a hint parameter or something like that.
> RELEASE OF SEVERAL COMPONENTS AT ONCE
> -------------------------------------
>
> Good. Much like the catch and finally clauses put all
> error handling into one spot, and the CM interface allows
> one to release a null component, we get all error handling into one place
> and guarantee that multiple components are released properly.
>
> My proposal:
<snip/>
This is similar to the PreparedEnqueue concept in the excalibur.event
package. The main difference is that all the responsibility is pushed
onto the Resolver.
so I guess we are now at an interface like this:
class Token {} // I snipped the Token impl you had, sorry :(
interface Resolver
{
Object resolve(String key, Token token);
Object resolve(String key, Object hint, Token token);
// for multi-dimensional resolution, the object can be a
// Map or equivalent
boolean hasReference(String key);
void release(Token token);
}
This allows a usage like this (adapted from the resolver example):
public class SampleComponent implements Parameterizable, Resolvable, Sample
{
private Resolver m_resolver;
private Parameters m_params;
private boolean m_hasEntityResolver;
private String m_dbName;
public SampleComponent()
{
}
/**
* Add parameters to specialize the query.
*/
public void parameterize( Parameters params )
throws ParameterException
{
m_params = params;
m_dbName = m_params.getParameter( "dbname", "default" );
}
/**
* Ensure a valid working space
*/
public void resolver( Resolver resolver )
throws ResolverException
{
m_resolver = resolver;
m_hasEntityResolver = m_resolver.hasReference( EntityResolver.ROLE );
// test if the required references are available
if ( ! m_resolver.hasReference( DataSourceComponent.ROLE ) ||
! m_resolver.hasReference( Parser.ROLE ) )
{
throw new ResolverException("Required references not available");
}
}
/**
* Perform the work from the Sample interface
*/
public Object doWork()
{
Token tok = new Token();
try
{
DataSourceComponent datasource =
m_resolver.lookup( DataSourceComponent.ROLE,
m_dbName, tok );
Parser parser = m_resolver.lookup( Parser.ROLE, tok );
// ... do stuff with the datasource to get input stream
if (m_hasEntityResolver) {
parser.setEntityResolver(
(EntityResolver)m_resolver.lookup( EntityResolver.ROLE, tok )
);
}
SampleContentHandler handler = getContentHandler();
parser.parse(handler);
return handler().getObject();
}
catch (Exception e)
{
// handle the exception
}
finally
{
m_resolver.release( tok );
}
}
/**
* The ContentHandler for the parser.
*/
SampleContentHandler getContentHandler()
{
//defined elsewhere
return new SampleContentHandler();
}
}
--
"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: Resolver package--Please post your thoughts
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Leo,
For starters, I really do not see that the Resolver pays very much by
the same reasons you expose.
However, what confuses me most is the need for a specific type for the
token object.
In my framework object tracking is a functionality of the CM and not
of an additional object and that provides for the most efficient
implementation because it allows to minimize the number of components
being tracked since:
- Thread safe components do not need to be tracked;
- Some non-thread-safe components that do not hold resources also do
not need to be tracked (I have some of this).
Actually, in my framework typical use, only a very low percentage of
the component requests to the CM require tracking.
But passing the necessary/intimate information about each component
to an external object and allow it to do the tracking would be a
nightmare.
Besides that, you should NOT mix these 2 usage models in the same
interface - with tracking and without - since it is error prone.
Either you use tracking or you do NOT and there should be an
interface/CM for each case if you really want both. (I am happy
having tracking everywhere).
This is my ideal interface for a CM:
public interface ComponentManager
{
public Object lookup(Object token, Object key);
public boolean containsComponent(Object key);
public void release(Object component);
public void releaseAll(Object token);
}
No need to specify a specific type for the token. You could use
the Request for a Web app scenario or some other object at hand.
...and that single key parameter can be directly used by a Map
based implementation.
Now, what about type safety? Those token/key objects could get
confused!!!
Well, when you use it, you can build your own wrapper to avoid
such mess and implement your key strategy, like:
public class ClassicCM
{
private final ComponentManager m_cm;
public ClassicCM(ComponentManager cm)
{
m_cm = cm;
}
public Object lookup(Object token, String role)
{
return m_cm.lookup(token, role);
}
public Object lookup(Object token, String role, Parameters params)
{
return m_cm.lookup(token, new PairKey(role, params));
}
public boolean contains(String role)
{
return m_cm.contains(role);
}
public boolean contains(String role, Parameters params)
{
return m_cm.contains(token, new PairKey(role, params));
}
public void release(Object comp)
{
m_cm.release(comp);
}
public void releaseAll(Object token)
{
return m_cm.releaseAll(token);
}
}
What do you think?
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Wednesday, February 13, 2002 9:09 PM
> To: Avalon Developers List
> Subject: RE: Resolver package--Please post your thoughts
>
>
> Berin,
>
> I've taken a look at the resolver package. It is very nice and general,
> but I fear that it is also too much as it is in CVS and there are issues
> with
> it that I do not understand.
>
> public interface Resolver {
> Token lookup( Query query )
> }
>
> public interface Token {
> Object[] references();
> ...
> }
>
> As I see it, the gain is that you can look up several components
> with one single call to Resolver.resolve, and then release them all
> simultaneously.
>
> Briefly, consider those two advantages completely separate. We can have
> none, one or both of them.
>
> LOOKUP OF SEVERAL COMPONENTS AT ONCE
> ------------------------------------
>
> Why? I fail to see the point of this. The usage would be
>
> 1) Fill in a query object.
> 2) lookup(query)
> 3) Extract the components from the Token based on their index in the
> returned array of Objects.
>
> I see no gain in number of lines of code: To lookup N components, you
> need to fill in a query object = N lines, resolve = 1 line, extract = N
> lines.
> In effect, the number of lines of code has doubled. Better to provide an
> easy
> interface for lookups and do N lookup(Query) calls.
>
> RELEASE OF SEVERAL COMPONENTS AT ONCE
> -------------------------------------
>
> Good. Much like the catch and finally clauses put all
> error handling into one spot, and the CM interface allows
> one to release a null component, we get all error handling into one place
> and guarantee that multiple components are released properly.
>
> My proposal:
>
> public interface Resolver {
>
> // --------------------- Lookup of a single
> component ------------------------------------
>
> /**
> * Looks up a component.
> * This method is identical to Object lookup( Query query ) called as
> * lookup( new Query (role) );
> */
> Object lookup( String role ) throws ComponentException;
>
> /**
> * Looks up a component.
> */
> Object lookup( Query query ) throws ComponentException;
>
> /**
> * Releases a single object.
> */
> Object release( Object component );
>
> // --------------------- Lookup/release of multiple
> components ---------------------------
>
> /**
> * Looks up a component and if successful, associates it with a release
> token.
> * This method is identical to Object lookup( Query query, Token token )
> called as
> * lookup( new Query (role), Token token );
> */
> Object lookup( String role, Token token ) throws InvalidTokenException,
> ComponentException;
>
> /**
> * Looks up a component and if successful, associates it with a release
> token.
> */
> Object lookup( Query query, Token token ) throws InvalidTokenException,
> ComponentException;
>
> /**
> * Releases all objects looked up via a given token.
> */
> Object release( Token token );
> }
>
> public class Token extends java.rmi.server.UID {}
>
> public class Query {
> public Query (String role);
> public Query (String role, Parameters parameters);
> }
>
> The single-component lookup/release works as the CM interface.
>
> The multiple version, with Token, works like this:
>
> Token token = new Token (); // Guaranteed unique due to
> java.rmi.server.UID
> MyComponent myComp = null;
> MyComponent2 myComp2 = null;
>
> try {
> myComp = (MyComponent) resolver.resolve (MyComponent.ROLE, token);
> myComp2 = (MyComponent2) resolver.resolve (MyComponent2.ROLE, token);
> } finally {
> resolver.release (token);
> }
>
> /LS
>
>
> --
> 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: Resolver package--Please post your thoughts
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Berin,
I've taken a look at the resolver package. It is very nice and general,
but I fear that it is also too much as it is in CVS and there are issues
with
it that I do not understand.
public interface Resolver {
Token lookup( Query query )
}
public interface Token {
Object[] references();
...
}
As I see it, the gain is that you can look up several components
with one single call to Resolver.resolve, and then release them all
simultaneously.
Briefly, consider those two advantages completely separate. We can have
none, one or both of them.
LOOKUP OF SEVERAL COMPONENTS AT ONCE
------------------------------------
Why? I fail to see the point of this. The usage would be
1) Fill in a query object.
2) lookup(query)
3) Extract the components from the Token based on their index in the
returned array of Objects.
I see no gain in number of lines of code: To lookup N components, you
need to fill in a query object = N lines, resolve = 1 line, extract = N
lines.
In effect, the number of lines of code has doubled. Better to provide an
easy
interface for lookups and do N lookup(Query) calls.
RELEASE OF SEVERAL COMPONENTS AT ONCE
-------------------------------------
Good. Much like the catch and finally clauses put all
error handling into one spot, and the CM interface allows
one to release a null component, we get all error handling into one place
and guarantee that multiple components are released properly.
My proposal:
public interface Resolver {
// --------------------- Lookup of a single
component ------------------------------------
/**
* Looks up a component.
* This method is identical to Object lookup( Query query ) called as
* lookup( new Query (role) );
*/
Object lookup( String role ) throws ComponentException;
/**
* Looks up a component.
*/
Object lookup( Query query ) throws ComponentException;
/**
* Releases a single object.
*/
Object release( Object component );
// --------------------- Lookup/release of multiple
components ---------------------------
/**
* Looks up a component and if successful, associates it with a release
token.
* This method is identical to Object lookup( Query query, Token token )
called as
* lookup( new Query (role), Token token );
*/
Object lookup( String role, Token token ) throws InvalidTokenException,
ComponentException;
/**
* Looks up a component and if successful, associates it with a release
token.
*/
Object lookup( Query query, Token token ) throws InvalidTokenException,
ComponentException;
/**
* Releases all objects looked up via a given token.
*/
Object release( Token token );
}
public class Token extends java.rmi.server.UID {}
public class Query {
public Query (String role);
public Query (String role, Parameters parameters);
}
The single-component lookup/release works as the CM interface.
The multiple version, with Token, works like this:
Token token = new Token (); // Guaranteed unique due to
java.rmi.server.UID
MyComponent myComp = null;
MyComponent2 myComp2 = null;
try {
myComp = (MyComponent) resolver.resolve (MyComponent.ROLE, token);
myComp2 = (MyComponent2) resolver.resolve (MyComponent2.ROLE, token);
} finally {
resolver.release (token);
}
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Antti Koivunen <an...@users.sourceforge.net>.
4. Loose Token?
As I see it, it's mainly a matter of
Token token = resolver.lookup(MY_URI);
MyComponent mc = (MyComponent) token.reference();
token.release();
vs.
MyComponent mc = (MyComponent) resolver.lookup(MY_URI);
resolver.release(MY_URI, mc);
And the same thing for String[] + Object[]. Which one do you like best?
--
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: Resolver package--Please post your thoughts
Posted by Antti Koivunen <an...@users.sourceforge.net>.
While it could be convenient to get everything from one place, combining
role based lookups with custom ones actually mixes concerns, so I'm in
favor of the direct 'ServiceManager' approach.
(: A ;)
Antti Koivunen wrote:
> I think that looking up things by role is a well defined operation, i.e.
> "Hey, get me something that implements this interface!", so I think we
> shouldn't break the pattern. That's why I would consider the following:
>
> public interface Resolver {
>
> Object lookup(String uri);
> Object[] lookup(String[] uris);
>
> Object lookupByRole(String role);
> Object[] lookupByRole(String[] roles);
>
>
> We could then define
>
> lookupByRole("com.mycompany.MyComponent");
>
> to be equivalent to
>
> lookup("role://com.mycompany.MyComponent");
>
> while being easier to use and not suffering from the additional cost of
> parsing the URL. I think usability is more important than 'elegance', so
> I wouldn't object to even adding something like:
>
> Object lookupByRoleAndHint(String role, Object hint);
>
> Well, that might be a bit too much, but I'd like to hear your opinions
> all the same. It could potentially make the migration from CM/CS easier,
> although that probably shouldn't be our primary concern.
>
> (: Anrie ;)
>
>
>
> --
> 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: Resolver package--Please post your thoughts
Posted by Antti Koivunen <an...@users.sourceforge.net>.
I think that looking up things by role is a well defined operation, i.e.
"Hey, get me something that implements this interface!", so I think we
shouldn't break the pattern. That's why I would consider the following:
public interface Resolver {
Object lookup(String uri);
Object[] lookup(String[] uris);
Object lookupByRole(String role);
Object[] lookupByRole(String[] roles);
We could then define
lookupByRole("com.mycompany.MyComponent");
to be equivalent to
lookup("role://com.mycompany.MyComponent");
while being easier to use and not suffering from the additional cost of
parsing the URL. I think usability is more important than 'elegance', so
I wouldn't object to even adding something like:
Object lookupByRoleAndHint(String role, Object hint);
Well, that might be a bit too much, but I'd like to hear your opinions
all the same. It could potentially make the migration from CM/CS easier,
although that probably shouldn't be our primary concern.
(: Anrie ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Paulo,
I see your point, using Object keys would naturally allow maximum
flexibility. However, the following operation is well defined:
MyComponent mc = (MyComponent) m.lookup("com.domain.MyComponent");
Custom Object keys would be perfect for one application, but how about
when we start switching container and component implementations?
(: A ;)
Paulo Gaspar wrote:
> Antti,
>
> Building a String key can get REALLY complicated. I am not sure if
> it really is a simplification.
>
> OTOH, if you know how to implement equals() and hashCode() methods,
> you can build efficient and non-coliding complex keys with ease...
> ...but then the key parameter should just be a
> java.lang.Object
>
>
> Have fun,
> Paulo Gaspar
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Resolver package--Please post your thoughts
Posted by Paulo Gaspar <pa...@krankikom.de>.
Antti,
Building a String key can get REALLY complicated. I am not sure if
it really is a simplification.
OTOH, if you know how to implement equals() and hashCode() methods,
you can build efficient and non-coliding complex keys with ease...
...but then the key parameter should just be a
java.lang.Object
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Antti Koivunen [mailto:anryoshi@users.sourceforge.net]
> Sent: Wednesday, February 13, 2002 6:52 PM
> To: Avalon Developers List
> Subject: Re: Resolver package--Please post your thoughts
>
>
> While I think something like the Resolver is needed, the current
> proposal might be a bit too complex. It, of course, has to be flexible
> enough, but also simple, easy, and efficient.
>
> But why do we need it in the first place?
>
> - To get rid of the Component interface.
> - To provide a consistent way of looking things up.
> - To avoid doing the same thing in the future.
>
> In other words, it has to be flexible enough to suit everyone's needs. I
> personally don't care if it's called ServiceManager or whatever (but
> Resolver does seem like a nice fit).
>
> Let's say you want to look up "com.food.FoodFactory:type=ice cream".
> Here, the current CM/CS works quite well:
>
> ComponentSelector cs = cm.lookup(FoodFactory.ROLE + "Selector");
> FoodFactory ff = (FoodFactory) cs.select("ice cream");
>
> But consider "com.food.FoodFactory:type=ice cream,flavor=vanilla". OK,
> that's a very artificial example, but I'm sure someone will want to do
> something similar. I don't think anyone finds SelectorSelectorSelectors
> or ManagerManagerManagers very elegant :)
>
> Enter the Resolver.
>
> I think it's important to be able to:
>
> - define each lookup with a single string
> - integrate other systems behind the Resolver interface
>
> So, in its simplest form, the Resolver would work exactly like the
> ComponentManager (without its limitations or intermediate
> ComponentSelectors). More complex lookups could be defined e.g. using an
> URI-type syntax (with custom protocols for different handlers/back-ends).
>
> Now, about the current proposal, I'm going to question what I don't find
> necessary, and I hope nobody gets offended. I'd also like to hear
> everybody's opinions on this...
>
> ---o---
>
> 1. Object vs. Component vs. Service
>
> Am I the only one who finds this separation somewhat artificial? I mean,
> why should the component using the Resolver care about where the objects
> come from, as long as they match the requested role. Consider the
> following:
>
> component:com.food.FoodFactory
> service:com.food.FoodFactory
>
> vs.
>
> role:com.food.FoodFactory
>
> Also, the objects retrieved from JNDI and ORB, are often components (in
> the real meaning of the word).
>
>
> 2. Loose Query?
>
> If we agree that each lookup can be defined with a single string, the
> real contract is this:
>
> Token lookup(String query);
>
> So what was that ObjectName about?
>
> - Enforcing a common syntax.
> - Improving performance
> (e.g. hashCode(), equals(), static final ObjectName = ...)
>
> To provide this, Query would have to be a concrete class (possibly even
> a final one). If parsing of the query is left to the Resolver, the Query
> interface isn't really necessary, unless it's used like:
>
> interface Resolver {
> Query newQuery();
> Query newQuery(String baseQuery);
>
> or something.
>
>
> 3. Look up one OR many, not both.
>
> I think combining the two just makes things more complex. I would
> consider the following:
>
> lookup(String query);
> lookup(String[] queries);
>
> which would be convenient for both the client and the Resolver
> implementation.
>
>
> I hope you find some of this useful.
>
> (: Anrie ;)
>
> --
> 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Antti Koivunen <an...@users.sourceforge.net>.
While I think something like the Resolver is needed, the current
proposal might be a bit too complex. It, of course, has to be flexible
enough, but also simple, easy, and efficient.
But why do we need it in the first place?
- To get rid of the Component interface.
- To provide a consistent way of looking things up.
- To avoid doing the same thing in the future.
In other words, it has to be flexible enough to suit everyone's needs. I
personally don't care if it's called ServiceManager or whatever (but
Resolver does seem like a nice fit).
Let's say you want to look up "com.food.FoodFactory:type=ice cream".
Here, the current CM/CS works quite well:
ComponentSelector cs = cm.lookup(FoodFactory.ROLE + "Selector");
FoodFactory ff = (FoodFactory) cs.select("ice cream");
But consider "com.food.FoodFactory:type=ice cream,flavor=vanilla". OK,
that's a very artificial example, but I'm sure someone will want to do
something similar. I don't think anyone finds SelectorSelectorSelectors
or ManagerManagerManagers very elegant :)
Enter the Resolver.
I think it's important to be able to:
- define each lookup with a single string
- integrate other systems behind the Resolver interface
So, in its simplest form, the Resolver would work exactly like the
ComponentManager (without its limitations or intermediate
ComponentSelectors). More complex lookups could be defined e.g. using an
URI-type syntax (with custom protocols for different handlers/back-ends).
Now, about the current proposal, I'm going to question what I don't find
necessary, and I hope nobody gets offended. I'd also like to hear
everybody's opinions on this...
---o---
1. Object vs. Component vs. Service
Am I the only one who finds this separation somewhat artificial? I mean,
why should the component using the Resolver care about where the objects
come from, as long as they match the requested role. Consider the following:
component:com.food.FoodFactory
service:com.food.FoodFactory
vs.
role:com.food.FoodFactory
Also, the objects retrieved from JNDI and ORB, are often components (in
the real meaning of the word).
2. Loose Query?
If we agree that each lookup can be defined with a single string, the
real contract is this:
Token lookup(String query);
So what was that ObjectName about?
- Enforcing a common syntax.
- Improving performance
(e.g. hashCode(), equals(), static final ObjectName = ...)
To provide this, Query would have to be a concrete class (possibly even
a final one). If parsing of the query is left to the Resolver, the Query
interface isn't really necessary, unless it's used like:
interface Resolver {
Query newQuery();
Query newQuery(String baseQuery);
or something.
3. Look up one OR many, not both.
I think combining the two just makes things more complex. I would
consider the following:
lookup(String query);
lookup(String[] queries);
which would be convenient for both the client and the Resolver
implementation.
I hope you find some of this useful.
(: Anrie ;)
--
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: Resolver package--Please post your thoughts
Posted by Peter Donald <pe...@apache.org>.
On Thu, 14 Feb 2002 00:08, Sylvain Wallez wrote:
> >* In phoenix there is left emphasis on request based components and more
> > on persistent service components. ie You will never see any Block use
> > ComponentManager.release() because it does not make sense in the context
> > but I suspect at then end of each request a bunch of resources are
> > released back to Cocoons container.
>
> Yes, mainly because they're not ThreadSafe. So, if I understand
> correctly, a block is implicitly considered as thread safe and doesn't
> use the lifestyle interfaces (ThreadSafe, SingleThreaded, etc).
Yep. Where a service needs to provide non ThreadSafe components they do it by
returning a non-threadsafe component from one of the service methods. ie The
Phoenix way would be to do something like
interface ParserManager
{
Parser aquireParser();
void releaseParser( Parser parser );
}
where cocoon would directly get parser component.
> >Yep in Phoenix you can provide multiple services - usually different
> > versions of same sort of service but useful to different users. For
> > instance a Block may suppoort the FooService, ExtendedFooService and
> > FooMBean - each of which is used by different clients but has the same
> > general idea
>
> I guess this mean the block implements the 3 interfaces, or that these
> interfaces extend each other, right ?
A bit of both. A likely arrangement would be
interface FooService {}
interface ExtendedFooService extends FooService {}
interface FooMBean {}
but it is largely up to the implementors.
--
Cheers,
Pete
-----------------------------------------------------
First, we shape our tools, thereafter, they shape us.
-----------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Peter Donald wrote:
>On Wed, 13 Feb 2002 21:04, Sylvain Wallez wrote:
>
>>Something that's missing in component management is some formal
>>description of components : blockinfo provides block dependencies, but
>>we could also have a formal description of the configuration of the
>>component (I don't want to say XMLSchema because of it's heavy weight).
>>
>+100
>
>We have talked about this before but no one ever got around to implementing
>it ;)
>
Stuff that is not absolutely required often has a lower priority, even
if it could make life easier... I'm sure one day we will need it, to
provide non-technical users an easy way to assemble their application or
server.
>>BTW, I know quite well CM/CS for having used it a lot in Cocoon and my
>>projects, but not much Phoenix. It seems to me (and the current
>>discussions enforce this feeling) there's a lot of redundancy both in
>>concepts and code between Service/Block and Component
>>interface/implementation. Moreover, looking at the "what-is-a-block"
>>page, many of the given examples are what we have as components in Cocoon.
>>
>Yep. There are four main differences.
>
>* In Phoenix the container is considered god and enforces all the contracts.
>It provides each block to other blocks only via a proxy and shutsdown the
>proxy when block gets shutdown (eliminating dangling references). It also
>only allows access to components if explicit dependencies are declared and
>makes sure everythings gets called with correct ContextClassLoader and
>ThreadGroup set etc.
>
>* In phoenix there is left emphasis on request based components and more on
>persistent service components. ie You will never see any Block use
>ComponentManager.release() because it does not make sense in the context but
>I suspect at then end of each request a bunch of resources are released back
>to Cocoons container.
>
Yes, mainly because they're not ThreadSafe. So, if I understand
correctly, a block is implicitly considered as thread safe and doesn't
use the lifestyle interfaces (ThreadSafe, SingleThreaded, etc).
>* assembly in Phoenix is more complex and explicit. Except for the
>environment.xml file most of this could be done in a lightweight fashion to
>fit in with cocoon but no one has ever made time to do so ;)
>
>* Phoenix hosts multiple applications in different areas where ECM does a
>single application - but may allow partial isolation via inheritance of ECM
>etc
>
Apart the third point (no lifestyle interfaces because of implicit
thread safety), the main difference I see lies in the usage context :
blocks are managed by the phoenix kernel which provides them with a
local CM where they can lookup their dependencies, while a component is
managed by a (hierarchy of) CM that define a single application (or
container, following Berin's proposal terminology)
>> From what I can, see, a block can provide several services (but AFAICS,
>>most of them provide only one), whereas a component implements only one
>>role. Could you enlighten me on this or point me to relevant resources
>>(other than the web site) ?
>>
>
>Yep in Phoenix you can provide multiple services - usually different versions
>of same sort of service but useful to different users. For instance a Block
>may suppoort the FooService, ExtendedFooService and FooMBean - each of which
>is used by different clients but has the same general idea
>
I guess this mean the block implements the 3 interfaces, or that these
interfaces extend each other, right ?
Thanks for your answers,
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Peter Donald <pe...@apache.org>.
On Wed, 13 Feb 2002 21:04, Sylvain Wallez wrote:
> Something that's missing in component management is some formal
> description of components : blockinfo provides block dependencies, but
> we could also have a formal description of the configuration of the
> component (I don't want to say XMLSchema because of it's heavy weight).
+100
We have talked about this before but no one ever got around to implementing
it ;)
> BTW, I know quite well CM/CS for having used it a lot in Cocoon and my
> projects, but not much Phoenix. It seems to me (and the current
> discussions enforce this feeling) there's a lot of redundancy both in
> concepts and code between Service/Block and Component
> interface/implementation. Moreover, looking at the "what-is-a-block"
> page, many of the given examples are what we have as components in Cocoon.
Yep. There are four main differences.
* In Phoenix the container is considered god and enforces all the contracts.
It provides each block to other blocks only via a proxy and shutsdown the
proxy when block gets shutdown (eliminating dangling references). It also
only allows access to components if explicit dependencies are declared and
makes sure everythings gets called with correct ContextClassLoader and
ThreadGroup set etc.
* In phoenix there is left emphasis on request based components and more on
persistent service components. ie You will never see any Block use
ComponentManager.release() because it does not make sense in the context but
I suspect at then end of each request a bunch of resources are released back
to Cocoons container.
* assembly in Phoenix is more complex and explicit. Except for the
environment.xml file most of this could be done in a lightweight fashion to
fit in with cocoon but no one has ever made time to do so ;)
* Phoenix hosts multiple applications in different areas where ECM does a
single application - but may allow partial isolation via inheritance of ECM
etc
> From what I can, see, a block can provide several services (but AFAICS,
> most of them provide only one), whereas a component implements only one
> role. Could you enlighten me on this or point me to relevant resources
> (other than the web site) ?
Yep in Phoenix you can provide multiple services - usually different versions
of same sort of service but useful to different users. For instance a Block
may suppoort the FooService, ExtendedFooService and FooMBean - each of which
is used by different clients but has the same general idea
--
Cheers,
Pete
*------------------------------------------------------*
| Hlade's Law: If you have a difficult task, give it |
| to a lazy person -- they will find an easier |
| way to do it. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Resolver package--Please post your thoughts
Posted by Stephen McConnell <mc...@apache.org>.
Sylvain Wallez wrote:
[snip]
> BTW, I know quite well CM/CS for having used it a lot in Cocoon and my
> projects, but not much Phoenix. It seems to me (and the current
> discussions enforce this feeling) there's a lot of redundancy both in
> concepts and code between Service/Block and Component
> interface/implementation. Moreover, looking at the "what-is-a-block"
> page, many of the given examples are what we have as components in Cocoon.
>
> From what I can, see, a block can provide several services (but AFAICS,
> most of them provide only one), whereas a component implements only one
> role. Could you enlighten me on this or point me to relevant resources
> (other than the web site) ?
Sylvain:
In the blocks we (OSM) have developed the number of services provided
by a block is typically 2 or more. One service enabling administrative
actions between peer-blocks and another service providing normal
service provisioning. In one case we have a block with about 7 distinct
services. The block is basically mediating requests based on identity
of the invoking principal. Our implementations use Block for highly
granular components (PKI Manager, Time Service, DPML Engine, Collaboration
Framework, Notification Server etc.) whereas the implementation make
extensive use of ComponentManager (and ServiceManager) in the structure
and management of fine grain components (request interceptors, ORBs,
Domain Managers, etc). From that perspective the Block/Component
abstractions map together quite elegantly.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolver package--Please post your thoughts
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch wrote:
> I have tried to address all the shortcommings of the
> ComponentManager/ComponentSelector
> approach in the Resolver package. (located in Avalon Framework
> src/proposals directory).
> If you find that this package does *not* support your needs, or
> appears clumsy/difficult
> to use, please air your grievances now.
>
> Please either take the approach of fine-tuning the interfaces or of
> providing an alternative.
> It also helps when you state the reasons why you beleive your
> alternative is better :)
One thing's that scares me is the use of arrays for obtaining results.
While this allows for one-call retrieval of many objects, this can
easily lead to some nasty bugs related to ordering/numbering of Query
keys, even more considering that query items are added in a non-indexed
way using "Query.addKey()", and objects retrieved in an indexed way
using "Token.references()[i]".
So the question is : is multiple lookups in one call really needed ?
> Since everyone is keen on removing the necessity of marker interfaces
> sooner than later,
> I want a smooth migration path. That means that we need a replacement
> for Component
> resolution (without the Component interface).
>
> It also means that we should do the following:
>
> * Promote ComponentHandler interface and implementations to Framework
> * Provide standard mechanism for registering a Component with a handler
> - ComponentInfo? (like BlockInfo)
Something that's missing in component management is some formal
description of components : blockinfo provides block dependencies, but
we could also have a formal description of the configuration of the
component (I don't want to say XMLSchema because of it's heavy weight).
This would allow building some tools that rely on this information, such
as conf file checkers (are all components correctly configured, and
their dependencies satisfied ?) or GUIs for the graphical assembly of a
system.
> - Manifest entries?
> - Other?
> * Finalize Resolver framework, or whatever the replacement ends up being
>
> If this seems like a winning migration path, and we really like this
> approach, we can make
> it a part of Framework 4.2 or something like that. It is important
> that we have working
> implementations though.
BTW, I know quite well CM/CS for having used it a lot in Cocoon and my
projects, but not much Phoenix. It seems to me (and the current
discussions enforce this feeling) there's a lot of redundancy both in
concepts and code between Service/Block and Component
interface/implementation. Moreover, looking at the "what-is-a-block"
page, many of the given examples are what we have as components in Cocoon.
From what I can, see, a block can provide several services (but AFAICS,
most of them provide only one), whereas a component implements only one
role. Could you enlighten me on this or point me to relevant resources
(other than the web site) ?
Thanks,
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Resolver package--Please post your thoughts
Posted by Paulo Gaspar <pa...@krankikom.de>.
> The ComponentHandler manages the lifestyle--we need a way of
> associating the
> ComponentHandler with the Component implementation without using
> marker interfaces.
I keep making components with separate factories that tell the CM
all about life cycles and I still did not find a better-safer way.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, February 13, 2002 3:28 PM
> To: Avalon Developers List
> Subject: Re: Resolver package--Please post your thoughts
>
>
> Gerhard Froehlich wrote:
> > Berin,
> > see dumb question inline:
> >
> >
> >>I have tried to address all the shortcommings of the
> ComponentManager/ComponentSelector
> >>approach in the Resolver package. (located in Avalon Framework
> src/proposals directory).
> >>If you find that this package does *not* support your needs, or
> appears clumsy/difficult
> >>to use, please air your grievances now.
> >>
> >>Please either take the approach of fine-tuning the interfaces
> or of providing an alternative.
> >>It also helps when you state the reasons why you beleive your
> alternative is better :)
> >>
> >>Since everyone is keen on removing the necessity of marker
> interfaces sooner than later,
> >>I want a smooth migration path. That means that we need a
> replacement for Component
> >>resolution (without the Component interface).
> >>
> >>It also means that we should do the following:
> >>
> >>* Promote ComponentHandler interface and implementations to Framework
> >>
> >
> > This is the "Manager", who handles the Resolver request, or?
>
> This is the policy by which a Component's lifestyle is managed.
> IOW, if A component
> must be pooled, or should have one instance per thread.
>
>
>
> >>* Provide standard mechanism for registering a Component with a handler
> >> - ComponentInfo? (like BlockInfo)
> >> - Manifest entries?
> >> - Other?
> >>
> >
> > What does this "registering with a handler" exactly mean? Does
> it just replaces
> > the Component marker interface, or do you intend to replace all
> interfaces -like
> > Configurable- with that? If yes, do you have a idea how we can
> implement this?
>
> The ComponentHandler manages the lifestyle--we need a way of
> associating the
> ComponentHandler with the Component implementation without using
> marker interfaces.
>
>
>
> >>* Finalize Resolver framework, or whatever the replacement ends up being
> >>
> >>If this seems like a winning migration path, and we really like
> this approach, we can make
> >>it a part of Framework 4.2 or something like that. It is
> important that we have working
> >>implementations though.
> >>
> >
> > Towards a complete re-factoring of the *whole* framework, it's
> surly a method of resolution.
> > But maybe we should look at the *things* standard Java can
> serve us, too (just to prevent
> > to re-invent the wheel twice). Especially the lookup of the objects.
>
>
> Ok.
>
>
>
> --
>
> "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: Resolver package--Please post your thoughts
Posted by Berin Loritsch <bl...@apache.org>.
Gerhard Froehlich wrote:
> Berin,
> see dumb question inline:
>
>
>>I have tried to address all the shortcommings of the ComponentManager/ComponentSelector
>>approach in the Resolver package. (located in Avalon Framework src/proposals directory).
>>If you find that this package does *not* support your needs, or appears clumsy/difficult
>>to use, please air your grievances now.
>>
>>Please either take the approach of fine-tuning the interfaces or of providing an alternative.
>>It also helps when you state the reasons why you beleive your alternative is better :)
>>
>>Since everyone is keen on removing the necessity of marker interfaces sooner than later,
>>I want a smooth migration path. That means that we need a replacement for Component
>>resolution (without the Component interface).
>>
>>It also means that we should do the following:
>>
>>* Promote ComponentHandler interface and implementations to Framework
>>
>
> This is the "Manager", who handles the Resolver request, or?
This is the policy by which a Component's lifestyle is managed. IOW, if A component
must be pooled, or should have one instance per thread.
>>* Provide standard mechanism for registering a Component with a handler
>> - ComponentInfo? (like BlockInfo)
>> - Manifest entries?
>> - Other?
>>
>
> What does this "registering with a handler" exactly mean? Does it just replaces
> the Component marker interface, or do you intend to replace all interfaces -like
> Configurable- with that? If yes, do you have a idea how we can implement this?
The ComponentHandler manages the lifestyle--we need a way of associating the
ComponentHandler with the Component implementation without using marker interfaces.
>>* Finalize Resolver framework, or whatever the replacement ends up being
>>
>>If this seems like a winning migration path, and we really like this approach, we can make
>>it a part of Framework 4.2 or something like that. It is important that we have working
>>implementations though.
>>
>
> Towards a complete re-factoring of the *whole* framework, it's surly a method of resolution.
> But maybe we should look at the *things* standard Java can serve us, too (just to prevent
> to re-invent the wheel twice). Especially the lookup of the objects.
Ok.
--
"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: Resolver package--Please post your thoughts
Posted by Gerhard Froehlich <g-...@gmx.de>.
Berin,
see dumb question inline:
>I have tried to address all the shortcommings of the ComponentManager/ComponentSelector
>approach in the Resolver package. (located in Avalon Framework src/proposals directory).
>If you find that this package does *not* support your needs, or appears clumsy/difficult
>to use, please air your grievances now.
>
>Please either take the approach of fine-tuning the interfaces or of providing an alternative.
>It also helps when you state the reasons why you beleive your alternative is better :)
>
>Since everyone is keen on removing the necessity of marker interfaces sooner than later,
>I want a smooth migration path. That means that we need a replacement for Component
>resolution (without the Component interface).
>
>It also means that we should do the following:
>
>* Promote ComponentHandler interface and implementations to Framework
This is the "Manager", who handles the Resolver request, or?
>* Provide standard mechanism for registering a Component with a handler
> - ComponentInfo? (like BlockInfo)
> - Manifest entries?
> - Other?
What does this "registering with a handler" exactly mean? Does it just replaces
the Component marker interface, or do you intend to replace all interfaces -like
Configurable- with that? If yes, do you have a idea how we can implement this?
>* Finalize Resolver framework, or whatever the replacement ends up being
>
>If this seems like a winning migration path, and we really like this approach, we can make
>it a part of Framework 4.2 or something like that. It is important that we have working
>implementations though.
Towards a complete re-factoring of the *whole* framework, it's surly a method of resolution.
But maybe we should look at the *things* standard Java can serve us, too (just to prevent
to re-invent the wheel twice). Especially the lookup of the objects.
~Gerhard
---------------------------------------------
Very funny, Scotty. Now beam down my clothes.
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Resolver package--Please post your thoughts
Posted by Stephen McConnell <mc...@apache.org>.
Berin:
Here are my thoughts concerning the Resolver.
Comparative table for Resolver/CM/SM
------------------------------------
CM/SM provides lookup based on String
Resolver provides lookup based on String and Query
semantics.
| args args
| lookup hasThing release
------------------------------------------
Resolver | String - Token.release
| Query Query Token.release
|
CM | String String Component
SM | String String Object
Primary difference
1. Resolver has exposure of a Query argument and Token
return structure exposed on the interface.
2. Resolver releases references via the token
whereas CM/SM release references based on
the object/component reference.
Resolver as an extension of Serviceable/ServiceManger
-----------------------------------------------------
What's missing/different?
1. Lookup on SM returns an object which could be a Token
(no problem), however an additional lookup( Query )
would be needed.
2. hasObject on SM takes an Object as an argument and returns
a single boolean whereas Resolver returns a boolean[]
(that's a problem but could be solved with a different
method)
3. SM allows decommission of a object using remove( Object )
This isn't exposed in the Resolver interface because objects
are removed relative to a Token. This can be handled by
an implementation.
Does is make sense for Resolver to extend Service manager - I
think its workable and makes sense in terms of maintaining the
current CM/SM object model.
interface Resolver extends ServiceManager
{
public Token lookupToken( Query );
public boolean[] hasReference( Query );
}
interface Resolvable extends Serviceable
{
public void setResolver( Resolver resolver );
}
Conclusion
----------
My assumption is that your real needs over and above SM is that
you want to package a collection of references that can be
collectively removed (hence the declaration of Query and Token).
Is that a fair and reasonable conclusion? Can Resolvable re
re-cast as an extension of SM - yes it can. What the
benefit? Maintenance of the CM/SM object model (which I happen
to like a lot, suits my needs, its simple and works well, and
most importantly - ensures a smooth consistent migration path).
Cheers, Steve.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Tuesday, 12 February, 2002 19:43
> To: avalon-dev@jakarta.apache.org
> Subject: Resolver package--Please post your thoughts
>
>
> I have tried to address all the shortcommings of the
> ComponentManager/ComponentSelector
> approach in the Resolver package. (located in Avalon Framework
> src/proposals directory).
> If you find that this package does *not* support your needs, or
> appears clumsy/difficult
> to use, please air your grievances now.
>
> Please either take the approach of fine-tuning the interfaces or
> of providing an alternative.
> It also helps when you state the reasons why you beleive your
> alternative is better :)
>
> Since everyone is keen on removing the necessity of marker
> interfaces sooner than later,
> I want a smooth migration path. That means that we need a
> replacement for Component
> resolution (without the Component interface).
>
> It also means that we should do the following:
>
> * Promote ComponentHandler interface and implementations to Framework
> * Provide standard mechanism for registering a Component with a handler
> - ComponentInfo? (like BlockInfo)
> - Manifest entries?
> - Other?
> * Finalize Resolver framework, or whatever the replacement ends up being
>
> If this seems like a winning migration path, and we really like
> this approach, we can make
> it a part of Framework 4.2 or something like that. It is
> important that we have working
> implementations though.
>
>
> --
>
> "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>