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/541238#541238
--------------------------------------------------------------
Thanks Alessio and Richard's comments again . Let me summarize our discussion points first , then I will give the issues I can see from my previous experimental work on cxf/jms integration in past two weeks, then you and Richard can continue to add your thoughts and comments:
> 1) Use jbossws-cxf.xml (cxf style configuration file) not the new introduced jbossws-endpoints.xml .
>
Looks like my previous 4 reasons are not the problems at all . To simplify the things , we can use jbossws-cxf.xml to deploy jms transport web service. I agreed for this direction.The one problem I can see if we use jbossws-cxf.xml to deploy jms endpoint so far : jbossws-cxf.xml is now used to customize the default generated cxf deployment descriptor by http endpoint , it will be mixed up with jms endpoint when user specifies the jbossws-cxf.xml for http endpoint ,and also want to deploy the jms endpoint with the same jbossws-cxf.xml. Let's take a example :
////////////////<web.xml>//////////////////
<servlet>
<servlet-name>HelloService</servlet-name>
<servlet-class>org.jboss.test.ws.jaxws.samples.HelloImpl</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloService</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
/////////////////<jbossws-cxf.xml>//////////////////////
<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>
We name the configuration file to only deploy jms endpoint to something like jbossws-cxf-jms.xml ? or we do not support deploy the jms endpoint and http endpoin in one deployment archive ?
> 2) the approach Richard suggested to do jms integration :
> * extend our UMDM (located in SPI) to provide JMS endpoint abstractions
> * extend our DA framework to distinguish DA aspects intended to create web based endpoints and jms based endpoints
> * update our ASIL (concretely WSDeploymentAspectDeployer) to distinguish between Web DAs and JMS DAs
> * implement CXF DA that will map jboss-cxf.xml MD to our UMDM (ensures CXF -> SPI dependency)
> * implement ASIL DA that will create JMS MD from our UMDM (ensures ASIL -> SPI dependency)
> * implement CXF DA that will register plain JMS endpoints with CXF (ensures CXF -> SPI dependency)
>
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.
Add also distinguish the http endpoint and jms endpoint in jbossws-cxf.xml is difficult, for some configuration file (like the example in 1) you need to parse the wsdl , then you can figour out.
> 3) The Endpoint and ASIL dispatch
> * Endpoint
> - ServletEndpoint -> url address
> - JMSEndpoint -> jms address
> * DA
> - ServletDA
> - JMSDA
OK. You convinced me to create JMSEndpoint for jms transport endpoint . It's ideal to use ServletDA to deploy the ServletEndpoint and JMSDA to handle jms endpoint. But again, DA can not handle the dependency deployment which is required by jms transport endpoints deployment in CXF. Do you have some ideas to change the DA api and eable the dependency in DA ?
>
> 4) jms endpoint from wsdl (soap over jms support) sample
I've created a test case for this : https://svn.jboss.org/repos/jbossws/stack/cxf/branches/jms-integration/mo... https://svn.jboss.org/repos/jbossws/stack/cxf/branches/jms-integration/mo...
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541238#541238]
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 HuiSheng Xu
HuiSheng Xu [http://community.jboss.org/people/rebody] replied to the discussion
"JBPM-2537"
To view the discussion, visit: http://community.jboss.org/message/541219#541219
--------------------------------------------------------------
Hi Maciej,
The patch run perfectly. There are still something we should review.
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;
}
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?
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?
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>
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541219#541219]
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] [jBPM Development] - jBPM5 Request for Comments
by Torsten R
Torsten R [http://community.jboss.org/people/tcr] commented on the document
"jBPM5 Request for Comments"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-15172#comment-3277
--------------------------------------------------
Some thoughts:
Very good and one of the reasons why we choose JBPM4 some time ago:
"based on a Process Virtual Machine (PVM), allowing the definition of multiple process languages on the same process engine"
In addition I would keep the interceptor chain. It really gives you a lot of integration options (different app servers, frameworks, transaction managers), all on a solid plug-and-play basis. In combination with the remote command executor this was one of the main benefits in our project.
A very important decision is how the process definitions are to be stored. Right now (jbpm4) processes are stored as XML in DB and the repository-session will ask the deployer to actually instanitate the process definition-object on every startup. This prevents dynamic ad-hoc definitions as they cannot be persistet (only one way is supported: from XML to process definition). JBPM could be a very good Workflow-Engine supporting Ad-Hoc workflows, if there was a mechansim to create and store defintiions via API.
--------------------------------------------------
14 years
Re: [jboss-dev-forums] [Management Development] - domain.xml work
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/541194#541194
--------------------------------------------------------------
> Emanuel Muckenhuber wrote:
>
> So a *DomainControllerProfile* could then be a sub-profile providing the capabilities for a server to act as DomainController?
Either:
*DomainControllerSubprofile*: A subprofile that describes the capabilities necessary for a server to act as a DomainController.
or
*DomainControllerProfile*: A profile that includes a subprofile that describes the capabilities necessary for a server to act as a DomainController.
or perhaps both, with the context determining which is used:
*DomainControllerSubprofile*: A subprofile that describes the capabilities necessary for a server to act as a DomainController.
*DomainControllerProfile*: A profile that includes a DomainControllerSubprofile.
Note that I use the verb "describes" instead of the "includes" on my earlier wiki definition. This is to be consistent with Scott's verbiage in the "Subprofile" definition.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541194#541194]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years