Re: [JBoss-user] Using JMS resources (or other resources)
> > There is a workaround/hack that uses the way the Container currently is > implemented: use instead of . Here is a working > jboss.xml for the Publisher bean from the SUN JMS tutorial: > Thanks, this works fine (for now). --jason ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
> I'll look at adding support for the resource-env-ref when I > fix an existing namespace issue. If you get time that would be nice. I would rather not have to manage accessing two different contexts. --jason ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
> For binding a subcontext from a remote server you should be able to use the >Context.PROVIDER_URL > to specify the subcontext and so the SubContext attribute should not be necessary. To > create a local alias I would rather create a new NamingAlias mbean that created >LinkRefs: > name=":service=NamingAlias,fromName=java:jms/topic"> > java:jms/topic > topic > That would be great. I guess this started because I was unable to lookup a QueueConnection (which I still have not had time to figure out based on the given suggestions). I just ran into another issues, where a deployed servlet needs to access a SSB and EB on a different VM. I installed a ExternalContext (very nice), then modified my code to use an InitialContext(), then get the mapped sub-context and use it for Home lookups. Sounds fine... until I start working with EJB handles... which will just use the InitialContext(), not a sub-context there of. If there was a nice way to create an alias to the default names (from the imported external context), then I would not have to perform an *magic* to restore a handle. Anyways, it sounds like a NamingAlias MBean would be a helpful feature. --jason ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
On 17 Apr, Scott M Stark wrote: > > - Original Message - > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, April 17, 2001 11:16 AM > Subject: Re: [JBoss-user] Using JMS resources (or other resources) > > >> >> Well, I naively tried that: >> >> localhost:1199/topic >> >> But that did not work. Looking at the code for jnp it does not look as >> if the subcontexts is picked up. Have you gotten this to work? >> > I have tried it with providers other than jnp and it works. I'll fix the jnp > code to work as well. > Well, thats great. You are a cool man ;-) > > >> > Is all that your trying to do related to the current fact that the >ApplicationMetaData >> > object requires resource names to be relative to the java: context? I view this >> > requirement as invalid and I am going to remove this requirement so that resource >> > references can refer to any context. >> > >> >> Both yes and no. Locally it would be better if the java: requirement was >> removed from ApplicationMetaData (or JMS stuff is added to the Container >> resource handling - like is done for mail) so that java: is not needed >> any more for resource-refs. (Why is it there in the first place). >> >> But I also want it because with JMS you will often want to send messages >> to destinations on other servers. But for that problem, ExternalContext >> is the solution. >> > Once the requirement that a resource-ref jndi name be relative the java: context > is removed you can do as you please using ExternalContext to bind the remote > server contexts under whatever name you choose. I'm going to commit the > change that removes the current ApplicationMetaData requirement for the java: > prefix today to the main branch. Great! > >> (For Message Driven Beans this already works perfect, but thats only >> because we have total control over the environment and does all naming >> lookups via a JMSProviderAdapter. For a resource adapter for JMS the >> challange is that the lookup of the ConnectionFactories is under our >> control, but not the lookup of the destination. This mean to get non >> compliant API we need some way to bind in external destinations through >> the resource framework. Since this will be the only way to get access to >> external destination I want the way to use JMS to be symetric. You >> basically should use the same way to reference destinations, be they >> local or externa. If the deployment stuff is changed so that we can >> reference for example topic/testTopic without the url-hack, all will be >> fine - I think. ) >> > Ok. Pickup the change to ApplicationMetaData when you see the commit > and let me know if that solves your problem. Ok. Thanks. //Peter > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 17, 2001 11:16 AM Subject: Re: [JBoss-user] Using JMS resources (or other resources) > > Well, I naively tried that: > > localhost:1199/topic > > But that did not work. Looking at the code for jnp it does not look as > if the subcontexts is picked up. Have you gotten this to work? > I have tried it with providers other than jnp and it works. I'll fix the jnp code to work as well. > > Is all that your trying to do related to the current fact that the >ApplicationMetaData > > object requires resource names to be relative to the java: context? I view this > > requirement as invalid and I am going to remove this requirement so that resource > > references can refer to any context. > > > > Both yes and no. Locally it would be better if the java: requirement was > removed from ApplicationMetaData (or JMS stuff is added to the Container > resource handling - like is done for mail) so that java: is not needed > any more for resource-refs. (Why is it there in the first place). > > But I also want it because with JMS you will often want to send messages > to destinations on other servers. But for that problem, ExternalContext > is the solution. > Once the requirement that a resource-ref jndi name be relative the java: context is removed you can do as you please using ExternalContext to bind the remote server contexts under whatever name you choose. I'm going to commit the change that removes the current ApplicationMetaData requirement for the java: prefix today to the main branch. > (For Message Driven Beans this already works perfect, but thats only > because we have total control over the environment and does all naming > lookups via a JMSProviderAdapter. For a resource adapter for JMS the > challange is that the lookup of the ConnectionFactories is under our > control, but not the lookup of the destination. This mean to get non > compliant API we need some way to bind in external destinations through > the resource framework. Since this will be the only way to get access to > external destination I want the way to use JMS to be symetric. You > basically should use the same way to reference destinations, be they > local or externa. If the deployment stuff is changed so that we can > reference for example topic/testTopic without the url-hack, all will be > fine - I think. ) > Ok. Pickup the change to ApplicationMetaData when you see the commit and let me know if that solves your problem. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
On 17 Apr, Scott M Stark wrote: > > On 17 Apr: Peter Antman wrote: >> Wow, seems to be almost exactly what I need. It does also look like this >> could solve our little problem with the JMS objects not being in the >> java: namespace. >> > >> Then we could write an mbean entry like this: >> >>name=":service=ExternalContext,jndiName=jms"> >> java:jms/topic >> topic >> javax.naming.InitialContext >> jndi.properties >> >> > For binding a subcontext from a remote server you should be able to use the >Context.PROVIDER_URL > to specify the subcontext and so the SubContext attribute should not be necessary. Well, I naively tried that: localhost:1199/topic But that did not work. Looking at the code for jnp it does not look as if the subcontexts is picked up. Have you gotten this to work? >To > create a local alias I would rather create a new NamingAlias mbean that created >LinkRefs: > name=":service=NamingAlias,fromName=java:jms/topic"> > java:jms/topic > topic > > >> And there by have bound all current and future topics to the JNDI >> java:jms/topic >> >> Then the res-jndi-name would work: >> >> java:jms/topic/testTopic >> >> >> The only problem then is the ConnectionFactorys, since they are bound to >> the "" namespace. Locally that could be solved by a LinkRef, but to >> another server, I still do not know how to do it. >> > Is all that your trying to do related to the current fact that the >ApplicationMetaData > object requires resource names to be relative to the java: context? I view this > requirement as invalid and I am going to remove this requirement so that resource > references can refer to any context. > Both yes and no. Locally it would be better if the java: requirement was removed from ApplicationMetaData (or JMS stuff is added to the Container resource handling - like is done for mail) so that java: is not needed any more for resource-refs. (Why is it there in the first place). But I also want it because with JMS you will often want to send messages to destinations on other servers. But for that problem, ExternalContext is the solution. (For Message Driven Beans this already works perfect, but thats only because we have total control over the environment and does all naming lookups via a JMSProviderAdapter. For a resource adapter for JMS the challange is that the lookup of the ConnectionFactories is under our control, but not the lookup of the destination. This mean to get non compliant API we need some way to bind in external destinations through the resource framework. Since this will be the only way to get access to external destination I want the way to use JMS to be symetric. You basically should use the same way to reference destinations, be they local or externa. If the deployment stuff is changed so that we can reference for example topic/testTopic without the url-hack, all will be fine - I think. ) //Peter > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
On 17 Apr: Peter Antman wrote: > Wow, seems to be almost exactly what I need. It does also look like this > could solve our little problem with the JMS objects not being in the > java: namespace. > > Then we could write an mbean entry like this: > >name=":service=ExternalContext,jndiName=jms"> > java:jms/topic > topic > javax.naming.InitialContext > jndi.properties > > For binding a subcontext from a remote server you should be able to use the Context.PROVIDER_URL to specify the subcontext and so the SubContext attribute should not be necessary. To create a local alias I would rather create a new NamingAlias mbean that created LinkRefs: java:jms/topic topic > And there by have bound all current and future topics to the JNDI > java:jms/topic > > Then the res-jndi-name would work: > > java:jms/topic/testTopic > > > The only problem then is the ConnectionFactorys, since they are bound to > the "" namespace. Localy that could be solved by a LinkRef, but to > another server, I still do not know how to do it. > Is all that your trying to do related to the current fact that the ApplicationMetaData object requires resource names to be relative to the java: context? I view this requirement as invalid and I am going to remove this requirement so that resource references can refer to any context. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
On 16 Apr, Scott M Stark wrote: > The ExternalContext mbean service supports this. All it is doing it binding > a Reference to a Context from the external server. You could use it statically, > programmatically or just mimic its behavior. The class is >org.jboss.naming.ExternalContext. Wow, seems to be almost exactly what I need. It does also look like this could solve our little problem with the JMS objects not being in the java: namespace. This little entry could solve that: java:jms javax.naming.InitialContext jndi.properties However the side effect is that all names under the "" namespace will be available through java:jms. Scott, would it be possible to sort of ad the functionality to bind in to an external subcontext. Sort of this way: topic Context newContext() throws Exception { if( initialContext == null ) { // First check the NonSerializableFactory cache initialContext = (Context) NonSerializableFactory.lookup(jndiName); // Create the context from the contextClass and contextProps if( initialContext == null ) { initialContext = newContext(contextClass, contextProps); // Added stuf for subcontext if(subContext != null) { initialContext = (Context)initialContext.lookup(subContext); } } } return initialContext; } Would that work? Then we could write an mbean entry like this: java:jms/topic topic javax.naming.InitialContext jndi.properties And there by have bound all current and future topics to the JNDI java:jms/topic Then the res-jndi-name would work: java:jms/topic/testTopic The only problem then is the ConnectionFactorys, since they are bound to the "" namespace. Localy that could be solved by a LinkRef, but to another server, I still do not know how to do it. //Peter > > - Original Message - > From: "Alexander Kogan" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, April 16, 2001 12:50 PM > Subject: Re: [JBoss-user] Using JMS resources (or other resources) > > >> [EMAIL PROTECTED] wrote: >> > >> > >> > Is it possible to contsruct some sort of factory that rules a complete >> > subcontext. An example: Suppose I want to send JMS messages from server >> > A to B. At A I would like to define a namspace like this: >> > java/serverB-jms I would then like to be able to lookup for example >> > java:/serverB-jms/topic/testTopic or >> > java:/serverB-jms/TopicConnectionFactory. But I do not want to have to >> > bind al those name into the A JNDI, only the java/serverB-jms. This name >> > should then somehow be bound to a factory that would lookup and returns >> > the objects from the remote machine. >> > >> > Any thoughts any one? >> >> Would "federation" help there? >> >> -- >> __ >> Alexander Kogan PTC www.ptc.com >> [EMAIL PROTECTED]140 Kendrick St. Needham MA 02494 >> >> ___ >> JBoss-user mailing list >> [EMAIL PROTECTED] >> http://lists.sourceforge.net/lists/listinfo/jboss-user >> > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user -- Jobba hos oss: http://www.tim.se/weblab Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
On 16 Apr, Alexander Kogan wrote: > [EMAIL PROTECTED] wrote: >> >> >> Is it possible to contsruct some sort of factory that rules a complete >> subcontext. An example: Suppose I want to send JMS messages from server >> A to B. At A I would like to define a namspace like this: >> java/serverB-jms I would then like to be able to lookup for example >> java:/serverB-jms/topic/testTopic or >> java:/serverB-jms/TopicConnectionFactory. But I do not want to have to >> bind al those name into the A JNDI, only the java/serverB-jms. This name >> should then somehow be bound to a factory that would lookup and returns >> the objects from the remote machine. >> >> Any thoughts any one? > > Would "federation" help there? > It shure sounds like that. But I have found no example of how to do that. Would it be possible to sort of bind in server-b:1099 into a subcontext of server-a? For now I am investigating the possibility of binding a StringRefAddr with type URL and the external url (perhaps jnp://server-b:1099) in a Reference, and hope that the server will return a ResolvResult to the JNDI client. But I have not followed that thought to it's end yet. //Peter -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
The ExternalContext mbean service supports this. All it is doing it binding a Reference to a Context from the external server. You could use it statically, programmatically or just mimic its behavior. The class is org.jboss.naming.ExternalContext. - Original Message - From: "Alexander Kogan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, April 16, 2001 12:50 PM Subject: Re: [JBoss-user] Using JMS resources (or other resources) > [EMAIL PROTECTED] wrote: > > > > > > Is it possible to contsruct some sort of factory that rules a complete > > subcontext. An example: Suppose I want to send JMS messages from server > > A to B. At A I would like to define a namspace like this: > > java/serverB-jms I would then like to be able to lookup for example > > java:/serverB-jms/topic/testTopic or > > java:/serverB-jms/TopicConnectionFactory. But I do not want to have to > > bind al those name into the A JNDI, only the java/serverB-jms. This name > > should then somehow be bound to a factory that would lookup and returns > > the objects from the remote machine. > > > > Any thoughts any one? > > Would "federation" help there? > > -- > __ > Alexander Kogan PTC www.ptc.com > [EMAIL PROTECTED]140 Kendrick St. Needham MA 02494 > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
[EMAIL PROTECTED] wrote: > > > Is it possible to contsruct some sort of factory that rules a complete > subcontext. An example: Suppose I want to send JMS messages from server > A to B. At A I would like to define a namspace like this: > java/serverB-jms I would then like to be able to lookup for example > java:/serverB-jms/topic/testTopic or > java:/serverB-jms/TopicConnectionFactory. But I do not want to have to > bind al those name into the A JNDI, only the java/serverB-jms. This name > should then somehow be bound to a factory that would lookup and returns > the objects from the remote machine. > > Any thoughts any one? Would "federation" help there? -- __ Alexander Kogan PTC www.ptc.com [EMAIL PROTECTED]140 Kendrick St. Needham MA 02494 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
On 13 Apr, Jason Dillon wrote: > Another JMS question, how should I go about creating a session such that its > transactional context is consistent with the executing bean? I assume that > the resource manager fluff is there to deal with some of this? Should I > assume that the session is transacted with an AUTO_ACK mode? I am surprised > the bean does not get a session as a resource instead of a connection > factory. > > --jason Hi, there is currently no support for using JMS as a true resource in JBoss (except for Message Driven Beans), where the JMS session will be enlisted with the ongoing transactions. I am working on a J2EE Connector resource adapter for JMS for JBoss. When this is finished JBoss will have access to transacted JMS sessions. I still have som stuff to figure out though, among them how to bind JMS objects without using the url-hack. What I really would like to have is a way to be able to bind in JMS objects that also resides on other servers and reference them in the deployment descriptors. Any JNDI experts out there? Is it possible to contsruct some sort of factory that rules a complete subcontext. An example: Suppose I want to send JMS messages from server A to B. At A I would like to define a namspace like this: java/serverB-jms I would then like to be able to lookup for example java:/serverB-jms/topic/testTopic or java:/serverB-jms/TopicConnectionFactory. But I do not want to have to bind al those name into the A JNDI, only the java/serverB-jms. This name should then somehow be bound to a factory that would lookup and returns the objects from the remote machine. Any thoughts any one? //Peter > > > On Thu, 12 Apr 2001, Scott M Stark wrote: > >> A ConnectionFactory is a resource factory and the spec talks about JMS >> being located by convention under the java:comp/env/jms context. To >> access a QueueConnectionFactory independent of which app server you >> deploy in you would define an ejb-jar resource-ref as: >> >> ejb-jar.xml: >> >> ENC Tests >> >> >> A session bean on looks up stuff in the ENC >> ... >> >> >> Default QueueFactory >> jms/QueFactory >> javax.jms.QueueConnectionFactory >> Container >> >> >> >> >> >> jboss.xml: >> >> >> >> ENCBean >> >> QueFactory >> jms/QueFactory >> >> >> >> >> >> >> QueFactory >> QueueConnectionFactory >> >> >> >> >> Your bean is indepdendent of the app server but its deployment unit is not. >> >> - Original Message - >> From: "Jason Dillon" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Thursday, April 12, 2001 5:25 PM >> Subject: Re: [JBoss-user] Using JMS resources (or other resources) >> >> >> > That is more or less what I am going to be doing, but I wanted to know if >> > there was a standard way to provide the queue information to a bean. My >> > guess is that it should be as a resource, but I am not 100% sure. >> > >> > --jason >> > >> >> >> >> ___ >> JBoss-user mailing list >> [EMAIL PROTECTED] >> http://lists.sourceforge.net/lists/listinfo/jboss-user >> > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
On 13 Apr, Jason Dillon wrote: > Hello, I am getting an odd naming exception when I try to lookup the > connection factory: Hi, this will not work in JBoss due to a feature in ApplicationMetaData. A JNDI pointed out in a res-jndi-name must be part of the java: namespace. If java: is not found in the JNDI name it will be added by ApplicationMetaData (if (jndi != null && !jndi.startsWith("java:/")) jndi = "java:/"+jndi; ) Meaning that you will try to lookup "java:QueueConnectionFactory", but since non of the JMS JNDI objects are bound to java: namespace, they will not be found. There is a workaround/hack that uses the way the Container currently is implemented: use instead of . Here is a working jboss.xml for the Publisher bean from the SUN JMS tutorial: false topicfactoryref TopicConnectionFactory topicref topic/TestTopic Publisher publisher Standard Stateless SessionBean jms/MyTopicConnectionFactory topicfactoryref jms/TopicName topicref This might not allways work, since it is based on a sideffect of the current implementation of the Container class. The truth is that JBoss currently really has no support for JMS as a resource (see repply on your other mail). //Peter > > > javax.naming.NameNotFoundException: QueueConnectionFactory not bound > at org.jnp.server.NamingServer.getBinding(NamingServer.java:474) > at org.jnp.server.NamingServer.getBinding(NamingServer.java:482) > at org.jnp.server.NamingServer.getObject(NamingServer.java:488) > at org.jnp.server.NamingServer.lookup(NamingServer.java:283) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:295) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:279) > at javax.naming.InitialContext.lookup(InitialContext.java:350) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:367) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:279) > > > > > Here are the bits that I added to the ejb-jar and jboss xml files, as well > as a bit of the JNDIView output from the server this is running in: > > > > > Default QueueConnectionFactory > jms/QueueConnectionFactory > javax.jms.QueueConnectionFactory > Container > > > > > > > > jms/QueueConnectionFactory > QueueConnectionFactory > > > > > > > QueueConnectionFactory > QueueConnectionFactory > > > > > > > +- QueueConnectionFactory (class: org.jbossmq.SpyQueueConnectionFactory) > > > -- > > It looks like the namespace of the bean is ok: > > > +- env (class: org.jnp.interfaces.NamingContext) > | +- jms (class: org.jnp.interfaces.NamingContext) > | | +- QueueConnectionFactory (class: javax.naming.LinkRef) > > > -- > > To lookup the object I am first getting the env context: > > context = new InitialContext().lookup("java:comp/env/"); > ... > factory = (...) context.lookup("jms/QueueConnectionFactory"); > > -- > > I am not really sure where the naming problem comes up. It looks like it > might be having touble with the LinkRef, but that is only a guess since the > name I am looking for has a 'jms/' prefix on it at the bean level, but the > resource does not. > > I will play around with it some more, but if you (or anyone else) has any > ideas please let me know. > > Thanks, > > --jason > > On Thu, 12 Apr 2001, Scott M Stark wrote: > >> A ConnectionFactory is a resource factory and the spec talks about JMS >> being located by convention under the java:comp/env/jms context. To >> access a QueueConnectionFactory independent of which app server you >> deploy in you would define an ejb-jar resource-ref as: >> >> ejb-jar.xml: >> >> ENC Tests >> >> >> A session bean on looks up stuff in the ENC >> ... >> >> >> Default QueueFactory >> jms/QueFactory >> javax.jms.QueueConnectionFactory >> Container >> >> >> >> >> >> jboss.xml: >> >> >> >> ENCBean >> >> QueFactory >> jms/QueFactory >>
Re: [JBoss-user] Using JMS resources (or other resources)
Another JMS question, how should I go about creating a session such that its transactional context is consistent with the executing bean? I assume that the resource manager fluff is there to deal with some of this? Should I assume that the session is transacted with an AUTO_ACK mode? I am surprised the bean does not get a session as a resource instead of a connection factory. --jason On Thu, 12 Apr 2001, Scott M Stark wrote: > A ConnectionFactory is a resource factory and the spec talks about JMS > being located by convention under the java:comp/env/jms context. To > access a QueueConnectionFactory independent of which app server you > deploy in you would define an ejb-jar resource-ref as: > > ejb-jar.xml: > > ENC Tests > > > A session bean on looks up stuff in the ENC > ... > > > Default QueueFactory > jms/QueFactory > javax.jms.QueueConnectionFactory > Container > > > > > > jboss.xml: > > > > ENCBean > > QueFactory > jms/QueFactory > > > > > > > QueFactory > QueueConnectionFactory > > > > > Your bean is indepdendent of the app server but its deployment unit is not. > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, April 12, 2001 5:25 PM > Subject: Re: [JBoss-user] Using JMS resources (or other resources) > > > > That is more or less what I am going to be doing, but I wanted to know if > > there was a standard way to provide the queue information to a bean. My > > guess is that it should be as a resource, but I am not 100% sure. > > > > --jason > > > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
Hello, I am getting an odd naming exception when I try to lookup the connection factory: javax.naming.NameNotFoundException: QueueConnectionFactory not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:474) at org.jnp.server.NamingServer.getBinding(NamingServer.java:482) at org.jnp.server.NamingServer.getObject(NamingServer.java:488) at org.jnp.server.NamingServer.lookup(NamingServer.java:283) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:295) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:279) at javax.naming.InitialContext.lookup(InitialContext.java:350) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:367) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:279) Here are the bits that I added to the ejb-jar and jboss xml files, as well as a bit of the JNDIView output from the server this is running in: Default QueueConnectionFactory jms/QueueConnectionFactory javax.jms.QueueConnectionFactory Container jms/QueueConnectionFactory QueueConnectionFactory QueueConnectionFactory QueueConnectionFactory +- QueueConnectionFactory (class: org.jbossmq.SpyQueueConnectionFactory) -- It looks like the namespace of the bean is ok: +- env (class: org.jnp.interfaces.NamingContext) | +- jms (class: org.jnp.interfaces.NamingContext) | | +- QueueConnectionFactory (class: javax.naming.LinkRef) -- To lookup the object I am first getting the env context: context = new InitialContext().lookup("java:comp/env/"); ... factory = (...) context.lookup("jms/QueueConnectionFactory"); -- I am not really sure where the naming problem comes up. It looks like it might be having touble with the LinkRef, but that is only a guess since the name I am looking for has a 'jms/' prefix on it at the bean level, but the resource does not. I will play around with it some more, but if you (or anyone else) has any ideas please let me know. Thanks, --jason On Thu, 12 Apr 2001, Scott M Stark wrote: > A ConnectionFactory is a resource factory and the spec talks about JMS > being located by convention under the java:comp/env/jms context. To > access a QueueConnectionFactory independent of which app server you > deploy in you would define an ejb-jar resource-ref as: > > ejb-jar.xml: > > ENC Tests > > > A session bean on looks up stuff in the ENC > ... > > > Default QueueFactory > jms/QueFactory > javax.jms.QueueConnectionFactory > Container > > > > > > jboss.xml: > > > > ENCBean > > QueFactory > jms/QueFactory > > > > > > > QueFactory > QueueConnectionFactory > > > > > Your bean is indepdendent of the app server but its deployment unit is not. > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, April 12, 2001 5:25 PM > Subject: Re: [JBoss-user] Using JMS resources (or other resources) > > > > That is more or less what I am going to be doing, but I wanted to know if > > there was a standard way to provide the queue information to a bean. My > > guess is that it should be as a resource, but I am not 100% sure. > > > > --jason > > > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
Theoretically yes, but resource-env-ref is an EJB2.0 spec addition that has not been implemented yet. In the interim you would simply have to use the global JNDI namespace: new InitialContext().lookup("queue/StockQueue"); which is actually not as bad as it seems as Queues are administered objects that have to be setup via a JMS provider mechanism and so you should always be able to bind to the same location. I'll look at adding support for the resource-env-ref when I fix an existing namespace issue. - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 12, 2001 8:01 PM Subject: Re: [JBoss-user] Using JMS resources (or other resources) > Thanks... so would I use something like this: > > > jms/StockQueue > javax.jms.Queue > > > to get at the queue/topic information to use with the connection factory > as configured below? > > --jason > > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
Thanks... so would I use something like this: jms/StockQueue javax.jms.Queue to get at the queue/topic information to use with the connection factory as configured below? --jason On Thu, 12 Apr 2001, Scott M Stark wrote: > A ConnectionFactory is a resource factory and the spec talks about JMS > being located by convention under the java:comp/env/jms context. To > access a QueueConnectionFactory independent of which app server you > deploy in you would define an ejb-jar resource-ref as: > > ejb-jar.xml: > > ENC Tests > > > A session bean on looks up stuff in the ENC > ... > > > Default QueueFactory > jms/QueFactory > javax.jms.QueueConnectionFactory > Container > > > > > > jboss.xml: > > > > ENCBean > > QueFactory > jms/QueFactory > > > > > > > QueFactory > QueueConnectionFactory > > > > > Your bean is indepdendent of the app server but its deployment unit is not. > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, April 12, 2001 5:25 PM > Subject: Re: [JBoss-user] Using JMS resources (or other resources) > > > > That is more or less what I am going to be doing, but I wanted to know if > > there was a standard way to provide the queue information to a bean. My > > guess is that it should be as a resource, but I am not 100% sure. > > > > --jason > > > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
A ConnectionFactory is a resource factory and the spec talks about JMS being located by convention under the java:comp/env/jms context. To access a QueueConnectionFactory independent of which app server you deploy in you would define an ejb-jar resource-ref as: ejb-jar.xml: ENC Tests A session bean on looks up stuff in the ENC ... Default QueueFactory jms/QueFactory javax.jms.QueueConnectionFactory Container jboss.xml: ENCBean QueFactory jms/QueFactory QueFactory QueueConnectionFactory Your bean is indepdendent of the app server but its deployment unit is not. - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 12, 2001 5:25 PM Subject: Re: [JBoss-user] Using JMS resources (or other resources) > That is more or less what I am going to be doing, but I wanted to know if > there was a standard way to provide the queue information to a bean. My > guess is that it should be as a resource, but I am not 100% sure. > > --jason > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
That is more or less what I am going to be doing, but I wanted to know if there was a standard way to provide the queue information to a bean. My guess is that it should be as a resource, but I am not 100% sure. --jason On Thu, 12 Apr 2001, Alexander Kogan wrote: > Jason, > > Why not to think about an EJB as a plain client > for JMS? There is nothing special here. > > I have a helper class (sort of ServiceLocator pattern) > which I'm using either on clients (servlets) and server (EJBs): > > > / > * creates query session > / > private void getQueueSession() throws BmxServerException > { > if ( qsession != null ) > return; > > // !!!provider specific!!!, must be got from properties > QueueConnectionFactory queueFactory = null; > try > { > queueFactory = > > (QueueConnectionFactory)context.lookup("QueueConnectionFactory"); > } > catch (NamingException ne) > { > throw new BmxServerException(ne, BmxError.InternalError); > } > > try > { > QueueConnection queueConnection = > queueFactory.createQueueConnection(); > qsession = queueConnection.createQueueSession(false, > Session.AUTO_ACKNOWLEDGE); > } > catch (JMSException jmse) > { > throw new BmxServerException(jmse, BmxError.InternalError); > } > } > > / > * sends message into queue > / > public void sendXmlMessage(String queueName, XmlDescriptor xmessage) > throws BmxServerException > { > getQueueSession(); > > try > { > Queue queue = (Queue)context.lookup("queue/" + > queueName); > QueueSender sender = qsession.createSender(queue); > > TextMessage tmess = qsession.createTextMessage(); > tmess.setText(xmessage.toXmlString()); > sender.send(tmess); > } > catch (Exception e) > { > throw new BmxServerException(e, BmxError.InternalError); > } > } > > > > > Jason Dillon wrote: > > > > Can someone point me a documentation or examples on the standard way to > > allow a EJB to access an external resource. > > > > I looked at the EJB spec and it was less than helpful. I saw one example > > of letting a bean access a JMS queue, but what about the ConnectionFactory > > and such? Do I need to have a seperate entry for that too? > > > > Is anyone using MDB who can give me some advise on how to go about letting > > an EJB access a JMS queue or topic? > > > > Thanks, > > > > --jason > > > > ___ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-user > > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using JMS resources (or other resources)
Jason, Why not to think about an EJB as a plain client for JMS? There is nothing special here. I have a helper class (sort of ServiceLocator pattern) which I'm using either on clients (servlets) and server (EJBs): / * creates query session / private void getQueueSession() throws BmxServerException { if ( qsession != null ) return; // !!!provider specific!!!, must be got from properties QueueConnectionFactory queueFactory = null; try { queueFactory = (QueueConnectionFactory)context.lookup("QueueConnectionFactory"); } catch (NamingException ne) { throw new BmxServerException(ne, BmxError.InternalError); } try { QueueConnection queueConnection = queueFactory.createQueueConnection(); qsession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); } catch (JMSException jmse) { throw new BmxServerException(jmse, BmxError.InternalError); } } / * sends message into queue / public void sendXmlMessage(String queueName, XmlDescriptor xmessage) throws BmxServerException { getQueueSession(); try { Queue queue = (Queue)context.lookup("queue/" + queueName); QueueSender sender = qsession.createSender(queue); TextMessage tmess = qsession.createTextMessage(); tmess.setText(xmessage.toXmlString()); sender.send(tmess); } catch (Exception e) { throw new BmxServerException(e, BmxError.InternalError); } } Jason Dillon wrote: > > Can someone point me a documentation or examples on the standard way to > allow a EJB to access an external resource. > > I looked at the EJB spec and it was less than helpful. I saw one example > of letting a bean access a JMS queue, but what about the ConnectionFactory > and such? Do I need to have a seperate entry for that too? > > Is anyone using MDB who can give me some advise on how to go about letting > an EJB access a JMS queue or topic? > > Thanks, > > --jason > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user -- __ Alexander Kogan PTC www.ptc.com [EMAIL PROTECTED]140 Kendrick St. Needham MA 02494 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user