February 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: EJB3 enterprise module?

by heiko.braun＠jboss.com

anonymous wrote : | so what you're saying is that with ejb3, there is a bigger chance that the .ear file will run without modifications on lets say websphere or weblogic ? | right View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208962#4208962 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208962

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB3 enterprise module?

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : I think the biggest problem with the CMP based implementation is the container dependence. It always requires a vendor specific persistence mapping. But if we move to JPA we get rid of that problem. that makes sense to me. (and makes me change my mind) so what you're saying is that with ejb3, there is a bigger chance that the .ear file will run without modifications on lets say websphere or weblogic ? if that is true, then i'm in favour of moving to ejb 3. with ejb 2, we will not have the time to build those appserver specific deployment descriptors. so ejb 3 would give us better coverage of environments. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208960#4208960 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208960

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Questions on EJB2 enterprise module

by camunda

Hi Alex, I currently review the current enterprise module and have some questions. I hope you don't mind if I post them here? - Commands: I thought about that they should be moved to the jbpm core command base. But this special behavior avoid this to be easy: ExecuteJobCommand / postJobsExecution: There a JMS message is created hard coded. Wouldn't it be possible to create the jobs again via the MessageService? In the JMS implementaion this will create messages but use the default way and code? - Why is the ExecuteJobsCommand that much easier than the ExecuteJobCommand? shouldn't it basically include the same logic? - The ExecuteTimerCommand could easily be moved to jbpm core timers, wouldn't that be a good option? Can I do such a refactoring? Thanks Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208959#4208959 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208959

17 years, 1 month

1
0
0 / 0

[Design of JBossXB] - Re: 2 root elements question

by alex.loubyansky＠jboss.com

Ok. Whether I release CR17 depends on whether I complete the next cleaning step. Hopefully so. Let me know if it's a blocker for you. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208958#4208958 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208958

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: jbpm 4 module dependencies

by heiko.braun＠jboss.com

It depends on what you mean with the "task" model. IMO a final task implementation would be split into the base task model (antwerp) and a concrete implementation. Whereas the first does probably belong into the PVM, but the later doesn't. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208957#4208957 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208957

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB3 enterprise module?

by heiko.braun＠jboss.com

I think the biggest problem with the CMP based implementation is the container dependence. It always requires a vendor specific persistence mapping. But if we move to JPA we get rid of that problem. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208953#4208953 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208953

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: jbpm 4 module dependencies

by tom.baeyens＠jboss.com

image is updated. heiko, what do you think about moving task into pvm ? do you see a disadvantage ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208949#4208949 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208949

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: jbpm 4 module dependencies

by tom.baeyens＠jboss.com

because jboss did not handle java.util.logging properly. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208948#4208948 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208948

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: jbpm 4 module dependencies

by heiko.braun＠jboss.com

As a side note: Why do we have a custom logging framework? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208942#4208942 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208942

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - 'public' API stability when embedded in JBossAS

by jhalliday

The long term support commitments for JBossTS CP maintenance involve not making public API changes, the intention being that users can be confident that moving between CP releases won't cause linker type errors. Unfortunately this is at odds with the need to fix bugs, which can sometimes require API changes. As we prepare to fork another long term maintenance branch I think we should spend some time considering this dilemma. What is the API we wish to support? We have got ahead of the game with XTS, explicitly packaging (i.e. different .jar) the API distinct from the implementation. For the rest of JBossTS it's all bundled up together, so we have to consider any 'public' class to be part of our published API. For a long time the codebase has used .internal. packages to denote implementation, but users are not necessarily aware of this distinction. A lot of code which end users need to access directly when running standalone, is abstracted by the app server when running embedded. Arguably the only public API for JBossTS when embedded in JBossAS, is the TransactionManagerService mbean, CORBA interceptors, ObjectStore and possibly a recovery class or two. The rest is all abstracted via javax.transaction. But this is at odds with the 'if we ship it we support it' model, since the binaries still include e.g. TxOJ and TransactionalDriver, neither of which JBossAS uses. My personal preference would be to publish the list of interfaces/classes we consider stable and make clear that everything else is subject to change in CPs, regardless of .internal. or 'public' modifiers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208938#4208938 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208938

17 years, 1 month

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 February 2009