Re: [jbpm-dev] [rules-dev] Drools 5.5.0.beta1 \ jBPM 5.4.0.beta1
by Michael Anstis
Hello,
FYI, once the Designer-Guvnor REST issue is resolved I will be pulling from
remote\master and re-start 5.5.0.Beta1\5.4.0.Beta1.
Therefore, any changes pushed to remote\master will now be in 5.5.0.Beta1.
Please be sure to update the N&N accordingly (if applicable).
CC'ed jBPM-DEV for information.
With kind regards,
Mike
On 14 September 2012 21:10, Michael Anstis <michael.anstis(a)gmail.com> wrote:
> Hi,
>
> 5.5.0.Beta1 has been blocked due to interoperability issues between jBPM
> Designer, jBPM Console and Guvnor.
>
> Once the issues have been addressed I will re-start release of 5.5.0.Beta1
> next week.
>
> With kind regards,
>
> Mike
>
>
> On 13 September 2012 20:33, Michael Anstis <michael.anstis(a)gmail.com>wrote:
>
>> Hi,
>>
>> Everything builds OK here and sanity checks look good.
>>
>> I will complete the POM changes (to 5.5.0.Beta1), tags and move to
>> 5.5.0-SNAPSHOT tomorrow.
>>
>> If everything goes well release should be completed tomorrow.
>>
>> With kind regards,
>>
>> Mike
>>
>>
>> On 13 September 2012 15:31, Michael Anstis <michael.anstis(a)gmail.com>wrote:
>>
>>> Simple Rule Template Example
>>> - Fixed on master (to be 5.5.0.Beta1) and 5.4.x branches.
>>>
>>>
>>> On 13 September 2012 15:00, Mario Fusco <mario.fusco(a)gmail.com> wrote:
>>>
>>>> I will give a quick look at the drools-distribution issues.
>>>>
>>>>
>>>> On Thu, Sep 13, 2012 at 3:55 PM, Michael Anstis <
>>>> michael.anstis(a)gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> 5.5.x has been built locally, and sanity checks completed.
>>>>>
>>>>> The following issues were observed:-
>>>>>
>>>>> drools-distribution-5.5.0-SNAPSHOT
>>>>> Text adventure
>>>>> - Shows invalid command errors
>>>>>
>>>>> Simple Rule Template Example
>>>>> - Caused by: java.io.FileNotFoundException:
>>>>> 'org/drools/examples/templates/Cheese.drt' cannot be opened because it does
>>>>> not exist
>>>>>
>>>>> drools-planner-distribution-5.5.0-SNAPSHOT
>>>>> Hospital Bed Planning
>>>>> - Rows are too tall to see anything (is this an issue, you want to
>>>>> fix?)
>>>>>
>>>>> Guvnor
>>>>> Test
>>>>> org.drools.guvnor.server.jaxrs.BasicPackageResourceIntegrationTest.testBasicAuthenticationInvalidPassword
>>>>> fails on Jenkins but is successful locally.
>>>>>
>>>>>
>>>>> Anybody want to fix these before we proceed?
>>>>>
>>>>> Otherwise all looks good to go.
>>>>>
>>>>> With kind regards,
>>>>>
>>>>> Mike
>>>>>
>>>>> On 6 September 2012 11:27, Mario Fusco <mario.fusco(a)gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>> - Do we need a new MVEL version?
>>>>>>>
>>>>>>> At the moment there isn't any known issue/bug related with MVEL, so
>>>>>> the last stable release (2.1.1.Final) should be fine.
>>>>>>
>>>>>> Mario
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> rules-dev mailing list
>>>>>> rules-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rules-dev mailing list
>>>>> rules-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> rules-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>
>>>
>>
>
11 years, 6 months
Help with ht problem? (Re: BZ 853019)
by Marco Rietveld
Hi Maciej and Mauricio,
I'm struggling to find a good solution for a problem and was hoping to
get your advice about the following.
The human-task service uses it's entities as DTO's, namely the Task
class/instances.
However, we use Hibernate, which uses lazy-loading, which means that
Hibernate substitutes proxy instances in collections until the actual
collection elements are needed.
With Hibernate 3, we miraculously were able to avoid any large problems.
However, testing with EAP 6 has uncovered situations, primarily with
postgresql, in which this strategy (entity as DTO) just won't work.
The problem is that even if all the "persistence" work is done in one
tx, the collections are still lazily-loaded. That means if a task
service operation has to return a Task instance, that the serialization
of the Task object (when it's being sent) triggers the loading of
entities. Due to postgresql's Large Object facility, this means that
there needs to be a transaction around this action. Because we don't
surround the session.write(resultsCmnd); operation with a tx, we get an
exception.
(To tell the truth, I don't understand why this worked with Hibernate 3.. )
As I've been writing this, I've come up with a couple of solutions:
1. Turn off lazy-loading for all entities.
2. Force the loading of all relevant entities by going through the
object tree (task.getPeopleAssignments().size(), etc.. )
3. Put a transaction around session.write(resultsCmnd);
Option 1 has a big impact on performance, especially if we start talking
about high-volumes.
Option 2 has a slightly larger impact on performance but Option 3 seems
a little bit ugly to me.
Are there any options I missed? Any advice or comments?
Thanks,
Marco
PS. This is (IMHO) one of the reasons we need to rewrite human-task.
I've been working on a proposal/POC, but the important thing is that
certain problems that we have now aren't also present in the rewritten
version.
--
jBPM/Drools developer
Utrecht, the Netherlands
11 years, 7 months
Catching exceptions in jbpm 5
by Giovanni Marigi
Hi,
my question is about catching error events in jbpm 5.x
Watching the examples and reading the docs it looks like I can define a
<boundaryEvent> only inside a SubProcess <subprocess>
Is this a limitation? Does it mean I can't define a <boundaryEvent> in a
process?
How to handle exceptions (for example jbpm exception) in a process
without using a boundaryEvent?
Thanks,
Giovanni
--
Giovanni Marigi
Red Hat - JBoss Consultant -
email: gmarigi(a)redhat.com
Mobile: +39 3423175986
Office: +39 0687502315
Red Hat Italy
Via Andrea Doria 41m
00192 Roma - Italy
www.redhat.com
Prima di stampare, pensa all'ambiente ** Think about the environment before printing
11 years, 7 months
