June 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: Thinking about transition attrs

by brittm

anonymous wrote : Consistency should be in the api. It should hide the underlying implementation (be it DB or file or whatever). Good clarification. Though I would suggest that jBPM developers might enjoy a consistent implementation as well. Is there a reason that namespaces couldn't be stored in a 'user table' just as well? Something like *id,jpdlElementId,namespace,tagName,value*? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054520#4054520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054520

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Refactoring access to JBPM database

by rjoachim

I agrre with you that only JPA is a considerable target for another persistence provider integrated with JBPM. But even if I agree with you on that I need to implement support for another provider. What I intend to contribut is only the refactoring of JBPM to allow implementation of adaption layers to different persistence providers. What I have in mind is to move all code that interacts with a persistence provider into the Session classes (e.g. GraphSession) in org.jbpm.db package. Having said that there are still some references to Hybernate classes that i do not have an idea yet how this could be achived (e.g. org.jbpm.persistence). As a second step the Session classes could be converted to interfaces with Hybernate specific implementations. It still need to be discussed how that implementations are instantiated but propably a factory would be a good idea. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054519#4054519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054519

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - hiding portlet.

by linmiss

hello , Please tell me how can I hide a portlet in jboss poral. thanks a lot. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054515#4054515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054515

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JORAM-tests.jar is missing test.properties

by clebert.suconic＠jboss.com

This is part of the integration work with JBAS I'm doing. I'm working on migrating JORAM Tests as integration on Branch_4_X on my local copy... and replacing JBossMQ by JBossMessaging on 4_X, and I realized that joram-tests.jar are missing test.properties. http://repository.jboss.com/objectweb-joramtests/1.3/lib/joramtests.jar This was caused because joram tests are now built with maven, the properties copy is not working there. I don't know nothing about maven... So... if someone (maybe Richard Achmatowicz) could look into that. http://jira.jboss.org/jira/browse/JBQA-846 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054513#4054513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054513

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Refactoring access to JBPM database

by tom.baeyens＠jboss.com

The sessions don't really intent to provide an pluggable persistence. What technology do you have in mind ? IMO, only JPA could be considered. But we are only researching if that kind of pluggability is feasible for jbpm 4. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054511#4054511 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054511

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Refactoring access to JBPM database

by rjoachim

Reviewing current JBPM codebase, it seams to me that you intend to move all database specific code of JPDL into the different Session classes in org.jbpm.db package to make persistence provider plugable. If that is your intention I am willing to contribute in that area as I like to use a different persistence provider together with JBPM. Are there already some open issues? If there are no open issues I would create one head task with a bunch of small subtasks. According to my experience the small subtasks will make review much easier for the committer. Is anyone of the committeres willing to assist me with this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054510#4054510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054510

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Release 1.1.0 of jboss-retro

by pgier

The release is now complete. I was able to move the classes back into the old package structure, and test the backwards compatibility of the runtime jar with tests weaved by retro version 1.0.5, and everything seems to work fine. The release notes can be found on the jira page: http://jira.jboss.com/jira/secure/ReleaseNote.jspa?projectId=12310081&sty... The groupId of jbossretro has changed from "jboss" to "org.jboss", so the path is now a little different. If you want to use version 1.1.0 from an ant script, you will have to put this into your build-thirdparty.xml | <componentref name="org/jboss/jboss-retro" version="1.1.0"/> | >From a maven build, the dependency should look like this: | <dependency> | <groupId>org.jboss</groupId> | <artifactId>jboss-retro</artifactId> | <version>1.1.0</version> | </dependency> | Or like this to include the runtime: | <dependency> | <groupId>org.jboss</groupId> | <artifactId>jboss-retro</artifactId> | <version>1.1.0</version> | <classifier>rt</classifier> | </dependency> | The jars are exactly the same whether you are using it from ant or maven, just a different path to get there. The maven-jboss-retro-plugin has also been released to verion 0.9-beta, and can be found here: http://repository.jboss.org/maven2/org/jboss/maven/plugins/maven-jboss-re... The GA version 0.9 of the plugin will be coming soon, and will include some better documentation about how to use the maven plugin to retro your code in a maven build. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054491#4054491 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054491

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Is this an issue with Maven or JBoss Build components?

by juha＠jboss.org

It seems likely to be an issue with the plugin then, since I'm running that specific task when it occurs. Either that or something to do with Java 6. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054476#4054476 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054476

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Is this an issue with Maven or JBoss Build components?

by pgier

I haven't seen this before. If it is only happening with certain plugins/goals like with the docbk generation stuff it could be a problem with that plugin. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054467#4054467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054467

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Listener Notifications to happen asyncronously?

by manik.surtani＠jboss.com

The primary reason was precisely that people were using listeners to apply aspects, which we think is incorrect as it can cause incorrect operation, reentrancy issues, etc. What needs to be noted is that such notifications are purely that - a notification. Any operations that happen in a listener implementation should not use the same scope as the original thread triggering the event to do stuff - like make more calls into the cache, etc. Any such work should happen in a separate thread (as we recommended in previous versions of JBoss Cache). The only difference is now we're forcing the use of a separate thread. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054451#4054451 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054451

18 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2007