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

[Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss

by bill.burke＠jboss.com

"tom.baeyens(a)jboss.com" wrote : "bill.burke(a)jboss.com" wrote : | | 1. The hibernate and jbpm xml files are embedded deep within the enterprise archive. These need to be moved up for easy edits by the user | | | | one option could be to extract all the .hbm.xml files and put then in the config jar file. would that qualify as 'moved up' ? | Has to be an exploded archive so people don't have to unjar things. The less people have to do, the better. anonymous wrote : | i definitely want at least something that is as portable as this solution. if there are jboss specific ways on how to move the configs even up further, i 'm ok with that as long as it's another option that we offer apart from the portable deployment. | It would be another option, as its definately JBoss specific. anonymous wrote : | "bill.burke(a)jboss.com" wrote : | | a) You need to create the jBPM schema in the database | | | | Previously detection and update of the schema was done automatically in a .sar. But i want to move to a portable .rar for this. Would that be an option for you ? | Its as simple as configuring Hibernate to "update" mode so that the schema is created on boot time. As for JCA, an outbound adapter for jbpm might be interesting so that you could inject JBPM contexts and would give you somewhat of a portable way of doing deployment. Like, with the outbound configuration, you'd specify the .jpdl file or process archive to load. anonymous wrote : | "bill.burke(a)jboss.com" wrote : | | At deployment time, the JBPM deployer would calculate a hash for hte .xml file. If this hash matches a previously deployed .xml file nothing is done. If it is a new hash, a new version of the process definition is saved to the database. | | | | hash in combination with the last update time of the file would be good, i think. i wouldn't trust hash only. chances are small for a collision, but imagine if you have such a collision, then you would have to make sure something in the file is changed to get it deployed. | I can't imagine having such a collision as you have a higher chance of getting struck by lightning. RMI and our EJB code uses an MD5 of a method to send its identity over the wire. anonymous wrote : | saving that info in the database is going to be tricky in 3.2.x as we only want to allow updates to the db schema between minor version releases. 3.3 is still some time out. | Why so tricky? Just create another table. create table( process_name VARCHAR, process_version int, process_hash long ); Its something only the deployer knows about. 1. Parse the .jpdl file. 2. Create an MD5 hash of the file (or object model or whatever) 3. Get PD name from deployed file 4. query table for latest PD 5. compare hashes 6. If new, insert into table name, version++, new_hash 7. create new PD in JBPM anonymous wrote : | "bill.burke(a)jboss.com" wrote : | | A new config structure would look like this: | | | | | | | jbpm.deployer/ | | | hibernate.cfg.xml | | | jbpm.cfg.xml | | | jbpm-ds.xml | | | jbpm-jpdl.jar | | | jbpm-enterprise.ear | | | META-INF/ | | | jboss-service.xml | | | | | that looks good. but consider JCA and a .rar to deploy jbpm separate on the appserver, apart from the deployer. then the .rar would be portable. A RAR would be limited and you would still need to deploy 2 separate files, a pd-ds.xml file, to define the process instance, and the .par file (or .jpdl file). Where in a JBoss deployer, its just one file and less metadata to write. What's also good about the JBoss model is you would be able to compose applications into one archive: | foo.sar/ | ejbs.jar | jbpm-app.par | foo-dsl.xml | with JBoss 5 it would be even more interesting and simple as a multiple deployers can process one archive (unlike JBoss 4). | jbpm-app.jar/ | com/ | org/ (class files, could be annotated components like EJB and SEAM) | foo-ds.xml | META-INF/ | ejb-jar.xml | jbpm.jpdl.xml | seam-components.xml | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052110#4052110 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052110

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Process Definition and Java class versioning

by bill.burke＠jboss.com

Ok, i'll have to look into this one. Didn't know that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052092#4052092 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052092

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss

by bill.burke＠jboss.com

"kukeltje" wrote : Question: Why should a new processarchive with an identical pd.xml file but new classes not always require a new deployment? This is related to the problem how to decide a class is new. (build clean gives you a new timestamp but is something else identical?) | | Expose a version attribute in the jpdl schema. This would allow you to rev the version if you want when only class changes are present. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052090#4052090 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052090

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss

by estaub

anonymous wrote : Though I've always disagreed with storing the process archive (especially the classes) in the database. Don't forget about clustering. anonymous wrote : I think that the user should be able to control (to the extent that it is possible) whether or not a new version is created Agreed, although it will be hard to explain and control expectations about what will work and what won't. For example, I think that many topological changes would work fine, but specifying that set of changes may be hard. -Ed Staub View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052087#4052087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052087

18 years, 10 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portal User Creation

by julien＠jboss.com

The user module although being stable API are not public API that we publish and support (unlike the org.jboss.portal.api.* packages). That being said we have in 2.6 fairly good documentation about that I think. http://cruisecontrol.jboss.com/cc/artifacts//jboss-portal-latest-doc/refe... Otherwise you can look at the code of the UserPortlet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052075#4052075 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052075

18 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remote replyto functionality - Bridge configuration in p

by thomasra

It could be as simple as this perhaps (from inside the sendBatch method in Bridge): | // Differentiate between messages that require a reply | Destination originalDestination = msg.getJMSReplyTo(); | if(originalDestination == null) { | producer.send(msg); | } else { | // This probably needs to be spawned in a separate thread so it doesn't block | QueueRequestor q = new QueueRequestor((QueueSession) targetSession, (Queue) producer.getDestination()); | Message response = q.request(msg); | producer.send(originalDestination, response); // This isn't the correct producer, though | } | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052074#4052074 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052074

18 years, 10 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portal 2.4.1

by julien＠jboss.com

thanks, I have created a JIRA task for this : http://jira.jboss.com/jira/browse/JBPORTAL-1478 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052073#4052073 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052073

18 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remote replyto functionality - Bridge configuration in p

by thomasra

Actually, JMS 1.1 section 5.10 QueueRequestor already does the temp stuff for us, so we could just thread out a QueueRequestor from the Bridge when sending to the remote provider, it will block until a response is received, and then we know what this is a response to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052068#4052068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052068

18 years, 10 months

1
0
0 / 0

[Design of JBossXB] - Re: Ignoring non-ignorable white space?

by wolfc

Yup. I've opened up http://jira.jboss.com/jira/browse/JBXB-103 and attached an unit test patch. (Why can't I commit there?) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052061#4052061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052061

18 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remote replyto functionality - Bridge configuration in p

by thomasra

"thomasra" wrote : | * JMS Message arrives at a JBM destination | * TwoWayBridge receives it, sees that it has a ReplyTo destination, keeps track of the original replyto destination and jmsmessageid | * TWB creates a remote temp destination | * TWB sends the message with the remote temp destination as the ReplyTo value, after send() it adds the remoteJMSMessageId to the same record | * TWB begins listening on the remote temp queue (it now knows which message it is waiting for a response to) | * TWB receives a response from the remote provider on the temp destination | * TWB replaces the correlationid and the replyto values with the original ones | * TWB sends to a JBM destination Correction: we do not need to keep the remote messageid in this scenario (it is irrelevant). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052058#4052058 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052058

18 years, 10 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