On 17/12/13 09:25, John Shooab wrote:
Hello Cristiano,

We have to agree with you. That factory approach is really a "point of risk" for osgi !

We had problems with hibernate too and we use Open JPA plus Aries JPA.
so you know what I'm talking about... :)


but you told me that there are people using drools with blueprint.  but they wouldn't get into same problems too?
well, what I know is that blueprint is based on heavy spring stuffs... and there are always some magic with spring :)
I saw that there are some examples with karaf and spring, maybe you could have a try...

have you talked about this with the drools/jbpm teams ?
yep, the best answer that I had was "we don't have payable customer that is using osgi" !


do you mind if I contact you personally ?
ok


thanks,

John

On 16/12/13 12:31, Cristiano Gavião wrote:
John,

I've passed sometime evaluating 6.x for equinox some months ago. We end up given up to use it in current project because we found lot of these classloading issues in that time. almost all examples failed to run as is...

I heard that some guys could setup JBPM fine (just a couple of smoke tests was done, actually) using blueprint. but as I think blueprint is too much heavy for my needs (I use DS instead) I didn't take a look, yet...

Just to anticipate your team, the major problem that identified was the Factory architecture being used by Drools, Kie and etc. They was planned to work with java SE flat classpaths... in they world, developer just need to put the needed jar in a place where java could find it... but we know that is not the reality in the OSGi world.

Take a look on this KieServices class [1]. that is one of the most used class that I could see in the examples provided by drools.

Observe that this class exists in bundle Kie-API and in the line 165 will try to instantiate another class that exists in the " org.drools.compiler" bundle and worst, using Class.forName(). 
You will find sentences like this everywhere in source code... And you won't see any integration tests for each of them...

As you could note, this breaks OSGi modular concept, and could be the origin of the classloading issues your team are facing...

I heard that some people could "bypass" those errors patching the manifest generation for :
A)  to add an import package from the Implementation bundle inside the API bundle ! :(  that is crap
B)  or to add a Dynamic Import-Package [2].

I had negative experiences with Dynamic Import-Package when I tried to use Hibernate in OSGi many year ago (too many issues that we lost confidence and moved to gemini + eclipselink). So, I'm in skeptical with its use in Drools/JBPM 6, too.

One solution would be the use of JDK's ServiceLoader api [3] and the SPI spec in osgi side, but I have doubts that the team would buy for this route... :)

anyway, good luck and let us know about your team experiments.


[1] - https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/master/kie-api/src/main/java/org/kie/api/KieServices.java#L165
[2] - http://keheliya.blogspot.com.br/2013/02/use-of-dynamicimport-package-in-osgi.html
[3] - http://docs.oracle.com/javase/tutorial/ext/basics/spi.html#the-serviceloader-class)

best regards,

Cristiano

On 16/12/13 10:10, John Shooab wrote:
Hi Mauricio,

I could see that many issues were resolved in Drools and JBPM Jira, that is really good.

The system environment where we plan to use JBPM is Equinox. So, what concerned we most are the issues that wasn't raised yet related running 6.x into OSGi.

In one entire day one of my team members wasn't able to make it run. I can't specify the problems right now because he got out for vacation without pass me the report file. But seems that it was related to classloading issues...

I asked to someone to repeat his procedure this week again and we will raise the issues, if necessary...

regards,

John

On 16/12/13 09:22, Mauricio Salatino wrote:
HI John,
If you can highlight which issues that you see there are important to you please let us know. We are still cleaning Jira for the last release so some of them are already fixed or not relevant.
Cheers


On Mon, Dec 16, 2013 at 1:15 PM, John Shooab <jshooab@gmail.com> wrote:
Hi Alexandre,

looking the number of issues since 6.0.0.Final at Jira, for us seems
that the release of Drools and Jbpm 6.0.0.Final.
was a kind precipitated...

We decided to postpone our prototype with 6.0.x for while...

thanks anyway,

John

On 14/12/13 09:33, Alexandre Porcelli wrote:
> Binaries were released, but we're still working on communication (new web site, new tutorials, videos, etc...)
>
> But if you check http://www.jboss.org/jbpm Documentation or Downloads sections there are references to new release.
>
>
> Regards,
> ---
> Alexandre Porcelli
> Principal Software Engineer
> Red Hat Business Systems and Intelligence Group
>
>
> On Dec 13, 2013, at 6:38 PM, John Shooab <jshooab@gmail.com> wrote:
>
>> Hello,
>>
>> I am in charge to investigate new JBPM and Drools 6 status.
>>
>> I should say that I'm kind confuse.
>>
>> Looking at maven central, already have 6.0.0.Final artifacts: http://search.maven.org/#artifactdetails%7Corg.jbpm%7Cjbpm%7C6.0.0.Final%7Cpom
>>
>> But looking at http://www.jboss.org/jbpm/ there are any reference to 6.0.0 !
>>
>>
>> looking at jira here (https://issues.jboss.org/browse/JBPM) I could see the 6.0.0.Final was release, but there are 3 different versions:jBPM 6.1.0.Final, jBPM 6.0.1.Final and jBPM 6.x !!!
>>
>> could someone explain me that ?
>>
>> which version should I track in jira? which source branch is the one that I should clone if I need to see the examples?
>>
>> thanks,
>>
>> John.
>> _______________________________________________
>> jbpm-dev mailing list
>> jbpm-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>

_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev



--
 - MyJourney @ http://salaboy.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar
 
 - Salatino "Salaboy" Mauricio -




_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev



_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev