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.
>>
> <snip>
>> Then we could write an mbean entry like this:
>>
>> <mbean code="org.jboss.naming.ExternalContext"
>name=":service=ExternalContext,jndiName=jms">
>> <attribute name="JndiName">java:jms/topic</attribute>
>> <attribute name="SubContext">topic</attribute>
>> <attribute name="InitialContext">javax.naming.InitialContext</attribute>
>> <attribute name="Properties">jndi.properties</attribute>
>> </mbean>
>>
> 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:
> <mbean code="org.jboss.naming.NamingAlias"
>name=":service=NamingAlias,fromName=java:jms/topic">
> <attribute name="FromName">java:jms/topic</attribute>
> <attribute name="ToName">topic</attribute>
> </mbean>
>
>> And there by have bound all current and future topics to the JNDI
>> java:jms/topic
>>
>> Then the res-jndi-name would work:
>>
>> <res-jndi-name>java:jms/topic/testTopic</res-jndi-name>
>>
>>
>> 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 Architect WWW: 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
