April 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: swimlaneInstance overwritten when creating startTaskInst

by yoyoyoyo

Hi, can anyone share some idea on this issue? Maybe I did not explain the problem well, so here again: if jbpm set the actorId on a taskInstance with update on the related swimlaneInstance, and this swimlaneInstance was initialized with pooledActors, what will be the consequences? how does jbpm deal with a swimlaneInstance with both actorId and pooledActors set? tks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040163#4040163 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040163

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: aop-mc-int tests with maven

by kabir.khan＠jboss.com

"pgier" wrote : | Which tests are supposed to go in each group 1, 2, and 3? It had been a while, so I was wrong. All tests are run with weaving enabled Some tests are run with no weaving I will update the pom.xml and see how that goes View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040160#4040160 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040160

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by timfox

"weston.price(a)jboss.com" wrote : | No, not illegal but it certainly makes deploying non XA JMS based resources with JBM all but impossible while using the JMS/JCA adapter. While this is not necessarily a bad thing, it simply says that when using JCA/JMS in conjunction with JBM you currently have no choice but to use XA which in most scenarios is exactly what you want. | But it is not what we want all cases anonymous wrote : | The JCA/JMS adapter is designed for generic JMS integration with any JMS provider, not just those implementing the optional XA API. | If it's designed for generic JMS integration with ANY JMS provider then it fails on its own requirement with JBM anonymous wrote : | | This is *by design*. | | Sounds like the design is broken. You are forcing us to always be always used as XA, because you use instanceof to tell the XAConnectionFactory and ConnectionFactory apart. I.e. the JCA implementation currently implicitly assumes that the a particular JMS provider won't use the same class to implement XA and non XA interfaces. As you yourself mentioned earlier in this thread, another solution which should work with all (read JBM) JMS providers is to add extra field "isXA" in the JMSProviderAdapter config. Or perhaps something like this - with explicit extra fields: | <mbean code="org.jboss.jms.jndi.JMSProviderLoader" | name="jboss.messaging:service=JMSProviderLoader,name=JMSProvider"> | <attribute name="ProviderName">DefaultJMSProvider</attribute> | <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute> | <attribute name="NonXAFactoryRef">java:/NonXAConnectionFactory</attribute> | <attribute name="NonXAQueueFactoryRef">java:/NonXAConnectionFactory</attribute> | <attribute name="NonXATopicFactoryRef">java:/NonXAConnectionFactory</attribute> | <attribute name="XAFactoryRef">java:/XAConnectionFactory</attribute> | <attribute name="XAQueueFactoryRef">java:/XAConnectionFactory</attribute> | <attribute name="XATopicFactoryRef">java:/XAConnectionFactory</attribute> | </mbean> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040108#4040108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040108

18 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: unit.getAttachment(Class type) returning null

by scott.stark＠jboss.org

Right, the key for the getAttachment(class) call is the class name. If a different name was used, you need to use the getAttachment(String name, Class expectedType) method. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040083#4040083 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040083

18 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: unit.getAttachment(Class type) returning null

by scott.stark＠jboss.org

The getAttachment(class) call walks through the various type of attachments. What deployment is not showing the metadata that should? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040081#4040081 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040081

18 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: unit.getAttachment(Class type) returning null

by anil.saldhana＠jboss.com

I think the call to unit.getAttachment(Class) works only if the attachment has been added to the unit without any name, because of the following pattern in AS trunk: | // The ServiceConstructorMetaData is not serializable due to its args | unit.addAttachment(ServiceMetaData.class, webModule); | | .... | | // Get the war URL | WebMetaData metaData = di.getAttachment(WebMetaData.class); | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040079#4040079 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040079

18 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: unit.getAttachment(Class type) returning null

by anil.saldhana＠jboss.com

I can get them by name which does not always serve the purpose. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040074#4040074 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040074

18 years, 11 months

1
0
0 / 0

[Design of POJO Server] - unit.getAttachment(Class type) returning null

by anil.saldhana＠jboss.com

In JBAS trunk, I get null for calls like: ServiceMetaData smd = unit.getAttachment(ServiceMetaData.class); or MetaData md = unit.getAttachment(MetaData.class); I can see them in the debugger. Is there a test case for this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040073#4040073 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040073

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by weston.price＠jboss.com

Also, it should be noted that while the JMS API does not require XA support, the J2EE specification requires that a JMS provider must be supported as a transactional resource manager (Section 4.2.8 in both in 1.4 and EE 5). The JMS/JCA adapter is the fullfilment of this requirement. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040069#4040069 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040069

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by weston.price＠jboss.com

anonymous wrote : | Well, yes I agree this may be unusual, although I don't believe it it illegal. | No, not illegal but it certainly makes deploying non XA JMS based resources with JBM all but impossible while using the JMS/JCA adapter. While this is not necessarily a bad thing, it simply says that when using JCA/JMS in conjunction with JBM you currently have no choice but to use XA which in most scenarios is exactly what you want. anonymous wrote : | It seems to me the JCA is making an incorrect assumption that a particular connection instance can't be both a Connection and an XAConnection. It just so happens up to now JBM is the only provider that implements it this way. | The JMS/JCA adapter does not make any assumptions beyond that which is specified in the requisite configuration files (ie *-ds.xml for outbound connectivity and the activation-configuration for inbound). The JCA/JMS adapter is designed for generic JMS integration with any JMS provider, not just those implementing the optional XA API. What is bound into JNDI and relayed to the adapter via the JMSProviderAdapter is what determines it's use in the context of a global transaction. If an XAConnectionFactory (or it's XA specific counterparts per domain) is bound into JNDI and registered with the adapter via the JMSProviderAdapter configuration property, the adapter uses this. If not, the traditional JMS API is used. This is *by design*. Being that XA is optional for an JMS provider this is used to support providers that do not implement XA but still may want to participate in a global transaction via the LRCG (Last resource commit gambit) much in the same manner as the local-tx-datasource. Similarly, it is used to support clients that do not want to use XA at all and be transaction ignorant (no-tx-connection-factory) and perhaps utilize the local JMS transaction API to control the transaction themselves (Session.commit(), Session.rollback()) while still getting the benefit of connection pooling. In other words, if you want XA you deploy the correct JMS adminstrative objects to support this. If not, or you can't because your JMS provider doesn't support it, you don't. To reflect this you configure your *-ds.xml file (and JMSProviderAdapter) appropriately. Having said all of this, I am not sure that any of this is the cause of the failures in the testsuite/TCK. Without specific stack traces/errors I can't determine what the issue is or if it pertains to JCA/JMS at all. The test offered an example is a perfectly supported use case under JBossMQ, but that isn't saying all that much. Without more information, I simply can't tell. I am more than happy to look at the issues if you want just point me to a specific trace/error that I can review. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040064#4040064 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040064

18 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2007