You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2002/09/01 15:11:39 UTC
RE: [RT] Management vs. Component Resolution
Just one final note:
the JNDI binding/lookup must be pluggable in the container. For example,
if you use JBoss, then JNDI *requires* all objects bound to it to be
Serializable / Referenceable / etc. So if the container just takes a
component
and tries to bind it (or creates a proxy for it) then the bind()
operation
will most likely fail.
The solution (JBoss specific) is to use a NonSerializableFactory class.
The point is that other JNDI implementations may work differently. I'd
say that
while the lookup () operation on JNDI is well-defined across all
containers (that
I've seen), the bind() operation is not neccesarily so.
One possibility is to define an interface:
interface JNDIPublisher /* implements Component */ {
void bind (String name, Object obj);
Object lookup (String name);
void unbind (String name);
}
and plug the JNDI publisher in as any other component (taking care
not to make it visible to the other components in the container).
/LS
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> >
> > > If you want to access a globally accessible service, you get an
> > > InitialContext()
> >
> > Nitpick: The container gets an InitialContext. The whole point is
> > to be able to access globally accessible services published
> via JNDI
> > via the ServiceManager interface. The Serviceable component
> > should not need to care whether the service comes in via JNDI
> > or whether it is a peer in the container.
>
>
> Fair enough.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] Management vs. Component Resolution
Posted by Stephen McConnell <mc...@apache.org>.
Leo:
I've been thinking a lot about this following the emails from yourself
and Berin. My conclusion is that there are a lot of different and
conflicting requirements - that are all valid because they are dealing
with different applications needs for a Container at quite different
scales and application domains.
My current thinking is that we should seperate "service-management" from
"component-management". I've restructured the Merlin Container interface
such that it is only dealing with "component-management" and provides a
"isolation" model. Given this change, the subject of
"service-management" can be dealt with somewhat more freely and under
different interfaces addressing the different requirements.
Some of the possible "service-management" requirements:
service aggreggation
Where all service are published to a aggregator
E.g. take this container specification and give me
back the set of candidate services that it declares.
This is required in cases where you are using a
container as an internal part of the component
management system - e.g. the parent container
delegates a part of component management to a
sub-container, get the aggreggated set of services,
and applies its own service management policies.
service location
Where services are disclosed based on a request for
the service - similar to a http protocol - if I know
the page I get the page and if I don't I get a 404,
or the ECM model based on a structured lookup matching
and interface name or service key.
This is required in situations where you have the need
to provide access to services that *may* be available
but the keys are not know at assembly time. For example
a container monitoring a set of jar files representing
plug-in extensions. The disclosure is based on the
addition of a jar file to a directory, combined with
service attribiutes on compoonent descriptors that
possibly constrain service visibility.
service publication
Where a container publishes services into a service
publication system (e.g. JNDI). The container publishes
services into to the extenal publication system based on
container specific directives and component descriptors.
Cheers, Steve.
Leo Sutic wrote:
> Just one final note:
>
> the JNDI binding/lookup must be pluggable in the container. For example,
> if you use JBoss, then JNDI *requires* all objects bound to it to be
> Serializable / Referenceable / etc. So if the container just takes a
> component
> and tries to bind it (or creates a proxy for it) then the bind()
> operation
> will most likely fail.
>
> The solution (JBoss specific) is to use a NonSerializableFactory class.
>
> The point is that other JNDI implementations may work differently. I'd
> say that
> while the lookup () operation on JNDI is well-defined across all
> containers (that
> I've seen), the bind() operation is not neccesarily so.
>
> One possibility is to define an interface:
>
> interface JNDIPublisher /* implements Component */ {
> void bind (String name, Object obj);
> Object lookup (String name);
> void unbind (String name);
> }
>
> and plug the JNDI publisher in as any other component (taking care
> not to make it visible to the other components in the container).
>
> /LS
>
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>
>>>From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>>>
>>>
>>>
>>>>If you want to access a globally accessible service, you get an
>>>>InitialContext()
>>>
>>>Nitpick: The container gets an InitialContext. The whole point is
>>>to be able to access globally accessible services published
>>
>>via JNDI
>>
>>>via the ServiceManager interface. The Serviceable component
>>>should not need to care whether the service comes in via JNDI
>>>or whether it is a peer in the container.
>>
>>
>>Fair enough.
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] Management vs. Component Resolution
Posted by Peter Donald <pe...@apache.org>.
On Sun, 1 Sep 2002 23:11, Leo Sutic wrote:
> Just one final note:
>
> the JNDI binding/lookup must be pluggable in the container. For example,
> if you use JBoss, then JNDI *requires* all objects bound to it to be
> Serializable / Referenceable / etc. So if the container just takes a
> component
> and tries to bind it (or creates a proxy for it) then the bind()
> operation
> will most likely fail.
>
> The solution (JBoss specific) is to use a NonSerializableFactory class.
>
> The point is that other JNDI implementations may work differently. I'd
> say that
> while the lookup () operation on JNDI is well-defined across all
> containers (that
> I've seen), the bind() operation is not neccesarily so.
>
> One possibility is to define an interface:
>
> interface JNDIPublisher /* implements Component */ {
> void bind (String name, Object obj);
> Object lookup (String name);
> void unbind (String name);
> }
>
> and plug the JNDI publisher in as any other component (taking care
> not to make it visible to the other components in the container).
I would LOVE to see this. I have actually implemented this twice in past (for
jboss, weblogic and jonas) but never been able to release it.
Another component I would love to see in this space is
interface AppServerStartup
{
void onStartup( JNDIPublisher pub ) throws Exception;
}
And this would be able to tie into whatever appserver specific mechanisms
exist for triggering things on startup. Each use different mechanisms - most
are easy to use (ie jboss/weblogic) but some are PITA!
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>