[Design of JBoss Web Services] - Re: JBWS-1452 - WSDL To Java, Array unwrapping.
by darran.lofthouse＠jboss.com
Thanks for the information, I have been looking at the test case for http://jira.jboss.com/jira/browse/JBWS-732 to try and get a better understanding of the expected behaviour of array unwrapping.
I have the following defined in my WSDL: -
<types>
| <schema targetNamespace='http://test.jboss.org/ws/jbws1452/types' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:tns='http://test.jboss.org/ws/jbws1452/types' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
|
| <complexType name='testMethod'>
| <sequence>
| <element name='request' nillable='true' type='tns:RequestStringArray'/>
| </sequence>
| </complexType>
|
| <complexType name='RequestStringArray'>
| <sequence>
| <element name='TheStrings' type='string' maxOccurs='unbounded'/>
| </sequence>
| </complexType>
|
| <complexType name='testMethodResponse'>
| <sequence>
| <element name='result' nillable='true' type='tns:ResponseStringArray'/>
| </sequence>
| </complexType>
|
| <complexType name='ResponseStringArray'>
| <sequence>
| <element name='TheStrings' type='string' maxOccurs='unbounded'/>
| </sequence>
| </complexType>
|
| <element name='testMethod' type='tns:testMethod'/>
| <element name='testMethodResponse' type='tns:testMethodResponse'/>
| </schema>
| </types>
| <message name='TestEndpoint_testMethod'>
| <part element='ns1:testMethod' name='testMethod'/>
| </message>
| <message name='TestEndpoint_testMethodResponse'>
| <part element='ns1:testMethodResponse' name='testMethodResponse'/>
| </message>
|
I believe this matches the wrapped array example from the test case. The complexType 'testMethod' contains a sequence with a single element which references a complexType 'RequestStringArray' which contains a sequence that just contains the array. Using wstools the following method is generated on the SEI: -
(Packages removed for readability)
| public ResponseStringArray testMethod(RequestStringArray request)
| throws RemoteException;
|
So the first stage of parameter unwrapping has occured but I don't think the array unwrapping has occured, I was expecting the method to look like: -
| public String[] testMethod(String[] request)
| throws RemoteException;
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001285#4001285
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001285
19 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - AUTO_ACKNOWLEDGE weirdness
by timfox
Something struck me as a bit strange with the AUTO_ACKNOWLEDGE and MessageListeners as defined in the JMS spec.
It has always been my understanding that using AUTO_ACKNOWLEDGE gives a "at most once" delivery guarantee.
You get a "at most once" guarantee because (with receive() at least) the message is acknowledged *before* the call to receive() has returned, so if failure occurs between acking and giving you the message it is effectively lost you - you didn't receive it, but you could never get it more than once.
However when using a MessageListener breaks this breaks down. For a MessageListener, according to the JMS spec, if you are using AUTO_ACKNOWLEDGE then the message should be acked *after* the onMessage has finished executing.
This means if a failure occurs right at the end of the onMessage but before the message is acked, it could be received again - i.e. you could get duplicates, and the "at most once" delivery guarantee is lost.
In order to maintain "at most once" semantics the message should be acked before onMessage is called.
Is this just a stupidity in the JMS spec or can you think of any reason it was done this way?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001281#4001281
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001281
19 years, 2 months
[Design of JCA on JBoss] - Problems JCA JMS inflow issue and tx NotSupported
by timfox
Weston - sorry to bug you again.
I'm using the JCA inflow invoker-proxy-binding in JBoss-4.0.5.GA for MDBs, and I'm using JBoss Messaging as the JMS provider.
I have the following trivial MDB:
| public class MDBExample implements MessageDrivenBean, MessageListener
| {
| public void onMessage(Message m)
| {
| System.out.println("got message " + m);
| }
|
| public void ejbCreate()
| {
| }
|
| public void ejbRemove()
| {
| }
| }
|
| <ejb-jar>
| <enterprise-beans>
| <message-driven>
| <ejb-name>MDBExample</ejb-name>
| <ejb-class>org.jboss.example.jms.mdb.MDBExample</ejb-class>
| <transaction-type>Container</transaction-type>
| <message-driven-destination>
| <destination-type>javax.jms.Queue</destination-type>
| </message-driven-destination>
| </message-driven>
| </enterprise-beans>
|
| <assembly-descriptor>
| <container-transaction>
| <method>
| <ejb-name>MDBExample</ejb-name>
| <method-name>*</method-name>
| </method>
| <trans-attribute>Required</trans-attribute>
| </container-transaction>
| </assembly-descriptor>
| </ejb-jar>
|
I sent a message, and it all works fine, the message gets consumed and acked.
I then change the trans-attribute to "NotSupported", so the onMessage should not be run in a tx context, and send a message again, and I get:
| 10:59:37,437 ERROR [JmsServerSession] Failed to commit session transaction
| javax.jms.TransactionInProgressException: Cannot call commit on an XA session
| at org.jboss.jms.client.container.TransactionAspect.handleCommit(TransactionAspect.java:97)
| at org.jboss.aop.advice.org.jboss.jms.client.container.TransactionAspect14.invoke(TransactionAspect14.java)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.
| java)
| at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:182)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.
| java)
| at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.
| java)
| at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$commit_8461082169793485964.invokeNext(ClientSessionDelegate$commit_8461082169793485964.
| java)
| at org.jboss.jms.client.delegate.ClientSessionDelegate.commit(ClientSessionDelegate.java)
| at org.jboss.jms.client.JBossSession.commit(JBossSession.java:165)
| at org.jboss.resource.adapter.jms.inflow.JmsServerSession$LocalDemarcationStrategy.end(JmsServerSession.java:341)
| at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:260)
| at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
| at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
| at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
| at java.lang.Thread.run(Thread.java:534)
|
I.e. it fails.
A couple of things I don't understand:
Why is there a transaction in the first place? The onMessage is supposed to run without a transaction and should be using the ack mode specified on the ejb (either dups_ok or auto_ack)
Why is JCA attempting to call commit() on it? The session that the JCA layer creates is an XASession and calling commit() on an XASession is illegal.
(see http://java.sun.com/j2ee/1.4/docs/api/index.html)
For a "NotSupported" method, I would expect the session used to do the message consumption to be a standard non XA session obtained from a standard non XA JMS connection, and I wouldn't expect commit to be called on it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001240#4001240
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001240
19 years, 2 months
[Design the new POJO MicroContainer] - Re: ServiceMetaData parsing needs to be pulled out of Servic
by bill.burke＠jboss.com
anonymous wrote : What the admin tool needs to see is an inverted view where it gets a set of ManagedPropertys to edit, and these changes get mapped onto the attachment settings. While this can be setup inside the server via aspects, when a remote tool queries the properties and edits them, the aspects are lost. Essentially the same issue as entity beans becoming detached. Either I need to leverage logic similar to what hibernate does, or have an xpath like attribute in a ManagedProperty that allows the tool to submit a set of changed ManagedPropertys that can be applied to the deployment attachment attribute by navigating from the attachment root to the correct attachment property.
Ok. I'm commenting based on reading just this thread and looking a bit at your code in org.jboss.test.profileservice.p0, so don't be too annoyed if I'm missing something....
IMO, an admin tool is going to need a complete structural view of ManagedObjects/DeploymentContexts to be able to display a generic UI to the user. For example, the UI might look like this:
| <DeploymentContext name="MyApp.ear">
| <!-- default security domain for ear -->
| <ManagedObject name="Security">
| <ManagedProperty name="SecurityDomain" value="other"/>
| </ManagedObject>
| <DeploymentContext name="MyEjb.jar">
| <!-- default security domain for application -->
| <ManagedObject name="Security">
| <ManagedProperty name="SecurityDomain" value="UNMODIFIED"/>
| </ManagedObject>
| <DeploymentContext name="jboss.ejb:ejbName=BankDAOBean">
| <!-- default security domain for application -->
| <ManagedObject name="Security">
| <ManagedProperty name="SecurityDomain" value="UNMODIFIED"/>
| </ManagedObject>
| </DeploymentContext>
| </DeploymentContext>
| </DeploymentContext>
|
Since the admin tool would have knowledge of structure, why not have a set of management deployers or another specific management() callback on the Deployer SPI? The admin tool would send back a list of ManagedProperties with structural information attached.
Lets use the modification of a security-domain of an EJB on the above as an example. Admin tool would change the name of the ManagedProperty and send this back to the MainDeployer:
|
| <DeploymentContext name="MyApp.ear">
| <DeploymentContext name="MyEjb.jar">
| <DeploymentContext name="jboss.ejb:ejbName=BankDAOBean">
| <ManagedObject name="Security">
| <ManagedProperty name="SecurityDomain" value="CorporateDomain"/>
| </ManagedObject>
| </DeploymentContext>
| </DeploymentContext>
| </DeploymentContext>
|
|
MainDeployer would navigate to the specific DeploymentContext and push the Update object to a set of deployers. Each deployer decides what it wants to do with the update. The EjbSecurityDeployer would be in this list. It would take the change, lookup the specific SecurityDomain and reset it on the EJBContainer.
The maindeployer would also attach the Update to the DeploymentContext. If an Update with the same ManagedObject and Property is there, the old one is removed. If the UPdate is persistable, the mainDeployer adds it to the Profile.
At server restart, the EjbDeployer would merge any persisted Updates into its metamodel.
Now what if the admin tool updated the EAR's default security domain?
|
| <DeploymentContext name="MyApp.ear">
| <ManagedObject name="Security">
| <ManagedProperty name="SecurityDomain" value="CorporateDomain"/>
| </ManagedObject>
| </DeploymentContext>
|
|
The way this would work would be that the MainDeployer would see that there are child DeploymentContexts and try to "deploy" the change to each and every child context. The EjbSecurityDeployer would do something like this:
| {
| public void managementEvent(ManagedUpdate update, DeploymentContext context) {
| if (update.getName() != "Security) return;
|
| boolean isThisContextUpdated = update.getDeploymentContext == context;
|
| EJBDeployment deployment = context.getMetaData(EJBDeployment.class);
| if (deployment != null)
| {
| // we are at the "ejb.jar" context deployment level.
| deployment.setSecurityDomain(update.getProperty("security-domain").getValue());
| return;
| }
|
| EJBContainer container = context.getMetaData(EJBContainer.class);
| if (container != null) {
| String newSecurityDomain = update.getProperty("security-domain").getValue();
| // we are at the EJBContainer level
|
| if (isThisContextUpdated)
| {
| // the admin tool has updated the same DeploymentContext as the EJBContainer
| container.updateSecurityDomain(newSecurityDomain);
| }
| else
| {
| // the admin tool has updated the ejb.jar context or the EAR's context, so only
| // set if our securitydomain is null
| if (container.getSecurityDomain() == null) container.updateSecurityDomain(newSecurityDomain);
| }
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001119#4001119
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001119
19 years, 2 months