From: <pr...@mi...> - 2001-04-17 18:13:32
|
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 > JBo...@li... > 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: pr...@ti... WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ------------------------------------------------------------ |