[JBoss Seam] - Concurrent Access Exception - should never happen, right?
by dhinojosa
>From what I interpret from 3.1.10. Concurrency model (it's description is hard to follow). So trying to oversimplify what it says....
Application scope - Multithreaded, concurrency protected by the servlet container?
Session scope - Multithreaded, concurrency protected by Seam serialization.
Conversation scope - Single threaded, concurrency protected by Seam serialization
Other smaller scopes - Multithreaded, concurrency not an issue since the scope on bean is short lived.
So, given these set of rules, if I am correct, you can only get a ConcurrentAccessException at an application scoped stateful bean, and is the only stateful bean that can and should accept a @Synchronized annotation (I believe there is a mistake in the documentation regarding this). Non-EJB-stateful components can have @Synchonized, but these beans will never encounter a ConcurrentAccessException. If you do get a ConcurrentAccessException anywhere else, then that would be considered a bug in seam.
Right or Wrong? ;)
Tags: ConcurrentAccessException Seam
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4105768#4105768
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4105768
18 years, 8 months
[JBoss Portal] - Re: Unable to Consume Remote Portlet
by chris.laprun@jboss.com
"vinuneelu" wrote : Hi Chris,
| I found one wsdl file named "wsrp_v1_bindings.wsdl" in Webspere Portal.
| Inside that there is one entry for getServiceDescription. Could you please tell me whether you meant this description?
|
| <wsdl:binding name="WSRP_v1_ServiceDescription_Binding_SOAP" type="intf:WSRP_v1_ServiceDescription_PortType">
| <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
|
| <wsdl:operation name="getServiceDescription">
| <soap:operation soapAction="urn:oasis:names:tc:wsrp:v1:getServiceDescription"/>
| <wsdl:input name="getServiceDescription">
| <soap:body use="literal"/>
| </wsdl:input>
| <wsdl:output name="getServiceDescriptionResponse">
| <soap:body use="literal"/>
| </wsdl:output>
| <wsdl:fault name="InvalidRegistration">
| <soap:fault name="InvalidRegistration" use="literal"/>
| </wsdl:fault>
| <wsdl:fault name="OperationFailed">
| <soap:fault name="OperationFailed" use="literal"/>
| </wsdl:fault>
| </wsdl:operation>
| </wsdl:binding>
This is the web service description of the web service operation. What I'd like to see is the result of calling this operation. This won't be a static file that you can find, but rather the SOAP response to a call to that getServiceDescription operation.
You might want to consider getting professional support from us, as it would help you solve your issue and get up to speed faster.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4105761#4105761
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4105761
18 years, 8 months
[EJB 3.0] - 422GA remoting conflicts with -Djboss.remoting.pre_2_0_compa
by Herculesx
In my last topic http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4105325
, I found jbossall-client.jar conflicts between 421 and 422 AS, that's a serialVersionUID bug. And I continue to test other version clients for Jboss 422 AS, and still have problem in Jboss 405 case.
I use the flag -Djboss.remoting.pre_2_0_compatible=true on the JBoss 4.2.2 side to interoperate with Jboss 4.0.5GA client, and the client can call 422 EJB3 successfully. But after that, I found another client using 422 jbossall-clent.jar can not call the EJB3 any longer, the following exception occured:
| javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.remoting.InvokerLocator; local class incompatible: stream classdesc serialVersionUID = -2909329895029296248, local class serialVersionUID = -4977622166779282521]
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:780)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
| ......
|
And I remove the flag -Djboss.remoting.pre_2_0_compatible=true, it works fine, of course the jboss 405 client failed as well.
It seems that when using -Djboss.remoting.pre_2_0_compatible=true, the jboss remoting 2.0 becomes incompatible with 422 AS, I think that's a bug of jboss 422, maybe a jboss remoting bug also.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4105757#4105757
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4105757
18 years, 8 months