October 2008 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: slf4j linking error ?

by thomas.diesler＠jboss.com

This is the 'mvn dependency:tree' I used to run the test | [INFO] ------------------------------------------------------------------------ | [INFO] Building JBoss jBPM3 - Core | [INFO] task-segment: [dependency:tree] | [INFO] ------------------------------------------------------------------------ | [INFO] [dependency:tree] | [INFO] org.jbpm.jbpm3:jbpm-core:jar:3.3.0-SNAPSHOT | [INFO] +- bsh:bsh:jar:1.3.0:compile | [INFO] +- commons-logging:commons-logging:jar:1.1.1:compile | [INFO] +- dom4j:dom4j:jar:1.6.1:compile | [INFO] +- javax.jcr:jcr:jar:1.0.1:provided | [INFO] +- javax.mail:mail:jar:1.4:provided | [INFO] | \- javax.activation:activation:jar:1.1:provided | [INFO] +- javax.servlet:servlet-api:jar:2.5:provided | [INFO] +- junit:junit:jar:3.8.1:compile | [INFO] +- org.apache.ant:ant:jar:1.7.0:compile | [INFO] | \- org.apache.ant:ant-launcher:jar:1.7.0:compile | [INFO] +- org.apache.jackrabbit:jackrabbit-core:jar:1.4.5:compile | [INFO] | +- concurrent:concurrent:jar:1.3.4:compile | [INFO] | +- commons-collections:commons-collections:jar:3.1:compile | [INFO] | +- org.apache.jackrabbit:jackrabbit-api:jar:1.4:compile | [INFO] | +- org.apache.jackrabbit:jackrabbit-jcr-commons:jar:1.4:compile | [INFO] | +- org.apache.jackrabbit:jackrabbit-spi-commons:jar:1.4:compile | [INFO] | +- org.apache.jackrabbit:jackrabbit-spi:jar:1.4:compile | [INFO] | +- org.apache.jackrabbit:jackrabbit-text-extractors:jar:1.4:compile | [INFO] | | +- org.apache.poi:poi:jar:3.0.2-FINAL:compile | [INFO] | | +- pdfbox:pdfbox:jar:0.6.4:compile | [INFO] | | +- org.textmining:tm-extractors:jar:0.4:compile | [INFO] | | +- nekohtml:nekohtml:jar:0.9.4:compile | [INFO] | | \- xerces:xercesImpl:jar:2.6.2:compile | [INFO] | | \- xml-apis:xml-apis:jar:1.3.02:compile | [INFO] | +- org.apache.lucene:lucene-core:jar:2.2.0:compile | [INFO] | \- org.apache.derby:derby:jar:10.2.1.6:compile | [INFO] +- org.hibernate:hibernate:jar:3.2.6.ga:compile | [INFO] | +- net.sf.ehcache:ehcache:jar:1.2.3:compile | [INFO] | +- javax.transaction:jta:jar:1.0.1B:compile | [INFO] | +- asm:asm-attrs:jar:1.5.3:compile | [INFO] | +- antlr:antlr:jar:2.7.6:compile | [INFO] | +- cglib:cglib:jar:2.1_3:compile | [INFO] | \- asm:asm:jar:1.5.3:compile | [INFO] +- org.slf4j:slf4j-api:jar:1.5.5:compile | [INFO] +- dumbster:dumbster:jar:1.6:test | [INFO] +- jaxen:jaxen:jar:1.1.1:test | [INFO] | +- jdom:jdom:jar:1.0:test | [INFO] | \- xom:xom:jar:1.0:test | [INFO] | +- xerces:xmlParserAPIs:jar:2.6.2:test | [INFO] | +- xalan:xalan:jar:2.6.0:test | [INFO] | \- com.ibm.icu:icu4j:jar:2.6.1:test | [INFO] +- org.slf4j:slf4j-log4j12:jar:1.5.5:test | [INFO] +- hsqldb:hsqldb:jar:1.8.0.7:test | [INFO] \- log4j:log4j:jar:1.2.14:test (scope not updated to runtime) | [INFO] ------------------------------------------------------------------------ | [INFO] BUILD SUCCESSFUL | [INFO] ------------------------------------------------------------------------ | Note, it uses sl4j-1.5.5 | [tdiesler@tdvaio trunk]$ svn log -v -r2585 | ------------------------------------------------------------------------ | r2585 | thomas.diesler(a)jboss.com | 2008-10-22 16:09:27 +0200 (Wed, 22 Oct 2008) | 1 line | Changed paths: | M /jbpm3/trunk/modules/core/pom.xml | M /jbpm3/trunk/pom.xml | | [JBPM-1720] update to sl4j-1.5.5 | With sl4j-1.5.5 in place the issue does not show any more - for me. Also see https://jira.jboss.org/jira/browse/JBPM-1720 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183889#4183889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183889

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: slf4j linking error ?

by tom.baeyens＠jboss.com

found this anonymous wrote : I was having the same problem and I solved it by downloading an older | version of slf4j. | | | the version of slf4j-api shipped with hibernate is 1.5.2 (lib/common/ | slf4j-1.5.2.jar) | | I downloaded the same version of slf4j from here: http://www.slf4j.org/dist/ | and the problem is gone. | here: http://www.velocityreviews.com/forums/t635509-hibernate-tutorial-problem.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183885#4183885 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183885

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - slf4j linking error ?

by tom.baeyens＠jboss.com

I'm going to fix the JcrDbTest. This is the exception it currently generates: Did anyone see such a problem before? It seems like a library incompatibility problem to me between slf4j and log4j. java.lang.NoSuchFieldError: name | at org.slf4j.impl.Log4jLoggerAdapter.<init>(Log4jLoggerAdapter.java:75) | at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:75) | at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:92) | at org.apache.jackrabbit.core.config.RepositoryConfig.<clinit>(RepositoryConfig.java:64) | at org.jbpm.jcr.jackrabbit.JackrabbitJcrServiceFactory.getRepository(JackrabbitJcrServiceFactory.java:48) | at org.jbpm.jcr.impl.AbstractJcrServiceFactory.openService(AbstractJcrServiceFactory.java:46) | at org.jbpm.svc.Services.getService(Services.java:156) | at org.jbpm.jcr.JcrDbTest.testJcrNodeStorageAndRetrieval(JcrDbTest.java:55) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at junit.framework.TestCase.runTest(TestCase.java:154) | at org.jbpm.AbstractJbpmTestCase.runTest(AbstractJbpmTestCase.java:57) | at junit.framework.TestCase.runBare(TestCase.java:127) | at junit.framework.TestResult$1.protect(TestResult.java:106) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.framework.TestResult.run(TestResult.java:109) | at junit.framework.TestCase.run(TestCase.java:118) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | at junit.framework.TestSuite.run(TestSuite.java:203) | at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) | at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) | at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183883#4183883 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183883

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Future of jBPM???

by tom.baeyens＠jboss.com

jBPM is going full speed. We are addressing crucial productization issues under the hood. Like optimizing persistence, how do you bind the process persistence into your transaction (whatever Java environment you're running on), how to extract the communalities between different forms of BPM in a Process Virtual Machine library. That has taken some time and now this work will be available soon. I regret that the drools guys put so much effort in duplication. We have had a couple of meetings on this topic. But we couldn't come to a joint PVM strategy yet. Hopefully that will still happen. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183770#4183770 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183770

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Expression Evaluation in ActionHandler Properties

by kukeltje

I think it is even more widely an interesting subject. Currently only part of the attributes are accept EL, not all of them. This confuses people from time to time. I'll add this to the meeting context View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183760#4183760 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183760

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Expression Evaluation in ActionHandler Properties

by alex.guizar＠jboss.com

>From a SF developer's perspective, something like Sales-#{market} should evaluate to something like "Sales-London". If the JbpmExpressionEvaluator does not do it, then it probably should. This change could go in jBPM 3.3.0, tough we'd have to discuss the consequences. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183697#4183697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183697

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Future of jBPM???

by koen.aers＠jboss.com

"keith" wrote : Also, will jBPM 3.5 or 4.0 move to Eclipse 3.4 from a tooling perspective? The latest release (3.1.4) of the GPD has been build and tested on Eclipse 3.4. Did you experience any problem with it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183676#4183676 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183676

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Future of jBPM???

by jbarrez

jBPM has wait states,human tasks, etc. for a very long long time now. In fact the concept of 'long running processes' is based upon this 'waiting'. I can assure you that the jBPM designers are constantly trying to build a better product. The last months were invested in reserch & design fo building jBPM, so that's why one would get the perception of idleness. But don't worry, we will al see signs of these investments in the coming months. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183655#4183655 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183655

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Future of jBPM???

by keithnielsen

I have been researching both jBPM and Drools for sometime now and am wondering what the future holds for jBPM. This is based on my research of Drools 5, which is bringing what I would consider more BPM constructs into the core engine, things such as Wait States, Human Tasks, etc. One of the main things I don't see yet is the whole persistence and support of long running processes. My question is will the trend with Drools continue, eventually consuming jBPM? I must say that my perception is that Drools is more active which makes me wonder if I should go with Drools hoping that it builds out more BPM features going forward. Also, will jBPM 3.5 or 4.0 move to Eclipse 3.4 from a tooling perspective? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183648#4183648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183648

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - fixed ProcessStateDbTest

by tom.baeyens＠jboss.com

it only took me a week. the weirdest sequence of phenomena that i ever saw. eventually one of the obstacles in finding the problem was that the database returned a list sorted on a timestamp. in most cases that gives a precise order... unless when the multiple process instances have a start date within the same millisecond. in that case, the order becomes random. along the way i tried to upgrade hibernate. (i won't commit those changes) but i want to mention that doing so was very hard. it seems we cannot rely on the automagical third party dependency resolution in mvn. i assume that the dependencies are not always correctly specified in the public repositories. also i saw way too many dependencies. this was really frustrating when cleaning the repo. it took me 1 hour to rebuild the repo. And during that one hour, i couldn't do anything else because once and the while a jar wasn't found in a public repo and I just had to retry. maybe we should consider to have our own maven repo for our dependencies. this is considered good practice with ivy. having a single repo for all of jboss is good, but making sure that all the 3rd party dependency resolutions happer correctly might be easier if we have full control. i'll add this as a topic to discuss on the meeting. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183419#4183419 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183419

17 years, 5 months

4
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev October 2008