You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2006/07/24 14:11:52 UTC
JNDI factories to provide access to the JBI bus
I have just created a JIRA (see
http://issues.apache.org/activemq/browse/SM-495).
This feature is to provide a better and consistent way to access the JBI bus
from anywhere within the JVM.
I think that JNDI is the good way to do that.
I have already discussed that a bit with Aaron Mulder at ApacheCon EU when
we were looking at Geronimo
integration (we had also thought about using a JCA connector, but this is a
more heavyweight and limited solution).
So I propose the following:
1) create a JNDI factory to create servicemix clients and bind it to the
JNDI tree
I' m not sure yet if we should bind a JNDI factory were you would
directly
retrieve a new client when performing a lookup, or a "real" factory which
would enable
the user to create a client. The second solution can be useful to pass
additional parameters
such as the user credentials. I' m not sure how JNDI works with security
/ JAAS, so any
input is welcome.
2) we may want to bind a modified implementation of the factory and bind it
to the JNDI context
for a component. This factory would use the ComponentContext and build
a client on top
of it instead of creating a new client (which activate a lightweight
component).
The only problem is that we would need to have one JNDI context per
component and this
is not done currently (is that really needed ?)
3) we also need to define an interface implemented by the JBIContainer so
that we can also bind
it in the JNDI tree. I think it would be useful to access ServiceMix
specific features without
relying on some casts like (JBIContainer) ((ComponentContextImpl)
context).getContainer()
which is currently the only way to retrieve the JBIContainer from a
component.
Any thoughts or volunteer ;) ?
Cheers,
Guillaume Nodet
Re: JNDI factories to provide access to the JBI bus
Posted by Guillaume Nodet <gn...@gmail.com>.
On 7/25/06, James Strachan <ja...@gmail.com> wrote:
>
> On 7/25/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > It seems that remoting a jmx client is not so easy.
> > All classes involved must be serializable or mbeans i think.
> > And this is not the case at all (the client has a pointer to the
> container,
> > the DefaultDestination has a pointer to the client, etc..)
> > So if we want to go that way, we have to provide wrapper for all
> > non serializable classes involved in the client api.
> >
> > So i will let the remote stuff aside for the moment.
> > It makes me thing that the first draft of the client api James put
> > in svn was simpler and easier use in a remote mode.
> >
> http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Client.html
> >
> http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Destination.html
> >
> > Should we revert back to it ?
>
> I guess we could. We could make ServiceMixClient extend Client as an
> interface.
>
> We could maybe have a client side version of Destination which is
> really just a facade on a ServiceMixClient interface? So keep, say,
> ServiceMixClient remote and have a client side facade using it to give
> the nice URI style API
Well, the problem is that the ServiceMixClient interface is not easily
remotable :(
Btw, the use of a remote api itself may be questioned. If you are in the
same jvm,
it is a big overhead to do remoting or to go through a BC to send exchanges.
But if you are remote, you can easily use HTTP or JMS instead of using a
remote api.
A user just sent a mail about using the RemoteClient to query endpoints
(which seems
to not work in his case), but i'm not sure of the use for that.
Just trying to find a good use case.
Cheers,
Guillaume Nodet
Guillaume
--
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: JNDI factories to provide access to the JBI bus
Posted by James Strachan <ja...@gmail.com>.
On 7/25/06, Guillaume Nodet <gn...@gmail.com> wrote:
> It seems that remoting a jmx client is not so easy.
> All classes involved must be serializable or mbeans i think.
> And this is not the case at all (the client has a pointer to the container,
> the DefaultDestination has a pointer to the client, etc..)
> So if we want to go that way, we have to provide wrapper for all
> non serializable classes involved in the client api.
>
> So i will let the remote stuff aside for the moment.
> It makes me thing that the first draft of the client api James put
> in svn was simpler and easier use in a remote mode.
> http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Client.html
> http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Destination.html
>
> Should we revert back to it ?
I guess we could. We could make ServiceMixClient extend Client as an interface.
We could maybe have a client side version of Destination which is
really just a facade on a ServiceMixClient interface? So keep, say,
ServiceMixClient remote and have a client side facade using it to give
the nice URI style API
--
James
-------
http://radio.weblogs.com/0112098/
Re: JNDI factories to provide access to the JBI bus
Posted by Guillaume Nodet <gn...@gmail.com>.
It seems that remoting a jmx client is not so easy.
All classes involved must be serializable or mbeans i think.
And this is not the case at all (the client has a pointer to the container,
the DefaultDestination has a pointer to the client, etc..)
So if we want to go that way, we have to provide wrapper for all
non serializable classes involved in the client api.
So i will let the remote stuff aside for the moment.
It makes me thing that the first draft of the client api James put
in svn was simpler and easier use in a remote mode.
http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Client.html
http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Destination.html
Should we revert back to it ?
Cheers,
Guillaume Nodet
On 7/25/06, James Strachan <ja...@gmail.com> wrote:
>
> On 7/25/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > I do not really see the point of having several different mechanism to
> > access the same objects.
> > If JMX is easier to use, let's use it.
> > This will also allow us to have a remote client easily, without relying
> on a
> > clustered flow.
> >
> > We could define a simple helper beans (and/or a factory bean)
> > that would return the ClientFactory given a MBeanServerConnection (which
> can
> > be local or remote).
> >
> > public class ClientFactoryHelper {
> > public ClientFactory getClientFactory(MBeanServerConnection server) {
> > ...
> > }
> > // in case the container does not have the default name
> > public ClientFactory getClientFactory(MBeanServerConnection server,
> String
> > containerName) {
> > ...
> > }
> > public ClientFactory getClientFactory(String host, String port) {
> > ...
> > }
> > // in case the container does not have the default name
> > public ClientFactory getClientFactory(String host, String port, String
> > container) {
> > ...
> > }
> > }
> >
> > /**
> > * We may need a way to authenticate the user using login/password
> > * so keep a level of indirection using a factory
> > */
> > public interface ClientFactory {
> > public ServiceMixClient createClient();
> > // public ServiceMixClient createClient(String user, String password);
> > }
> >
> > We just need to expose the implementation of the ClientFactory in the
> mbean
> > server.
> > Any comments ?
>
> Yeah that'll work (and do the remoting piece too).
>
> Another approach is just to configure the ClientFactory as a POJO in
> the JNDI provider thats used by the server - such as in Tomcat or
> Jetty or some of the other J2EE servers.
>
> Either sound good to me; using a container-specific JNDI provider or JMX
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: JNDI factories to provide access to the JBI bus
Posted by James Strachan <ja...@gmail.com>.
On 7/25/06, Guillaume Nodet <gn...@gmail.com> wrote:
> I do not really see the point of having several different mechanism to
> access the same objects.
> If JMX is easier to use, let's use it.
> This will also allow us to have a remote client easily, without relying on a
> clustered flow.
>
> We could define a simple helper beans (and/or a factory bean)
> that would return the ClientFactory given a MBeanServerConnection (which can
> be local or remote).
>
> public class ClientFactoryHelper {
> public ClientFactory getClientFactory(MBeanServerConnection server) {
> ...
> }
> // in case the container does not have the default name
> public ClientFactory getClientFactory(MBeanServerConnection server, String
> containerName) {
> ...
> }
> public ClientFactory getClientFactory(String host, String port) {
> ...
> }
> // in case the container does not have the default name
> public ClientFactory getClientFactory(String host, String port, String
> container) {
> ...
> }
> }
>
> /**
> * We may need a way to authenticate the user using login/password
> * so keep a level of indirection using a factory
> */
> public interface ClientFactory {
> public ServiceMixClient createClient();
> // public ServiceMixClient createClient(String user, String password);
> }
>
> We just need to expose the implementation of the ClientFactory in the mbean
> server.
> Any comments ?
Yeah that'll work (and do the remoting piece too).
Another approach is just to configure the ClientFactory as a POJO in
the JNDI provider thats used by the server - such as in Tomcat or
Jetty or some of the other J2EE servers.
Either sound good to me; using a container-specific JNDI provider or JMX
--
James
-------
http://radio.weblogs.com/0112098/
Re: JNDI factories to provide access to the JBI bus
Posted by Guillaume Nodet <gn...@gmail.com>.
I do not really see the point of having several different mechanism to
access the same objects.
If JMX is easier to use, let's use it.
This will also allow us to have a remote client easily, without relying on a
clustered flow.
We could define a simple helper beans (and/or a factory bean)
that would return the ClientFactory given a MBeanServerConnection (which can
be local or remote).
public class ClientFactoryHelper {
public ClientFactory getClientFactory(MBeanServerConnection server) {
...
}
// in case the container does not have the default name
public ClientFactory getClientFactory(MBeanServerConnection server, String
containerName) {
...
}
public ClientFactory getClientFactory(String host, String port) {
...
}
// in case the container does not have the default name
public ClientFactory getClientFactory(String host, String port, String
container) {
...
}
}
/**
* We may need a way to authenticate the user using login/password
* so keep a level of indirection using a factory
*/
public interface ClientFactory {
public ServiceMixClient createClient();
// public ServiceMixClient createClient(String user, String password);
}
We just need to expose the implementation of the ClientFactory in the mbean
server.
Any comments ?
Cheers,
Guillaume Nodet
On 7/25/06, James Strachan <ja...@gmail.com> wrote:
>
> On 7/25/06, Philip Dodds <ph...@gmail.com> wrote:
> > Good point - since if it works in Spring we should be in good shape for
> the
> > others !
>
> Yeah - using Spring we can auto-export POJOs as MBeans...
>
> http://static.springframework.org/spring/docs/2.0.x/reference/jmx.html
>
> I hope there's some similar mechanism for GBeans too. so we could duck
> being too app-server specific.
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: JNDI factories to provide access to the JBI bus
Posted by James Strachan <ja...@gmail.com>.
On 7/25/06, Philip Dodds <ph...@gmail.com> wrote:
> Good point - since if it works in Spring we should be in good shape for the
> others !
Yeah - using Spring we can auto-export POJOs as MBeans...
http://static.springframework.org/spring/docs/2.0.x/reference/jmx.html
I hope there's some similar mechanism for GBeans too. so we could duck
being too app-server specific.
--
James
-------
http://radio.weblogs.com/0112098/
Re: JNDI factories to provide access to the JBI bus
Posted by Philip Dodds <ph...@gmail.com>.
Good point - since if it works in Spring we should be in good shape for the
others !
P
On 7/25/06, James Strachan <ja...@gmail.com> wrote:
>
> Agreed with everything said so far.
>
> My favourite approach first would be to solve the problem for spring
> users; then look at GBean or MBean(JBoss SAR) folks later on. So we
> should be able to make a POJO thingy first then make it an MBean/GBean
> later.
>
> On 7/25/06, Philip Dodds <ph...@gmail.com> wrote:
> > I think the idea of JNDI factories is great, and making it workable in
> > other application servers would be a blessing for people trying to
> > integration from web applications etc.
> >
> > Offering a simple interface that allows a factory to get an instance of
> an
> > endpont to interact with would be an interesting way or promoting JBI
> use in
> > more traditional applications.
> >
> > The question I suppose is how the remote and local natures would be
> > handled, are you planning on binding using a GBean in Geronimo? Could
> the
> > code be re-used and deployed in JBoss with a SAR I wonder?
> >
> > P
> >
> > On 7/24/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > >
> > > I have just created a JIRA (see
> > > http://issues.apache.org/activemq/browse/SM-495).
> > > This feature is to provide a better and consistent way to access the
> JBI
> > > bus
> > > from anywhere within the JVM.
> > > I think that JNDI is the good way to do that.
> > > I have already discussed that a bit with Aaron Mulder at ApacheCon EU
> when
> > > we were looking at Geronimo
> > > integration (we had also thought about using a JCA connector, but this
> is
> > > a
> > > more heavyweight and limited solution).
> > >
> > > So I propose the following:
> > >
> > > 1) create a JNDI factory to create servicemix clients and bind it to
> the
> > > JNDI tree
> > > I' m not sure yet if we should bind a JNDI factory were you would
> > > directly
> > > retrieve a new client when performing a lookup, or a "real" factory
> > > which
> > > would enable
> > > the user to create a client. The second solution can be useful to
> pass
> > > additional parameters
> > > such as the user credentials. I' m not sure how JNDI works with
> > > security
> > > / JAAS, so any
> > > input is welcome.
> > >
> > > 2) we may want to bind a modified implementation of the factory and
> bind
> > > it
> > > to the JNDI context
> > > for a component. This factory would use the ComponentContext and
> > > build
> > > a client on top
> > > of it instead of creating a new client (which activate a
> lightweight
> > > component).
> > > The only problem is that we would need to have one JNDI context
> per
> > > component and this
> > > is not done currently (is that really needed ?)
> > >
> > > 3) we also need to define an interface implemented by the JBIContainer
> so
> > > that we can also bind
> > > it in the JNDI tree. I think it would be useful to access
> ServiceMix
> > > specific features without
> > > relying on some casts like (JBIContainer) ((ComponentContextImpl)
> > > context).getContainer()
> > > which is currently the only way to retrieve the JBIContainer from
> a
> > > component.
> > >
> > > Any thoughts or volunteer ;) ?
> > >
> > > Cheers,
> > > Guillaume Nodet
> > >
> > >
> >
> >
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: JNDI factories to provide access to the JBI bus
Posted by James Strachan <ja...@gmail.com>.
Agreed with everything said so far.
My favourite approach first would be to solve the problem for spring
users; then look at GBean or MBean(JBoss SAR) folks later on. So we
should be able to make a POJO thingy first then make it an MBean/GBean
later.
On 7/25/06, Philip Dodds <ph...@gmail.com> wrote:
> I think the idea of JNDI factories is great, and making it workable in
> other application servers would be a blessing for people trying to
> integration from web applications etc.
>
> Offering a simple interface that allows a factory to get an instance of an
> endpont to interact with would be an interesting way or promoting JBI use in
> more traditional applications.
>
> The question I suppose is how the remote and local natures would be
> handled, are you planning on binding using a GBean in Geronimo? Could the
> code be re-used and deployed in JBoss with a SAR I wonder?
>
> P
>
> On 7/24/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > I have just created a JIRA (see
> > http://issues.apache.org/activemq/browse/SM-495).
> > This feature is to provide a better and consistent way to access the JBI
> > bus
> > from anywhere within the JVM.
> > I think that JNDI is the good way to do that.
> > I have already discussed that a bit with Aaron Mulder at ApacheCon EU when
> > we were looking at Geronimo
> > integration (we had also thought about using a JCA connector, but this is
> > a
> > more heavyweight and limited solution).
> >
> > So I propose the following:
> >
> > 1) create a JNDI factory to create servicemix clients and bind it to the
> > JNDI tree
> > I' m not sure yet if we should bind a JNDI factory were you would
> > directly
> > retrieve a new client when performing a lookup, or a "real" factory
> > which
> > would enable
> > the user to create a client. The second solution can be useful to pass
> > additional parameters
> > such as the user credentials. I' m not sure how JNDI works with
> > security
> > / JAAS, so any
> > input is welcome.
> >
> > 2) we may want to bind a modified implementation of the factory and bind
> > it
> > to the JNDI context
> > for a component. This factory would use the ComponentContext and
> > build
> > a client on top
> > of it instead of creating a new client (which activate a lightweight
> > component).
> > The only problem is that we would need to have one JNDI context per
> > component and this
> > is not done currently (is that really needed ?)
> >
> > 3) we also need to define an interface implemented by the JBIContainer so
> > that we can also bind
> > it in the JNDI tree. I think it would be useful to access ServiceMix
> > specific features without
> > relying on some casts like (JBIContainer) ((ComponentContextImpl)
> > context).getContainer()
> > which is currently the only way to retrieve the JBIContainer from a
> > component.
> >
> > Any thoughts or volunteer ;) ?
> >
> > Cheers,
> > Guillaume Nodet
> >
> >
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: JNDI factories to provide access to the JBI bus
Posted by Philip Dodds <ph...@gmail.com>.
I think the idea of JNDI factories is great, and making it workable in
other application servers would be a blessing for people trying to
integration from web applications etc.
Offering a simple interface that allows a factory to get an instance of an
endpont to interact with would be an interesting way or promoting JBI use in
more traditional applications.
The question I suppose is how the remote and local natures would be
handled, are you planning on binding using a GBean in Geronimo? Could the
code be re-used and deployed in JBoss with a SAR I wonder?
P
On 7/24/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> I have just created a JIRA (see
> http://issues.apache.org/activemq/browse/SM-495).
> This feature is to provide a better and consistent way to access the JBI
> bus
> from anywhere within the JVM.
> I think that JNDI is the good way to do that.
> I have already discussed that a bit with Aaron Mulder at ApacheCon EU when
> we were looking at Geronimo
> integration (we had also thought about using a JCA connector, but this is
> a
> more heavyweight and limited solution).
>
> So I propose the following:
>
> 1) create a JNDI factory to create servicemix clients and bind it to the
> JNDI tree
> I' m not sure yet if we should bind a JNDI factory were you would
> directly
> retrieve a new client when performing a lookup, or a "real" factory
> which
> would enable
> the user to create a client. The second solution can be useful to pass
> additional parameters
> such as the user credentials. I' m not sure how JNDI works with
> security
> / JAAS, so any
> input is welcome.
>
> 2) we may want to bind a modified implementation of the factory and bind
> it
> to the JNDI context
> for a component. This factory would use the ComponentContext and
> build
> a client on top
> of it instead of creating a new client (which activate a lightweight
> component).
> The only problem is that we would need to have one JNDI context per
> component and this
> is not done currently (is that really needed ?)
>
> 3) we also need to define an interface implemented by the JBIContainer so
> that we can also bind
> it in the JNDI tree. I think it would be useful to access ServiceMix
> specific features without
> relying on some casts like (JBIContainer) ((ComponentContextImpl)
> context).getContainer()
> which is currently the only way to retrieve the JBIContainer from a
> component.
>
> Any thoughts or volunteer ;) ?
>
> Cheers,
> Guillaume Nodet
>
>