[Design of JBoss ESB] - Re: JSR-170 message store
by mark.little＠jboss.com
"derek.adams" wrote : I think the current implementation works well in the sense that there is not a specific interface for the properties associated with a message (i.e - no getMessageId() or getMessageCreateDate() on the Message interface itself). I added the org.jboss.soa.esb.message.properties.MessagePropertyFacade class as a wrapper for messages so that there would be consistent property naming and typing without restricting the Message interface. Does that sound like a good way to handle it?
Yes and no ;-) Maybe I just need some clarification.
When I look at the MessageStore interface, the way of retrieving messages is either by URI:
public Message getMessage (URI uid) throws MessageStoreException;
or by the fact that the messages haven't been delivered:
public Map<URI, Message> getUndeliveredMessages() throws MessageStoreException;
One of the intentions of the message store was that it could be used for audit trail purposes ("give me all mesage exchanges between A and B during 9am and 12pm on 2nd of August") and debugging (replay the events), etc. A DLQ is obviously just one way in which we can use the messages stored. The original interface for the MessageStore fell short of our intentions, as you've seen. What we've got now is a lot more useful. However, it would be nice to have something that is more flexible. We could do this in a number of ways. For example, did you see my earlier comment about using rules?
public Map<URI, Message> getMessages(RuleBase rules) throws MessageStoreException;
Would be interested in your thoughts on generalising the interface.
Also, could you add the copyright statement to the head of the files you added? Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037753#4037753
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037753
18 years, 11 months
[Design of JCA on JBoss] - JMS provider issues
by weston.price＠jboss.com
We are seeing a case with a JMS provider (that shall remain nameless) where prior to the ServerSessionPool being able to be recycled as the result of a provider failure, a ServerSession is being removed from the pool. As a result, the pool can never be cleared as there are outstanding Sessions and as such the cleanup code waits indefinitely for these resources to be returned. At this point, no forward progress can be made and the pool itself can never be recycled.
While this particular issue cropped up in the JMSContainerInvoker, similar logic exists in the JMS/JCA adapter. While I am loathe to provide a configuration option to wait for an interval and then just 'bail out', I am not sure how we can move forward on this as the JMS provider is similarly unwilling to make modifications with the underlying ConnectionConsumer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037739#4037739
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037739
18 years, 11 months
[Design of JBoss Remoting, Unified Invokers] - JBossCX -- JBossJCA and Remoting
by weston.price＠jboss.com
It has been proposed to combine the JBossJCA and JBossRemoting projects into a single project. This project with the tentative name JBossCX would be a new home for
| * JBossJCA
| * JBossRemoting
| * Any shared connectivity modules/functionality from both projects. The high level goals of the project are
|
|
| 1) Provide a single point of departure for any connectivity related functionality in JBoss5 regardless of where this functionality may reside in the 'stack' in terms of abstraction
|
| 2)Organize the project as a first class citizen on par with EJB3, Microcontainer etc.
|
| 3) Take advantage of the new JBoss build system work utilizing Maven as the primary build system.
|
| 4) Provide connectivity services to a variety of projects namely JBM, EJB3, ESB etc.
|
| 5) Provide the foundation for a unified connectivity solution
|
| as integration with thirdparty systems becomes relevant.
|
| Benefits:
|
| Currently JBossJCA is due for a rewrite to use the Microcontainer as the underlying framework versus JMX. While pieces of this have been completed (deployers, programmatic *-ds.xml deployment etc) the new implementation will be aided by being isolated from JBoss as a whole making the migration process easier to manage. Discussion around these varying aspects can be found here:
|
| http://www.jboss.com/index.html?module=bb&op=viewforum&f=165
|
| Similarly, JBossRemoting is currently beginning work on Remoting3 which will offer an NIO based implementation replacing Remoting2. More on this can be found and discussed here:
|
| http://www.jboss.com/index.html?module=bb&op=viewtopic&t=105497
|
| This new proposed structure should not be confused with one module replacing the other. Nor should this be taken as a sign that one project will be 'folded' into the other. This is simply an effort to combine two related projects having connectivity as a primary aim into a larger framework; the primary impetus being better able to service clients as we move towards a more modular and, hopefully better, structure with JBoss5.
|
|
| Thoughts, comments, suggestions?
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037730#4037730
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037730
18 years, 11 months
[Design of JBoss jBPM] - Re: Commands: Maybe result should be part of the Command-Obj
by camunda
I have one new comment on that:
Maybe it would be also a good option to always return a Map (or return the Command and have a Map always in there) to make the following approach possible:
I have written a EJB3-CommandServiceBean which has some additional informations about the processes and some Entities in the process variables. So it can load the required Entity-Objects (via JDO in that project). That could be handled in the CommandServiceBean, no problem, no overhead with multiple remote calls (jepp, we are in a Swing Client).
But how to return these additonal values?
change the result of the execute-method is not a good idea, because then, we have to now in the code which implementation of the CommandService we use, bad idea.
add the values to the process variables? sounds good at first, but has the problem, if I add them to the processInstance (for example) before returning, they are treated as process variables and persistet (which I do not want).
So if we have a Map as a return value, every CommandService-Implementation could add, what it wants to add. And the client can look for entries in the Map and use them, if he finds something. A concept like the "hints" for the PersistenceProvider in EJB 3...
What do you think?
I know, the most of the problems are not problems in the Webapp-World, but I think it is worse to support Remote-Apps too...
Thanks for any hints, ideas and comments! Unfortunatly, I am a little bit under time pressure for that issue :-(
Regards
Bernd
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037718#4037718
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037718
18 years, 11 months
[Design of JBoss ESB] - Re: Finding the EPR for a provider from a notifier
by derek.adams
Sorry about the confusion -- I guess the easiest way to explain it is through an example.
Case 1: I want to add a new Telnet (or whatever other protocol) gateway to the system. Rather than adding it to the core JBossESB source code, I would like to be able to deploy the new implementation such that all of the impl code is contained in a separate jar. The JBossESB deployer would detect when the jar is added to the deploy directory and would add the gateway impl to the list it supports. Some of the meta-information in the jar would indicate how the new gateway would be referenced from the jboss-esb.xml. It is my understanding that EPRs are lightweight facades that provide info to the underlying gateway impl, so I was suggesting that the available EPR classes for an impl would be listed in the jar metadata. So, I would create my impl, jar up the libs/classes/metadata, drop telnetImpl.jar into the deploy directory, and all deployments could reference the new technology without changes to the core libs.
Case 2: I want to replace the FTP gateway/EPRs/etc included with JBossESB with my own impl. If the packaged implementations for file, FTP, JMS, etc are just jars in the jbossesb.sar folder, I could build my own and replace the appropriate jar (i.e ftpImpl.jar) with my new code... preferably without bouncing the server.
Does that make more sense?
Thanks,
Derek
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037715#4037715
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037715
18 years, 11 months