February 2008 - jboss-dev-forums - Jboss List Archives

[Deployers on JBoss (Deployers/JBoss)] - Deployers ordering and write access to the private naming co

by deruelle_jean

Hi all, Sorry in advance for the long post, As part of the Mobicents Jboss project, we are currently building a sip servlets 1.1 (JSR 289) implementation that run both on top of Tomcat and Jboss. (available at https://sip-servlets.dev.java.net/). The spec mandates in its section 18.2.7 Annotation for SipFactory Injection that for converged containers, a SipFactory would appear as java:/comp/env/sip//SipFactory in the JNDI mapping or injected as an @Resource annotation. This annotation can be used in any SIP Servlet or a JEE application component deployed on the converged container in the same EAR archive file. The SipFactory is an interface for a variety of SIP Servlet API abstractions, which could allow an EJB to initiate a sip call by example. In an EAR, we could have many Sip Servlets Applications, so we would need to first deploy the web applications (contexts) before EJB, webservices, mdb, ... and then when starting those other JEE components be able to access their private naming context (java:/comp/env/) to inject the SipFactory of each app bundled within the EAR. Could you provide some informations/tips/tricks/guildelines on how to extend/modify the current deployers in order to achieve that ? I can provide more information if this is not clear enough. Thanks in advance Best regards Jean Deruelle View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132512#4132512 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132512

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Transaction rollback in action pipeline

by Kevin.Conner＠jboss.com

Hiya Daniel. You can certainly go ahead and commit on JBESB-1563. Please make sure that these activation properties cannot overwrite the ones created in the configuration mapper though, our attributes need to take precedence. Kev View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132508#4132508 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132508

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Transaction rollback in action pipeline

by beve

That worked like a charm! Thanks So the only thing I need now is a green light to commit work for http://jira.jboss.com/jira/browse/JBESB-1563 ;) Would that be ok? Thanks, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132505#4132505 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132505

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New package structure

by timfox

"jmesnil" wrote : | I'm thinking mainly about the Message interface (and also the Version interface, anything else?). | I find weird in client code to instantiate an object from server.impl package. | We should probably create a core/message package to avoid this problem. Version is already in core/version. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132502#4132502 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132502

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Eclipse template wizard plugin directory structure

by jeffdelong

Thanks for going the structured directories and including the rules and jdpl folders. I am currently conducting a SOA workshop for a client, and it is a bit clumsy creating a rule project or a jbpm project in Eclipse with one directory structure and then a second project that mimics the quickstart folder structure. Drools plugin has a nice feature that you can add the required jars through a menu option "Convert to Drools Project". When the user creates a jBPM project it uses a jBPM Runtime that the user has previously configured in preferences. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132500#4132500 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132500

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Eclipse template wizard plugin directory structure

by Kevin.Conner＠jboss.com

Hiya Daniel. The first version just recreated the helloworld example, IIRC, and may have been updated when the base-build.xml was created. Everything was a C&P prior to the base-build.xml, it was a maintenance nightmare. Having the new plugin independent from the quickstarts would be a good move as the dependency mechanism should not really reside within the quickstarts. I would like the plugin and quickstarts to share the mechanism though. Kev View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132499#4132499 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132499

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New package structure

by jmesnil

"timfox" wrote : I have just committed a refactoring to our new package structure. | | Here is how it goes: | | org.jboss.messaging.core and sub packages. | | Contain the messaging core - this is all the stuff needed to make a fully functioning transactional, reliable messaging system. | | ... | | server - the core server interfaces and implementation | | ... | | client - this contains the core client interfaces and implementation | I'd put the stuff common to the client & server code directly under org.jboss.messaging.core. I'm thinking mainly about the Message interface (and also the Version interface, anything else?). I find weird in client code to instantiate an object from server.impl package. As an aside, we should also extract a subset of the Message interface common to the client and the server. In this interface, all the methods related to MessageReference do not make sense in the context of the client. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132496#4132496 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132496

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Transaction rollback in action pipeline

by beve

Ah, thanks for the hint! So something like this in a customer action: | TransactionStrategy strategy = TransactionStrategy.getTransactionStrategy(true); | strategy.rollbackOnly(); | /Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132495#4132495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132495

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Eclipse template wizard plugin directory structure

by beve

Hey Kevin, yeah, I agree with you that the quickstarts should look the same as the projects created by the template plugin. I'll try modifying one quickstart locally to see how much is involved in this. One thing that I'm probably missing is how the current template plugin is/was supposed to be used. Was it only intended to help generate new quickstarts? I have to admit that I have never used it. When I create a new quickstart I copy one that is similar to what I need and make updates :( My thought was that the "new" template plugin should not have any dependencies to the quickstarts structure at all. And that jar dependencies should be used from the chosen esb server during project configuration. /Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132493#4132493 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132493

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New package structure

by ataylor

anonymous wrote : Being dependent on the implementation in one place (at construction) is better than being dependent on the implementation in N places (each place the class is used), so it's an improvement. I agree, but that is what IOC is all about, it class doesnt have to worry about how a pluggable component is constructed. anonymous wrote : 1) Makes testing a whole lot easier since can easily create mock / fake implementions i agree anonymous wrote : 2) Makes code easier to read / understand again i agree anonymous wrote : 3) If user wants to create their own implementation of the interface they can. If it's a concrete class they'd have to extend that class. That may not be possible or desirable. defo. I'm not against using interfaces where we can, just making a point. We have to make sure that we dont just introduce interfaces that are dragged out of the implementation, the abstraction still needs to make sense. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132492#4132492 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132492

17 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2008