[JBoss jBPM] - Re: Intalio vs jBPM
by swatis
BA with less technical knowledge but more of functional knowledge try to map business requirements into process model.
Technical guy deals with technical aspects of process like integration with other applications.
Intalio uses BPMN as process modeling language. got 52 BPMN notations (standard). When Intalio designer deploys process on the server it deploys as "BPEL" process.
If anyone has taken look at intalio, will understand how complex this tool has become by making it BA friendly. Error Resolving is difficult task. User Interface its not at all satisfactory. Integration with other open source products like "Liferay portal for UI" is needed to have better look and feel.
Data Mapper given but its complex to understand that BA will prefer to write Database adapter himself. :)...
Again the workflow form designer is again the same case.
What you can say overall is "Intalio Designer" has made process modeling easier task but it consumes lot of time to understand that designer itself. whereas jbpm xml is quite easy to read and understand.
One more advantage over Intalio jbpm has, is JPDL can be created by using any XML editor. To understand 52 BPMN notations in terms of XML tags is not that easy. SO you need to have "Intalio Designer" to design process.
Customization in JBPM is easy; having advantage over Intalio.
Web services can easily be created using Axis API So not a big deal.
And one more thing you can always create custom nodes in jBPM. Tell your BA about your custom nodes and put in JPDL while modeling process. (one time effort but worth of it). Create db node, email node, web service node and just tell BA to use it... its not that difficult to modify XML file.
jBPM
ï¼ Database query can be done through developer no component available
ï¼ Needs to develop separate forms and then deploy
ï¼ Swimlanes are present but cannot visualize them.
ï¼ symbols present are 10
ï¼ More developer centric. Control is given to developers
ï¼ Business rule management strong support. Drool or JBoss Rules.
ï¼ Again no BPMN standards. Own PDL.
ï¼ BAM (Business Activity Monitoring) for available but not to great extent
Intalio
ï¼ Db component is present but requires lots of configuration, mappings, xml schema elements and so on
ï¼ No need to create separately and then deploy.
ï¼ Symbols present are 52 out of which 12 are used.
ï¼ Import Support for ArisXML, BPEL.
ï¼ Integrated with OpenLexicon rule engine needs to install separately. Drools based.
ï¼ In platinum and gold versions BAM is present.
ï¼ Poor version controlling in both
ï¼ Easy LDAP Support
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246597#4246597
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246597
17 years, 1 month
[EJB/JBoss] - Re: PostConstruct loadClass fails when porting to JBoss 5
by jcstaff2
I understand where your caution comes from about the ClassLoader after reading the spec, but when I read the Javadoc on getClass().getResource(), it sounds like it too is locating the ClassLoader. When I did some searching, I found that Tom Marrs (Lead Author, JBoss at Work: A Practical Guide) had the same solution as I did as late as 2006. http://www.coderanch.com/t/89900/JBoss/reading-properties-file
I spent the last few days building up a simple set of test cases where I loaded classes and resources from different types of ClassLoaders both inside and outside the EJB. In my simple test case, I could not recreate the problem. I finally tracked the issue down to the deployment descriptor. The JBoss 5 parsing of the deployment descriptor elements seems to now include white-space characters into values.
My class looked like the following...
| @Stateless
| public class TellerEJB implements TellerLocal, TellerRemote {
| ...
| @Resource(name="daoClass")
| protected String daoClassName;
|
| @PostConstruct
| public void init() {
| log.debug("init(), daoClass=" + daoClassName);
| teller = new TellerImpl();
|
| try {
| AccountDAO dao = (AccountDAO)Thread.currentThread()
| .getContextClassLoader()
| .loadClass(daoClassName)
| .newInstance();
|
My deployment descriptor was written as follows
| ...
| <enterprise-beans>
| <session>
| <ejb-name>TellerEJB</ejb-name>
| <env-entry>
| <env-entry-name>daoClass</env-entry-name>
| <env-entry-type>java.lang.String</env-entry-type>
| <env-entry-value>xxx.jpa.JPAAccountDAO
| </env-entry-value>
| </env-entry>
| </session>
| </enterprise-beans>
| </ejb-jar>
|
Note the line break after ...DAO and the line break in the original debug output. Once I removed the white-space from the deployment descriptor all worked.
| <enterprise-beans>
| <session>
| <ejb-name>TellerEJB</ejb-name>
| <env-entry>
| <env-entry-name>daoClass</env-entry-name>
| <env-entry-type>java.lang.String</env-entry-type>
| <env-entry-value>xxx.jpa.JPAAccountDAO</env-entry-value>
| </env-entry>
| </session>
| </enterprise-beans>
|
I've seen this same type of problem elsewhere in the processing of deployment descriptors by JBoss 5. In one post I saw where adding export JAVA_OPTS="-Dxb.builder.useUnorderedSequence=true" to the startup corrected the issue. I have not yet tried that for this issue.
So, in short. I may be violating what you think is wrong with my use of Thread.currentThread().getContextClassLoader(). However the problem in porting from JBoss 4 to JBoss 5 ended up being a whitespace interpretation change of the ejb-jar.xml between the two versions. JBoss 5 is adding extra whitespace to the injected String variable.
Thoughts?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246592#4246592
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246592
17 years, 1 month