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

[Design of JBoss jBPM] - Re: first cut of the new history

by jbarrez

Tom, Thanks for the clarification. This is a great modification compared to jbpm 3! This allows to keep the runtime structures nice and tidy and the queries fast :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209894#4209894 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209894

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Duplicate DeploymentContext registration

by adrian＠jboss.org

"alesj" wrote : This eliminates the duplicates: | I found it very difficult to understand what the problem was from the forum threads other than it produced a spurious warning, but I used your deployment structure to create a test that reproduced it and fixed the problem. https://jira.jboss.org/jira/browse/JBDEPLOY-158 The issue was that both registerMBeans() from the top level deployment and registerMBeans() from the subdeployment were trying to install the sub-subdeployment mbean. I've fixed it such that each mbean only recurses to one-level which is I think what your fix was trying to do, but it wasn't very clean. anonymous wrote : | And another issue. | Isn't DeployersImpl::registerMBean called too early? | As at that point we don't have any components yet, | since the deployment hasn't gone yet through deployment stages. | It's just installed + manual mode --> Not_Installed state. | The idea is that the mbean is deployed as early as possible so you can analyse it using JMX. If you add/remove components or subdeployments later there are hooks to (un)register the mbeans. I also started some much need missing tests to make sure this doesn't regress. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209893#4209893 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209893

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: blobs, clobs, text and bytes

by camunda

Okay, then +1 for the blob as default View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209891#4209891 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209891

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: first cut of the new history

by tom.baeyens＠jboss.com

the bigger picture is this: in jbpm 3 we have a flat log table. biggest problem with that is that it contains references to the runtime data (tokens and process instances). because of that reason, the runtime data cannot be deleted and it keeps growing. now in jbpm 4, we'll have a history schema that does not reference the runtime data (it can reference process definition data as that data remains in the db). as a result, now process instance data is deleted once it is no longer needed. e.g. executions and variables get deleted when they go out of scope. and the full process instance is deleted when it ends. the runtime data tables stay clean and healthy this way. the reporting and other monitoring is done on a separate set of tables. so this also makes the whole system more performant. so in jbpm 4 we will not have a flat log file, but a fully fledged schema that contains the history information of what happened when in the process executions. so an extra advantage is that the history schema is designed to be easy queryable. it can contain some de-normalized duplications of information. (e.g. startTime, endTime and duration fields). internally, the architecture remains almost the same: runtime execution still generates history events (previously called processlogs). there is a pluggable history session that captures these history events. and the rest is described above. does this help ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209890#4209890 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209890

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: blobs, clobs, text and bytes

by tom.baeyens＠jboss.com

the chopping code is ported to 4, but i'm not sure what is best to take as the default in this situation. the reason was that chopping was better for database portability. i always thought that oracle was a difficult one. but that seems to work ok. maybe since we have our own qa now, we can just use blob as the default and save ourselves a table and gain some performance. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209889#4209889 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209889

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: first cut of the new history

by camunda

Hi Tom. Sorry, I didn't completly get it. Could you maybe start with the bigger picture first bevore going into the details? I didn't catched the idea yet. Of should I maybe read a bit of code if its already checked in? Thanks Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209888#4209888 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209888

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: blobs, clobs, text and bytes

by camunda

As far as I remember there was a lot of effort put in the chopping, and there is a good reason why it is there, or not? In that case maybe it makes sense to just port the logic/code? But if it works without as well I am with Jorram, skip every unecessary complexety.... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209887#4209887 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209887

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: email templates

by heiko.braun＠jboss.com

Yes, for Seam it makes sense to leverage what's there. But in our case it's doesn't seem appropriate. jBPM is intended to be embeddable. Hence we shouldn't pull in large dependencies for simple things. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209846#4209846 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209846

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: email templates

by pete.muir＠jboss.org

Ronald - the work is mostly done, it should work in most cases. There have been some issues raised that in some situations the bootstrap we do doesn't work. The remaining work is more polish/edge cases than anything else. Currently you need to import all of Seam core and mail as we haven't done the modularisation of Seam yet. Please let me know if you have patches for this and I will try to look at them. As for why we didn't use velocity - well for a start we would have used freemarker ;-) But really, Seam is about allowing you do to stuff without having to learn 101 ways of doing things so, as we already used JSF for the view layer, we wanted to allow people to reuse this knowledge. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209839#4209839 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209839

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: console roles

by heiko.braun＠jboss.com

yes, that was my idea aswell: implement the monitoring a top of jopr and embed the jopr console into the gwt console. so it can be used standalone or as part of jon. I'll probably be able to look into it in the next iteration. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209835#4209835 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209835

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