Re: [JBoss-user] Using JMS resources (or other resources)

2001-04-18 Thread Jason Dillon

>
> 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)

2001-04-18 Thread Jason Dillon

> 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)

2001-04-18 Thread Jason Dillon

> 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)

2001-04-17 Thread pra

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)

2001-04-17 Thread Scott M Stark


- 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)

2001-04-17 Thread pra

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)

2001-04-17 Thread Scott M Stark


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)

2001-04-17 Thread Peter Antman

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)

2001-04-16 Thread pra

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)

2001-04-16 Thread Scott M Stark

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)

2001-04-16 Thread Alexander Kogan

[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)

2001-04-16 Thread pra

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)

2001-04-16 Thread pra

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)

2001-04-13 Thread Jason Dillon

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)

2001-04-13 Thread Jason Dillon

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)

2001-04-12 Thread Scott M Stark

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)

2001-04-12 Thread Jason Dillon

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)

2001-04-12 Thread Scott M Stark

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)

2001-04-12 Thread Jason Dillon

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)

2001-04-12 Thread Alexander Kogan

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