[JBoss Tools] - JBoss Dev Studio: jars from dependant projects disappearing from deployed wars
by Mark Taylor
Mark Taylor [https://community.jboss.org/people/mtt_] created the discussion
"JBoss Dev Studio: jars from dependant projects disappearing from deployed wars"
To view the discussion, visit: https://community.jboss.org/message/749144#749144
--------------------------------------------------------------
We are evaluating JBoss Dev Studio for use in our projects. We are running into the problem below.
For our applications we deploy and EJB 3.0 jar and several wars. In Eclipse we have separate projects for the EJB and wars, as well as 2 utility projects. Each war project has the two utility projects as dependancies. We add the utility projects to the Deployment Assemblies for each web project. When we publish the first project to JBoss, the utility jars go to WEB-INF/lib as they are supposed to.
The problem is that when we publish the next war it deploys with the jars in WEB-INF/lib, BUT the utility jars disappear from the first wars WEB-INF/lib. Then start up fails because the first web app doesn't see the jars in the second web apps WEB-INF/lib folder. Order is completely arbitrary.
The Deployment Assembly seems to be working correctly, it appears to be a problem with the JBoss management plugin removing what it believes to be extra jars. Has anyone seen this before?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/749144#749144]
Start a new discussion in JBoss Tools at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 8 months
[Javassist] - Compile problem with interface initialization
by Enrico Palazzo
Enrico Palazzo [https://community.jboss.org/people/pulce] created the discussion
"Compile problem with interface initialization"
To view the discussion, visit: https://community.jboss.org/message/749098#749098
--------------------------------------------------------------
Hi there! I implemented code to my project that makes use of javassist. However, I constantly fail to implement an interface to a new class I create. Here is the code I use (adapted from http://www.javaranch.com/journal/200711/Journal200711.jsp#a4): http://www.javaranch.com/journal/200711/Journal200711.jsp#a4):
*Main file:*
package test;
import javassist.*;
public class Example2 {
public static void main (String[] args) throws Exception {
ClassPool pool = ClassPool.getDefault();
CtClass evalClass = pool.makeClass("Eval"+System.currentTimeMillis());
evalClass.setInterfaces(new CtClass[] { pool.makeClass("Evaluator") });
evalClass.addMethod(CtNewMethod.make("public double eval (double x) { return (x*x-x) ; }", evalClass));
Class clazz = evalClass.toClass();
Evaluator obj = (Evaluator) clazz.newInstance();
double result = obj.eval(4);
System.out.println(result);
}
}
*Interface "Evaluator":*
package test;
public interface Evaluator {
public double eval (double x);
}
The code works like a charm in the default package of an Eclipse project (without package test; of course). However, when I use it in a package, I get an Error:
javassist.CannotCompileException: by java.lang.NoClassDefFoundError: Evaluator
>From trial and interpreting different error messages I guess that the class loader that should load "Evaluator" refers to the /bin path, while the Evaluator.class file is to be found in the /bin/test folder. Is there a way to solve that? Many thanks in advance!
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/749098#749098]
Start a new discussion in Javassist at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 8 months
[Beginner's Corner] - Migrating from jboss 4.2.3 to 5.1.0
by gajendra jangid
gajendra jangid [https://community.jboss.org/people/gjangid] created the discussion
"Migrating from jboss 4.2.3 to 5.1.0"
To view the discussion, visit: https://community.jboss.org/message/749122#749122
--------------------------------------------------------------
Hi,
For the purpose to migrate to jboss 5.1.0 , I have placed the changes in the .xml files of .ear files of my application.
I encounterd following error while starting up the jboss.
Here is the error :-
08:39:12,126 [main] ERROR [AbstractKernelController] Error installing to Parse: name=vfsfile:/opt/sonus/xauth/as/server/all_test/farm/trunkGroupActivator.ear/ state=Not Installed mode=Manual requiredState=Parse
org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/opt/sonus/xauth/as/server/all_test/farm/trunkGroupActivator.ear/
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:362)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:322)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:294)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:234)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:619)
*Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: cvc-complex-type.2.4.a: Invalid content was found starting with element 'description'. One of '{" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee":display-name, " http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee":icon, " http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee":module}' is expected. @ vfsfile:/opt/sonus/xauth/as/server/all_test/farm/trunkGroupActivator.ear/META-INF/application.xml[8,16]*
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168)
at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:189)
at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:166)
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137)
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121)
at org.jboss.deployment.AppParsingDeployer.parse(AppParsingDeployer.java:79)
at org.jboss.deployment.AppParsingDeployer.parse(AppParsingDeployer.java:46)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:188)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:348)
... 33 more
*Caused by: org.xml.sax.SAXException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'description'. One of '{" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee":display-name, " http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee":icon, " http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee":module}' is expected. @ vfsfile:/opt/sonus/xauth/as/server/all_test/farm/trunkGroupActivator.ear/META-INF/application.xml[8,16]*
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$MetaDataErrorHandler.error(SaxJBossXBParser.java:426)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:199)
I think the error is due to the declaration in application.xml and web.xml.
Here is my application.xml
*<?xml version="1.0" encoding="UTF-8"?>*
*<application xmlns=" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee"*
*xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2001/XMLSchema-instance"*
*xsi:schemaLocation=" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd http://java.sun.com/xml/ns/javaee/application_5.xsd"*
*version="5">*
* <display-name>Trunk Group Activator </display-name>*
* <description>Trunk Group Activator for the Sonus Networks Systems</description>*
* <!-- IMPORTANT: No longer need to list jars for JBoss or for WebLogic -->*
* <module>*
* <ejb>AsyncRegistrationBean.jar</ejb>*
* </module>*
* <!-- deployment of the web application module -->*
* <module>*
* <web>*
* <web-uri>trunkGroupActivator.war</web-uri>*
* <context-root>/trunkGroupActivator</context-root>*
* </web>*
* </module>*
* <module>*
* <web>*
* <web-uri>trunkGroupActivatorAPI.war</web-uri>*
* <context-root>/trunkGroupActivatorAPI</context-root>*
* </web>*
* </module>*
* <module>*
* <web>*
* <web-uri>jdcpool.war</web-uri>*
* <context-root>/jdcpool_tga</context-root>*
* </web>*
* </module>*
* <module>*
* <ejb>common-utils-mdbs.jar</ejb>*
* </module>*
*</application>*
Web.xml :-
*<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>*
*<web-app version="2.5"*
* xmlns=" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee"*
* xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2001/XMLSchema-instance"*
* xsi:schemaLocation=" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">*
*........*
*......*
*</web-app>*
Any kind of help will be highly praised.
Thanks,
Gajendra.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/749122#749122]
Start a new discussion in Beginner's Corner at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 8 months
[Beginner's Corner] - Info on Getting reference to JBoss MBean Server
by Ragav Baskaran
Ragav Baskaran [https://community.jboss.org/people/ragavendran_kb] created the discussion
"Info on Getting reference to JBoss MBean Server"
To view the discussion, visit: https://community.jboss.org/message/749121#749121
--------------------------------------------------------------
Hi, I'm trying to get reference to Jboss MBean server using the code snippet below. I'm invoking this in a JSP file which is present in a WAR file and deployed in default profile of Jboss.
If i try with the below,
.....
MBeanServer server = MBeanServerLocator.locateJBoss();
.....
I'm getting this error.
[java] java.lang.IllegalStateException: No 'jboss' MBeanServer found!
[java] at org.jboss.mx.util.MBeanServerLocator.locateJBoss(MBeanServerLocator.java:110)
[java] at org.apache.jsp.demo_jsp._jspService(demo_jsp.java:67)
[java] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
[java] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
[java] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
[java] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
If i use the below:
...
MBeanServer server = MBeanServerLocator.locate();
...
then getting this error.
[java] java.util.NoSuchElementException
[java] at java.util.AbstractList$Itr.next(AbstractList.java:350)
[java] at org.jboss.mx.util.MBeanServerLocator.locate(MBeanServerLocator.java:67)
[java] at org.jboss.mx.util.MBeanServerLocator.locate(MBeanServerLocator.java:80)
[java] at org.apache.jsp.demo1_jsp._jspService(demo1_jsp.java:67)
[java] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
[java] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
Also tried this option, but not able to get reference to the mbean server.
....
ArrayList serverList = MBeanServerFactory.findMBeanServer (null);
log ("servers.size() = " + serverList.size());
.....
Output:
servers.size() = 0
Can you please explain the reason for this error or what is the correct way to obtain reference of Jboss mbean server in application code running on the same VM.
Dropped the below JSP file in to jmx-console.war of jboss
<%@page import="javax.management.MBeanServer"%>
<%@page import="org.jboss.mx.util.MBeanServerLocator"%>
<%@page import="javax.management.MBeanServerFactory"%>
<%@page import="java.util.ArrayList"%>
<html>
<body>
<%
MBeanServer server1 = MBeanServerLocator.locate();
MBeanServer server2 = MBeanServerLocator.locateJBoss();
ArrayList ser = MBeanServerFactory.findMBeanServer(null);
%>
Locate method : <%=server1%> </br>
Locate Jboss method : <%=server2%> </br>
findMBeanServer method : <%=ser%> </br>
</body>
</html>
I'm able to see the below output:
Locate method : org.jboss.mx.server.MBeanServerImpl@121dcac[ defaultDomain='jboss' ]
Locate Jboss method : org.jboss.mx.server.MBeanServerImpl@121dcac[ defaultDomain='jboss' ]
findMBeanServer method : [org.jboss.mx.server.MBeanServerImpl@121dcac[ defaultDomain='jboss' ], org.jboss.mx.server.MBeanServerImpl@dc5c8b[ defaultDomain='null' ]]
However if i drop the same JSP in to my application WAR and access it. I'm getting this exception as stated in my above post.
I'm running out of clues. Any help will be highly appreciated.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/749121#749121]
Start a new discussion in Beginner's Corner at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 8 months
[jBPM] - Human Task Module Refactoring
by Mauricio Salatino
Mauricio Salatino [https://community.jboss.org/people/salaboy21] modified the document:
"Human Task Module Refactoring"
To view the document, visit: https://community.jboss.org/docs/DOC-18789
--------------------------------------------------------------
This document aims to explain how the human task module should look after applying some refactorings which were the results of several experiments.
You can more about this experiments here: https://github.com/Salaboy/human-task-poc-proposal https://github.com/Salaboy/human-task-poc-proposal
The following sections describe how the module will look like after the refactorings
h1. APIs and Service Structure
All the Services Proposed by this refactoring are CDI managed beans. For the ones not familiar with CDI, you need to think about it as JPA for Dependency Injection frameworks. So we can say
that CDI is to Spring/Guice/Weld what JPA is to Hibernate/Top Link. CDI propose some very cool out of the box features that we definitely want to use to make our services more clear, robust, easy to maintain. Some of the things provided by CDI that I'm using in the experiments are:
* Configuration based on annotations: We can inject services instances without needing to specify the implementation, so we keep it pluggable and decoupled all the time.
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
As you can see there, we can define at service level which characteristic the service implementation will need to be injected inside a service, but then we can provide several alternatives
for that implementation and configure them for different environments. The CDI container will do the rest for us, it will choose wisely the implementation that fits with all the characteristic required and it will inject the services implementation when it's need.
* Event Producers and Observers
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
and: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
As you can see a simple and out of the box (and defined by an specification) Event mechanism is provided, allowing us to keep our Event Producers completely Decoupled from our Event Observers. We can also configure the obsevers to be instantiated by teh CDI container or we can decide how many instances of our observer do we need for a particular use case.
* Decorators/Interceptors:
We can use both to improve a specific technical or business policy should be applied to the execution of our service methods.
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
Decorators and Interceptors can be enabled and disabled based on configurations, which give us once again a great flexibility to add or remove things based on what we want to achieve.
At the end of the day we have a set of services which can leverage the power of the CDI container. We can also hide that we are using CDI/Weld (weld is the implementation of the CDI interfaces/spec), look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
We can use it internally and if the user wants to get access to the container he/she can.
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-6-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-6...
All the proposed services are simple POJOs which can contain references to all the other services. We can combine them to achive different functionality.
For a more detailed description about each service you can look at: https://community.jboss.org/docs/DOC-18641 https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal
The next section describe more advantages about using the CDI/Weld proposed programming model to keep our services simple and take out all the code that is not related with Human Interaction logic.
h1. Services Working Together
The following image shows how the interactions with the human task module will happen. The diagram shows the interfaces and implementations required to interact with a TaskInstance
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-6-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-6...
The previous figure shows all the components interacting when we want to interact with a task instance that was already created.
So let's say for example that we want to start a task. From the client perspective he/she can use the TaskServiceEntryPoint to
start the task. This TaskServiceEntryPoint will delegate the calls to the different service implementations. In this case if we are
starting a task the TaskInstanceService implementation will delegate the action to the LifeCycleManager. As you can see
the LifeCycleManager, no matter the implementation is being decorated by an UserGroupDecorator which in charge of handling the
resolution of the identities associated with the operation. The LifeCycleManager is also an Event Producer, which means that is in charge
of generating events to communicate to the external world the LifeCycle changes of each task. We can then attach external listeners to
Observer these events to audit what is happening or as callback mechanisms to execute actions when a task is completed for example.
Classes and Interfaces to look at this point:
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
No magic, no complicated debug sessions, the services should be as straight forward as possible trying to following the sequence:
*TaskServiceEntryPoint ---(Delegate)--> Task*ServiceImpl -> Storage*
h3. Shared Persistence Context and Transactional Behavior
If you take a look at the previous links you will notice that all the Services, for example TaskInstanceServiceImpl and TaskDefServiceImpl are all using an Inject EntityManager.
And there is no code related with transactions or loading and merging detached entities (em.getTransaction(), ut.begin(), em.merge()).
The EntityManager that is being injected is being managed by Seam Persistence (ASL 2.0) ( http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html_single/ http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html_single/) which give us a transparent
way of having all the advantages of the unified programming model of being in Managed and Transaction Persistence Context without the hassle of taking care of how to share different
instances of an EntityManager or demarcate the transactions based on what is available in our context. Seam Persistence provide us a declarative way to deal with all this topics, and take all the code
related with these tasks out of the Human Task Module. This also give us the possibility to integrate with Spring only configuring our environment and not changing our code
( http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html)
The Seam 3 Spring module give us all the integration that we can possible want and even more with Spring, no need to worry about that stuff at all: http://seamframework.org/Seam3/SpringModule http://seamframework.org/Seam3/SpringModule
h1. Integration with the Outside World
Using CDI for the integration perspective is just great. Most of the integration frameworks out there have CDI integration which make exposing our services extremely easy and natural.
I've created an experiment showing how we can do this with Switchyard/Camel, and most of this principles can be used for the Process/Rule engine as well:
https://github.com/Salaboy/human-task-poc-proposal/tree/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/tree/master/human-task...
The main focus of this project is to contain all the integration configuration required to expose our POJO services using different transports. I've being focused on JMS because it will allow
us to have asynchronous interactions transparently.
The following figure shows us teh Switchyard Declarative configuration which is using our CDI POJO services to define the integration points:
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-6-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-6...
The previous diagram is showing the following interaction and integration points:
1. A client sending a JMS message wants to start a task
2. The Switchyard container is exposing a JMS queue which is expecting "Action" messages
3. As soon as we get one of this action messages, Switchyard picks the message and propagate it to the correspondant service
4. We can register a listener that will observe the events being fired by our components (i.e. TaskLifeCycleEvents)
5. As soon as one of these events is observed by our listener it will be redirected to a JMS topic which can contain multiple subscribers
6. Any number of subscribers can pick up the message and do what they want with it
More info: https://community.jboss.org/docs/DOC-18719 https://community.jboss.org/wiki/HumanTaskModuleSwitchYardIntegration
NOTE: An Executor component can be used to pick the up the notification and execute callbacks. I'm right now creating a document which explains how this component can be used.
This idea perfectly fits in this scenario. I will add the link as soon as the document is ready.
Cool Facts:
1. This experiment is just showing one of the possibilities of using Switchyard and the camel integration for handling async interactions in a very efficient way, without including code inside the Human Task Module. We are delegating all the interaction points to the Integration framework instead of adding complexity to the Human Task Logic.
2. We can integrate with any transport in the same way and we can mix and match what we want. For example, we can recieve a REST call and send notifications via JMS
3. Switchyard and all the services can run inside a SE or EE environment (because of CDI and its programming model)
4. Is all based on configuration, so we can provide a set of well known configurations and let the users to customize that if they want
5. Quartz for reminders, cron tasks and all of that comes for free
6. Push us to use a clean programming model, leverage all the CDI features
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18789]
Create a new document in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 8 months
[jBPM] - Human Task Module Refactoring
by Mauricio Salatino
Mauricio Salatino [https://community.jboss.org/people/salaboy21] modified the document:
"Human Task Module Refactoring"
To view the document, visit: https://community.jboss.org/docs/DOC-18789
--------------------------------------------------------------
This document aims to explain how the human task module should look after applying some refactorings which were the results of several experiments.
You can more about this experiments here: https://github.com/Salaboy/human-task-poc-proposal https://github.com/Salaboy/human-task-poc-proposal
The following sections describe how the module will look like after the refactorings
h1. APIs and Service Structure
All the Services Proposed by this refactoring are CDI managed beans. For the ones not familiar with CDI, you need to think about it as JPA for Dependency Injection frameworks. So we can say
that CDI is to Spring/Guice/Weld what JPA is to Hibernate/Top Link. CDI propose some very cool out of the box features that we definitely want to use to make our services more clear, robust, easy to maintain. Some of the things provided by CDI that I'm using in the experiments are:
* Configuration based on annotations: We can inject services instances without needing to specify the implementation, so we keep it pluggable and decoupled all the time.
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
As you can see there, we can define at service level which characteristic the service implementation will need to be injected inside a service, but then we can provide several alternatives
for that implementation and configure them for different environments. The CDI container will do the rest for us, it will choose wisely the implementation that fits with all the characteristic required and it will inject the services implementation when it's need.
* Event Producers and Observers
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
and: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
As you can see a simple and out of the box (and defined by an specification) Event mechanism is provided, allowing us to keep our Event Producers completely Decoupled from our Event Observers. We can also configure the obsevers to be instantiated by teh CDI container or we can decide how many instances of our observer do we need for a particular use case.
* Decorators/Interceptors:
We can use both to improve a specific technical or business policy should be applied to the execution of our service methods.
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
Decorators and Interceptors can be enabled and disabled based on configurations, which give us once again a great flexibility to add or remove things based on what we want to achieve.
At the end of the day we have a set of services which can leverage the power of the CDI container. We can also hide that we are using CDI/Weld (weld is the implementation of the CDI interfaces/spec), look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
We can use it internally and if the user wants to get access to the container he/she can.
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-5-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-5...
All the proposed services are simple POJOs which can contain references to all the other services. We can combine them to achive different functionality.
For a more detailed description about each service you can look at: https://community.jboss.org/docs/DOC-18641 https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal
The next section describe more advantages about using the CDI/Weld proposed programming model to keep our services simple and take out all the code that is not related with Human Interaction logic.
h1. Services Working Together
The following image shows how the interactions with the human task module will happen. The diagram shows the interfaces and implementations required to interact with a TaskInstance
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-5-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-5...
The previous figure shows all the components interacting when we want to interact with a task instance that was already created.
So let's say for example that we want to start a task. From the client perspective he/she can use the TaskServiceEntryPoint to
start the task. This TaskServiceEntryPoint will delegate the calls to the different service implementations. In this case if we are
starting a task the TaskInstanceService implementation will delegate the action to the LifeCycleManager. As you can see
the LifeCycleManager, no matter the implementation is being decorated by an UserGroupDecorator which in charge of handling the
resolution of the identities associated with the operation. The LifeCycleManager is also an Event Producer, which means that is in charge
of generating events to communicate to the external world the LifeCycle changes of each task. We can then attach external listeners to
Observer these events to audit what is happening or as callback mechanisms to execute actions when a task is completed for example.
Classes and Interfaces to look at this point:
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
No magic, no complicated debug sessions, the services should be as straight forward as possible trying to following the sequence:
*TaskServiceEntryPoint ---(Delegate)--> Task*ServiceImpl -> Storage*
h3. Shared Persistence Context and Transactional Behavior
If you take a look at the previous links you will notice that all the Services, for example TaskInstanceServiceImpl and TaskDefServiceImpl are all using an Inject EntityManager.
And there is no code related with transactions or loading and merging detached entities (em.getTransaction(), ut.begin(), em.merge()).
The EntityManager that is being injected is being managed by Seam Persistence (ASL 2.0) ( http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html_single/ http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html_single/) which give us a transparent
way of having all the advantages of the unified programming model of being in Managed and Transaction Persistence Context without the hassle of taking care of how to share different
instances of an EntityManager or demarcate the transactions based on what is available in our context. Seam Persistence provide us a declarative way to deal with all this topics, and take all the code
related with these tasks out of the Human Task Module. This also give us the possibility to integrate with Spring only configuring our environment and not changing our code
( http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html)
h1. Integration with the Outside World
Using CDI for the integration perspective is just great. Most of the integration frameworks out there have CDI integration which make exposing our services extremely easy and natural.
I've created an experiment showing how we can do this with Switchyard/Camel, and most of this principles can be used for the Process/Rule engine as well:
https://github.com/Salaboy/human-task-poc-proposal/tree/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/tree/master/human-task...
The main focus of this project is to contain all the integration configuration required to expose our POJO services using different transports. I've being focused on JMS because it will allow
us to have asynchronous interactions transparently.
The following figure shows us teh Switchyard Declarative configuration which is using our CDI POJO services to define the integration points:
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-5-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-5...
The previous diagram is showing the following interaction and integration points:
1. A client sending a JMS message wants to start a task
2. The Switchyard container is exposing a JMS queue which is expecting "Action" messages
3. As soon as we get one of this action messages, Switchyard picks the message and propagate it to the correspondant service
4. We can register a listener that will observe the events being fired by our components (i.e. TaskLifeCycleEvents)
5. As soon as one of these events is observed by our listener it will be redirected to a JMS topic which can contain multiple subscribers
6. Any number of subscribers can pick up the message and do what they want with it
More info: https://community.jboss.org/docs/DOC-18719 https://community.jboss.org/wiki/HumanTaskModuleSwitchYardIntegration
NOTE: An Executor component can be used to pick the up the notification and execute callbacks. I'm right now creating a document which explains how this component can be used.
This idea perfectly fits in this scenario. I will add the link as soon as the document is ready.
Cool Facts:
1. This experiment is just showing one of the possibilities of using Switchyard and the camel integration for handling async interactions in a very efficient way, without including code inside the Human Task Module. We are delegating all the interaction points to the Integration framework instead of adding complexity to the Human Task Logic.
2. We can integrate with any transport in the same way and we can mix and match what we want. For example, we can recieve a REST call and send notifications via JMS
3. Switchyard and all the services can run inside a SE or EE environment (because of CDI and its programming model)
4. Is all based on configuration, so we can provide a set of well known configurations and let the users to customize that if they want
5. Quartz for reminders, cron tasks and all of that comes for free
6. Push us to use a clean programming model, leverage all the CDI features
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18789]
Create a new document in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 8 months
[jBPM] - Human Task Module Refactoring
by Mauricio Salatino
Mauricio Salatino [https://community.jboss.org/people/salaboy21] modified the document:
"Human Task Module Refactoring"
To view the document, visit: https://community.jboss.org/docs/DOC-18789
--------------------------------------------------------------
This document aims to explain how the human task module should look after applying some refactorings which were the results of several experiments.
You can more about this experiments here: https://github.com/Salaboy/human-task-poc-proposal https://github.com/Salaboy/human-task-poc-proposal
The following sections describe how the module will look like after the refactorings
h1. APIs and Service Structure
All the Services Proposed by this refactoring are CDI managed beans. For the ones not familiar with CDI, you need to think about it as JPA for Dependency Injection frameworks. So we can say
that CDI is to Spring/Guice/Weld what JPA is to Hibernate/Top Link. CDI propose some very cool out of the box features that we definitely want to use to make our services more clear, robust, easy to maintain. Some of the things provided by CDI that I'm using in the experiments are:
* Configuration based on annotations: We can inject services instances without needing to specify the implementation, so we keep it pluggable and decoupled all the time.
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
As you can see there, we can define at service level which characteristic the service implementation will need to be injected inside a service, but then we can provide several alternatives
for that implementation and configure them for different environments. The CDI container will do the rest for us, it will choose wisely the implementation that fits with all the characteristic required and it will inject the services implementation when it's need.
* Event Producers and Observers
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
and: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
As you can see a simple and out of the box (and defined by an specification) Event mechanism is provided, allowing us to keep our Event Producers completely Decoupled from our Event Observers. We can also configure the obsevers to be instantiated by teh CDI container or we can decide how many instances of our observer do we need for a particular use case.
* Decorators/Interceptors:
We can use both to improve a specific technical or business policy should be applied to the execution of our service methods.
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
Decorators and Interceptors can be enabled and disabled based on configurations, which give us once again a great flexibility to add or remove things based on what we want to achieve.
At the end of the day we have a set of services which can leverage the power of the CDI container. We can also hide that we are using CDI/Weld (weld is the implementation of the CDI interfaces/spec), look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
We can use it internally and if the user wants to get access to the container he/she can.
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-3-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-3...
All the proposed services are simple POJOs which can contain references to all the other services. We can combine them to achive different functionality.
For a more detailed description about each service you can look at:
The next section describe more advantages about using the CDI/Weld proposed programming model to keep our services simple and take out all the code that is not related with Human Interaction logic.
h1. Services Working Together
The following image shows how the interactions with the human task module will happen. The diagram shows the interfaces and implementations required to interact with a TaskInstance
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-3-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-3...
The previous figure shows all the components interacting when we want to interact with a task instance that was already created.
So let's say for example that we want to start a task. From the client perspective he/she can use the TaskServiceEntryPoint to
start the task. This TaskServiceEntryPoint will delegate the calls to the different service implementations. In this case if we are
starting a task the TaskInstanceService implementation will delegate the action to the LifeCycleManager. As you can see
the LifeCycleManager, no matter the implementation is being decorated by an UserGroupDecorator which in charge of handling the
resolution of the identities associated with the operation. The LifeCycleManager is also an Event Producer, which means that is in charge
of generating events to communicate to the external world the LifeCycle changes of each task. We can then attach external listeners to
Observer these events to audit what is happening or as callback mechanisms to execute actions when a task is completed for example.
Classes and Interfaces to look at this point:
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
No magic, no complicated debug sessions, the services should be as straight forward as possible trying to following the sequence:
*TaskServiceEntryPoint ---(Delegate)--> Task*ServiceImpl -> Storage*
h3. Shared Persistence Context and Transactional Behavior
If you take a look at the previous links you will notice that all the Services, for example TaskInstanceServiceImpl and TaskDefServiceImpl are all using an Inject EntityManager.
And there is no code related with transactions or loading and merging detached entities (em.getTransaction(), ut.begin(), em.merge()).
The EntityManager that is being injected is being managed by Seam Persistence (ASL 2.0) ( http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html_single/ http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html_single/) which give us a transparent
way of having all the advantages of the unified programming model of being in Managed and Transaction Persistence Context without the hassle of taking care of how to share different
instances of an EntityManager or demarcate the transactions based on what is available in our context. Seam Persistence provide us a declarative way to deal with all this topics, and take all the code
related with these tasks out of the Human Task Module. This also give us the possibility to integrate with Spring only configuring our environment and not changing our code
( http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html)
h1. Integration with the Outside World
Using CDI for the integration perspective is just great. Most of the integration frameworks out there have CDI integration which make exposing our services extremely easy and natural.
I've created an experiment showing how we can do this with Switchyard/Camel, and most of this principles can be used for the Process/Rule engine as well:
https://github.com/Salaboy/human-task-poc-proposal/tree/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/tree/master/human-task...
The main focus of this project is to contain all the integration configuration required to expose our POJO services using different transports. I've being focused on JMS because it will allow
us to have asynchronous interactions transparently.
The following figure shows us teh Switchyard Declarative configuration which is using our CDI POJO services to define the integration points:
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-3-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-3...
The previous diagram is showing the following interaction and integration points:
1. A client sending a JMS message wants to start a task
2. The Switchyard container is exposing a JMS queue which is expecting "Action" messages
3. As soon as we get one of this action messages, Switchyard picks the message and propagate it to the correspondant service
4. We can register a listener that will observe the events being fired by our components (i.e. TaskLifeCycleEvents)
5. As soon as one of these events is observed by our listener it will be redirected to a JMS topic which can contain multiple subscribers
6. Any number of subscribers can pick up the message and do what they want with it
Cool Facts:
1. This experiment is just showing one of the possibilities of using Switchyard and the camel integration for handling async interactions in a very efficient way, without including code inside the Human Task Module. We are delegating all the interaction points to the Integration framework instead of adding complexity to the Human Task Logic.
2. We can integrate with any transport in the same way and we can mix and match what we want. For example, we can recieve a REST call and send notifications via JMS
3. Switchyard and all the services can run inside a SE or EE environment (because of CDI and its programming model)
4. Is all based on configuration, so we can provide a set of well known configurations and let the users to customize that if they want
5. Quartz for reminders, cron tasks and all of that comes for free
6. Push us to use a clean programming model, leverage all the CDI features
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18789]
Create a new document in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 8 months
