Currently JBoss messaging has some dependencies to JBoss AS, specially jbossxs, commons, j2ee and jboss.jar Looking at http://repository.jboss.com/jbossas/core-libs/4.2.0.GA/, I only see these libraries: jboss-common.jar jboss-j2ee.jar jboss-jmx.jar jboss-system.jar jboss-xml-binding.jar I don't see jboss.jar, jbosssx.jar and jnp-client.jar. I'm still not sure If I need jnp-client but jboss.jar and jbosssx.jar I do need to compile security stuff and transaction integrations. Anyone sees any problem if I add these libraries into that repository... or anyone know if there is another place I should be looking at on the repository? Anyway, I don't think anyone is using that as the component-info.xml was completely broken, making references to inexistent components. Clebert _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Yes, this should be in an spi jar, and should not be referencing the Service/ServiceMBean interfaces. Clebert Suconic wrote: > It has to be a better way to do this... > > The only reason JBossMessaging is dependent on jboss.jar is because > org.jboss.jms.jndi.JMSProviderAdapter is only available there. (Did a > search on all the other jars on JBoss 4.2) > > Shouldn't these Adapters be available in some sort of > jboss-integration.jar or jboss-adapters.jar? > > I would have to add jboss.jar to core-libs just because of this class. > > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Integration code does not need to be shared. Integration should be written in the JBossAS codebase (integration project) not in JBoss Messaging (implementation project). http://jira.jboss.com/jira/browse/JBAS-1796 I closed JBAS-4499 since even if we were going to make this a "public spi" we would want to change it anyway to not necessarily be dependent on jndi for JMS integration. On Fri, 2007-06-22 at 16:15 -0500, Clebert Suconic wrote: > http://jira.jboss.com/jira/browse/JBAS-4499 > > Scott M Stark wrote: > >> Yes, this should be in an spi jar, and should not be referencing the >> Service/ServiceMBean interfaces. >> >> Clebert Suconic wrote: >> >>> It has to be a better way to do this... >>> >>> The only reason JBossMessaging is dependent on jboss.jar is because >>> org.jboss.jms.jndi.JMSProviderAdapter is only available there. (Did a >>> search on all the other jars on JBoss 4.2) >>> >>> Shouldn't these Adapters be available in some sort of >>> jboss-integration.jar or jboss-adapters.jar? >>> >>> I would have to add jboss.jar to core-libs just because of this class. >>> >>> >>> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development >> > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development >

The JBoss Messaging Bridge MBean has dependencies on JMSProviderLoader since it uses these to connect to its source and target destinations. Are you suggesting we move the Bridge MBean into the AS project?

Yes, this is the approach I was referring to in my previous post when I said "minor changes", no need to write an essay ;)

Adrian wrote: > On Wed, 2007-06-27 at 14:55 +0100, Tim Fox wrote: >> Yes, this is the approach I was referring to in my previous post >> when I said "minor changes", no need to write an essay ;) > > If I just said "use IOC" or "create an abstraction" > most people wouldn't understand > what I was talking about and probably ignore it. (not that they won't > anyway :-) > > There's still very little understanding of the issue raised > by JBAS-1796. > > It wasn't until I recently "wrote an essay" on AOP integration > that Kabir finally groked it. :-) I'd say we need more of Adrian's essays :-)

_______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

On Wed, 2007-06-27 at 14:55 +0100, Tim Fox wrote: > Yes, this is the approach I was referring to in my previous post when I > said "minor changes", no need to write an essay ;) If I just said "use IOC" or "create an abstraction" most people wouldn't understand what I was talking about and probably ignore it. (not that they won't anyway :-) There's still very little understanding of the issue raised by JBAS-1796.

On Wed, 2007-06-27 at 14:01 +0100, Tim Fox wrote: > The JBoss Messaging Bridge MBean has dependencies on JMSProviderLoader > since it uses these to connect to its source and target destinations. > > Are you suggesting we move the Bridge MBean into the AS project? No, I'm suggesting you think about providing a clean api which can be used by the AS to integrate with its configuration mechanisms. Trying to do integration in your project just leads to JBAS-1796 style problems and bad api! IOC 101 Why doesn't the bridge just take connection factories and destinations as injections (javabean setters)? That is a trivial "no dependency required" configuration api. public SimpleBridge { setSourceConnectionFactory(XAConnectionFactory cf) {}; setTargetConnectionFactory(XAConnectionFactory cf) {}; setSourceDestination(Destination destination) {}; setTargetDestination(Destination destination) {}; ... } ANY FORM OF INTEGRATION IS NOW EASY For standalone ease of use, you could subclass the simple bridge with a version that does something like (psuedo code): public JNDIBridge extends SimpleBridge { public void setTargetDestinationJndiName(String targetJNDI) {} public void setJNDITargetProperties(Properties targetProperties) { } // Create lifecycle that does base setters from jndi configuration public void create() throws Exception { if (targetJNDI == null) throw new IllegalStateException("Target jndi name not set!"); InitialContext context; if (targetProperties == null) context = new InitialContext(); else context = new InitialContext(targetProperties); try { Destination d = (Destination) context.lookup(targetJNDI); setTargetDestination(d); etc.... } finally { context.close(); } } } Which is basically what the JMSProvider really does anyway! JBOSS INTEGRATION IS ALSO TRIVIAL In the appserver we could have a JNDIProvider based version to integrate with the current way of configuring jms servers in one place. public JNDIProviderBridge extends SimpleBridge { public void setSourceJNDIProviderName(String jndiName) {} public void setTargetJNDIProviderName(String jndiName) {} public void setSourceDestination(String jndiName) {} public void setTargetDestination(String jndiName) {} etc.... }