Re: [jboss-dev-forums] [JBoss Web Services Development] - CXF jms integration
by Richard Opalka
Richard Opalka [http://community.jboss.org/people/richard.opalka%40jboss.com] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/541304#541304
--------------------------------------------------------------
Hi Jim, I just reviewed your SPI and ASIL prototypes and here are my 2 cents:
SPI:
Remove org.jboss.wsf.spi.metadata.endpoints.EndpointsFactory (proprietary DD xml JBXB parsing)
Remove org.jboss.wsf.spi.metadata.endpoints.AbstractEndpointsDeployment (to don't publish proprietary DD)
I like org.jboss.wsf.spi.metadata.endpoints.jms.JMDDestinationMetaData
I like org.jboss.wsf.spi.metadata.endpoints.jms.JMDDestinationMetaData but remove static fields from it (proprietary DD xml JBXB parsing)
I like org.jboss.wsf.spi.metadata.endpoints.AddressMetaData (but it's name should be AbstractAddressMetaData because it's abstract class)
I like org.jboss.wsf.spi.metadata.endpoints.EndpointsMetaData (but remove URL related methods & fields)
I like org.jboss.wsf.spi.metadata.endpoints.EndpointMetaData (but here's some overlap with org.jboss.wsf.spi.deployment.Endpoint you should investigate/fix)
ASIL:
Remove org.jboss.webservices.integration.deployers.WSEndpointsDescriptorParserDeployer (proprietary DD xml parsing deployer)
Rewrite org.jboss.webservices.integration.deployers.WSEndpointsRealDeployer
- it have to be DA
- I would name it MetaDataBuilderJMS
- I would place it in package org.jboss.webservices.integration.metadata (because it provides JMS metadata)
Update WSDeploymentAspectDeployer to specify proper inputs/outputs according to passed DeploymentAspect type (JMS/Servlet)
Provide another DeploymentType (DeploymentType.JAXWS_JMS)
Update org.jboss.webservices.integration.deployers.deployment.WSDeploymentBuilder
- remove hacky code
- and provide proper DeploymentModelBuilderJAXWS_JMS integration
Implement org.jboss.webservices.integration.deployers.deployment.DeploymentModelBuilderJAXWS_JMS
- so it properly integrates with SPIEndpoint
- it handles new DeploymentType.JAXWS_JMS
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541304#541304]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss Web Services Development] - CXF jms integration
by Jim Ma
Jim Ma [http://community.jboss.org/people/jim.ma] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/541296#541296
--------------------------------------------------------------
> 1) AFAIK jbossws-cxf.xml is generated only in case there isn't one provided.
> The scenario of deploying both JMS and Servlet endpoints in one war
> using one jbossws-cxf.xml DD should be supported.
> I don't expect any real issues with this scenario.
Sorry , I may do not explain this problem well . We now create SPI endpoint from ServletMetaData in web.xml . How to distinguish the jms tranport endpoint and create jms endpoint/MD from the user provided jbossws-cxf.xml like :
<jaxws:endpoint id='HttpHelloService'
implementor='org.jboss.test.ws.jaxws.samples.HelloImpl>
</jaxws:endpoint>
<!--jms endpoint->
<jaxws:endpoint id='JMSHelloService'
wsdlLocation="./wsdl/jms-samples.wsdl"
implementor='org.jboss.test.ws.jaxws.samples.HelloImpl>
</jaxws:endpoint>
> True, you cannot resolve dependency on JMS deployers in DA code. This can be done only in deployers.
> But you're able to detect if particular DA is JMS DA or Servlet DA. See my suggestion (the pseudocode)
> in my previous post how to resolve this issue in our WSDeploymentAspectDeployer constructor.
> IOW *you shouldn't introduce additional deployers in AS IL*. You should *do everything in DAs* and just *leverage the AS IL integration code*.
AFAIK, the hornetq deployers create BeanMetaData for queue/topic deployment descriptor
and KernalDeploymentDeployer will start/stop these BeanMetaData represents queue/topic created by hornetq deployers.
I understood your suggestion : use deployer input to put the JMS DA after the deployer deployed jms destination. In AS5 , we should put JMSDA after the last real stage deployer ServiceDeployer . AS6, we put JMSDA after KernalDeploymentDeployer. IOW, we do not rely on AS deployer frameworks' deployment dependency mechinism , we rely on the deployer order to resolve the deployment dependency. If this is acceptable and if you do not see any other problems , I will follow your suggestion (as your pseudocode shows) to rewrite .
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541296#541296]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [jBPM Development] - JBPM-2537
by Maciej Swiderski
Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion
"JBPM-2537"
To view the discussion, visit: http://community.jboss.org/message/541263#541263
--------------------------------------------------------------
Hi,
here comes my comments:
> HuiSheng Xu wrote:
> We should add more information in here. And the state constaints is defined in Task interface. So should we move STATE_TIMEOUT and STATE_CANCELLED from HistoryTask to Task?
>
> Actually, the STATE_COMPLETED field in Task is duplicated by STATE_COMPLETED field in HistoryTask.
>
>
In my opinion Task and HistoryTask are two different entities and they should be kept separated.
States are defined in both places because they are used by different queries. So I think they should be as is.
> HuiSheng Xu wrote:
> 1.Should we modify TaskImpl.isComplete(), let this method fit additional states: 'timeout' and 'cancelled'.
>
> Now the isComplete() is like this:
> *public* *boolean* isCompleted() {
> *if* (Task.STATE_COMPLETED.equals(state)) {
> *return* *true*;
> }
> *if* ((Task.STATE_OPEN.equals(state)) || (Task.STATE_SUSPENDED.equals(state))) {
> *return* *false*;
> }
> *return* *true*;
> }
>
I think this is only internal method and IMO it is about verifying if that was already completed in regular way. Timeout and cancel are not completion states, they just close the task and not complete it. That's why states for them are only for history purposes.
> HuiSheng Xu wrote:
>
> 2. The content of TaskTimeout.java and TaskCancel.java is exactly the same. The only difference of them is the completion state, so should we make a abstract class, e.g. AbstractTaskCancel, and let them inherit the superclass?
>
Yeap, you are right here, they are quite the same. We could make an abstract class or shall we give it some thought and check if they should be the same?!
> HuiSheng Xu wrote:
>
> 3. I notice that there is a jbpm.task.lifecycle.xml configution file in the classpath since jBPM-4.0.0-Alpha2, and it contains the prossible states of task. Should we modify it as well? or this configuration file is useless and should be removed in the future version? The content of this file like below:
> <task-lifecycle initial="open">
> <state name="open">
> <transition name="complete" to="completed" />
> <transition name="suspend" to="suspended" />
> <transition name="cancel" to="cancelled" />
> </state>
> <state name="suspended">
> <transition name="resume" to="open" />
> <transition name="cancel" to="cancelled" />
> </state>
> <state name="cancelled" />
> <state name="completed" />
> </task-lifecycle>
>
I haven't seen it before, so thanks for pointing it out. I did look for it in the code but with the same result as Michael, no real references of it. They should not be used by custom code either since they are internal classes.
Thanks for your comments
Maciej
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541263#541263]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss Web Services Development] - CXF jms integration
by Richard Opalka
Richard Opalka [http://community.jboss.org/people/richard.opalka%40jboss.com] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/541260#541260
--------------------------------------------------------------
1)
AFAIK jbossws-cxf.xml is generated only in case there isn't one provided.
The scenario of deploying both JMS and Servlet endpoints in one war
using one jbossws-cxf.xml DD should be supported.
I don't expect any real issues with this scenario.
2) & 3)
> Jim Ma wrote:
> > If you look at my cxf integration work two weeks ago, you can find what I did except the jbossws-endpoints are mainly follow this suggested approach. But after I realized the jms endpoints needs the jms queue/topic deployment dependencies, I created the BeanMataData and deliever the KernalDeploymentDeployer to deploy the jms endpoints . At present , we can not resolve the deployment dependency in the DA.
True, you cannot resolve dependency on JMS deployers in DA code. This can be done only in deployers.
But you're able to detect if particular DA is JMS DA or Servlet DA. See my suggestion (the pseudocode)
in my previous post how to resolve this issue in our WSDeploymentAspectDeployer constructor.
IOW *you shouldn't introduce additional deployers in AS IL*. You should *do everything in DAs*
and just *leverage the AS IL integration code*.
This said I suggest you to delete both BeaMetaData and KernalDeploymentDeployer in our SPI
and rewrite your solution to follow my suggestions ;)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541260#541260]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [jBPM Development] - JBPM-2537
by Michael Wohlfart
Michael Wohlfart [http://community.jboss.org/people/mwohlf] replied to the discussion
"JBPM-2537"
To view the discussion, visit: http://community.jboss.org/message/541258#541258
--------------------------------------------------------------
Hi Guys,
I also stumbled across the jbpm.task.lifecycle.xml file and tried to find out what it was doing, this is what i managed to figure out so far:
The content of the file is read in org.jbpm.pvm.internal.task.LifeCycle.java, it is parsed and seems to implement a kind of min-process / state machine for the task status. You can call LifeCycle.fireLifeCycleEvent(String eventName, TaskImpl task)and it changes the state of the task according to the transitions defined in jbpm.task.lifecycle.xml.
protected static void fireLifeCycleEvent(String eventName, TaskImpl task) {
// reading the state machine
ExecutionImpl lifeCycleExecution = new ExecutionImpl();
ProcessDefinitionImpl lifeCycleProcess = getLifeCycle(task);
lifeCycleExecution.setProcessDefinition(lifeCycleProcess);
// setting up the current state:
String state = task.getState();
Activity activity = lifeCycleProcess.getActivity(state);
lifeCycleExecution.setActivity((ActivityImpl) activity);
// performing a transition
lifeCycleExecution.signal(eventName);
// transfering the new state to the task
task.setState(lifeCycleExecution.getActivity().getName());
}
I think this is great stuff, unfortunatly I couldn't find any place in the code where LifeCycle.fireLifeCycleEvent(String eventName, TaskImpl task)is called, but to me it seems a nice idea to have the task status and transitions configurable in a single file like this.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541258#541258]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years