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

[jBPM Development] - Re: parser for each jpdl release

by kukeltje

Detailed comment coming later, but one remark first: anonymous wrote : but my neural network is chewing on this with 100% CPU utilization. I've seen CPU's being busy for 100% and effectively doing nothing. The times I've seen a neural network busy 100% of the time it was shortly before a nervous breakdown... Either way, it is not good ;-P View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258553#4258553 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258553

15 years, 3 months

1
0
0 / 0

[jBPM Development] - Re: parser for each jpdl release

by tom.baeyens＠jboss.com

"kukeltje" wrote : Ok, the 'parking' of older parsers makes sense. I do have som questions though | - A version is not only the parser but also accompanying activity implementations. These are instantiated once a process is started (from what I understand). Does this have implications? | very true ! that's the tricky thing i ran into yesterday. so now i think we should aim for the following approach: * make sure that we can know the version of each process when we parse it. this can be a bit tricky, because 1) we do not enforce people to specify namespace, so when deploying a process, the current library version somehow has to be added in to the db. and another issue is this: if we use the namespace for knowing the version, then this is also used to activate or not activate the xml validation. so we could end up with the situation that an invalid process deploys because originally the namespace was not present. if we then add the namespace before we save it in the deployment, then when loading it from the db it contains the namespace and that will activate validation. and hence the process can not be used. given that we use a cache after deployment, this kind of problem might not show up in test environments. * introduce a couple of if-then-else statements in the parser that depend on the version * the hard part is testing. i'm still trying to find how to we test this? how can we make sure that old deployed processes will still work correctly in newer versions of jBPM. i've been thinking about making sure that we run the test suite with a version parameter. then all the processes in the testsuite which don't have an explicit namespace, will use the configured parser version. but i'm not yet sure if this tests what we actually need. and to what extend it protects us from making backwards incompatible changes. if we get this wrong, the risk is that we break existing installations after they upgrade. "kukeltje" wrote : - Currently the schema is not fully 'any:any' aware. (I still think it should be 'other:any' for the extensibility. Fully supporting this is needed if you automatically want to add a namespace since people can remove the ns now if they want to add custom attributes. | if you declare extensibility with any:any, then users can *still* define all their extensions in their own namespace. they are just not forced to do it if they want to. why do think users *need* to define their extensions in a separate namespace. i agree that it would be good practice from a user perspective. but i don't see a reason why we should enforce our users to it like that. "kukeltje" wrote : - Does this mean that people have to redeploy their old processes if they want to take advantage of certain bugfixes in e.g. activity implementations? that's the kind of questions that we have to ask ourselves when composing a solution. i didn't yet see the best solution for this whole compatibility and versioning of deployed processes issue. but my neural network is chewing on this with 100% CPU utilization. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258532#4258532 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258532

15 years, 3 months

1
0
0 / 0

[jBPM Development] - Re: parser for each jpdl release

by tom.baeyens＠jboss.com

"camunda" wrote : Depends on how good we can develop these new parsers. I think of fixes in parsing for older released, where complexity might explode if you have to have a look at a couple of versions. | after an attempt i did yesterday, I realized having a parser-per-version gets much more trickier then I originally thought. "camunda" wrote : Hmm, and you changed, you want to ADD namespaces per default???? ;-) not really. basically one of the techniques that we could use is the following: upon deploying the process, we could * parse the process into dom * if no namespace is present to indicate the version, we could add a namespace declaration or another attribute that indicates the version * then serialize that process * and update the xml in the deployment before it gets saved in general we could potentially add or change the xml when we deploy it. but I think that a downside will be that developers don't like this because they will love it better if they still recognize their own XML in the DB. the alternative is that we leverage the properties that are associated to a deployment object. "camunda" wrote : A basic question upfront: Why not forbit removing attributes from the schema at all? Shouldn't be that regular and not hard to avoid, or am I wrong here? Would save us all that complexity... | here's the dilemma: attribute 'expr' is used in conditions on transitions in a decision. in that case the returned value is expected to be a boolean. the 'expr' attribute is also used in one of the places where you specify user code. in that case the resulting object is used as the user defined object. now I want to clean that up: 1) i want to keep 2) i want to make all the user code parsing consistent. in order not to clash with the expr of condition, I want to use object-expr for all usages where the resulting object is used as user code. i don't see how we can clean this up without differentiating the parsing between versions. in the meantime i do think that we should be able to support this with just a couple of if-then-else statements in the single parser based on the namespace or version info. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258531#4258531 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258531

15 years, 3 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - Re: Web application deployment directory

by alesj

You can also already use the latest VFS 2.1.4-SNAPSHOT and its TempStore, as it's back compatible with the current 2.1.2 version. See my TempStoreTestCase and PreInitializVSFContexts on the actual usage/config. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258526#4258526 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258526

15 years, 3 months

1
0
0 / 0

[JBoss Portal Development] - Re: jbossportal:flash doesn't load on IE

by raffaele.letizia

i use jbossportal 2.6.7 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258522#4258522 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258522

15 years, 3 months

1
0
0 / 0

[JBoss Portal Development] - jbossportal:flash doesn't load on IE

by raffaele.letizia

HI, i have a problem. I have create on "jbossportal" ( i used jboss 4.2.3) my portal and when i load a flash (.swf ) on a page Mozilla is great while the Internet Explorer create a white screen where the swf is no load. Thank you View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258519#4258519 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258519

15 years, 3 months

1
0
0 / 0

[JBoss Messaging Development] - Re: FilterParser.jj

by clebert.suconic＠jboss.com

anonymous wrote : I am just reading the new JMS server source code, inside eclipse Do you mean hornetQ? www.hornetq.org? jboss-messaging/trunk has been discontinued. We are now developing under hornetq. JBM 1.4 (Branch_1_4) is in maintenance mode. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258493#4258493 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258493

15 years, 3 months

1
0
0 / 0

[JBoss ESB Development] - Re: XPath Routing

by Kevin.Conner＠jboss.com

"burrsutter" wrote : Historically, we counted on the tooling guys to just "keep up". That explains why they think so highly of us :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258480#4258480 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258480

15 years, 3 months

1
0
0 / 0

[JBoss ESB Development] - Re: XPath Routing

by burrsutter

I don't believe we have a clearly defined process. Historically, we counted on the tooling guys to just "keep up". In this case, I think any of us can create the jira. Ideally it would be Tom since he can describe the changes to the jboss-esb.xml better than the rest of us at this moment. Burr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258477#4258477 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258477

15 years, 3 months

1
0
0 / 0

[JBoss ESB Development] - Re: XPath Routing

by Kevin.Conner＠jboss.com

"bfitzpat" wrote : Tom, do we have a JIRA created yet for this new ESB Xpath routing to get it into the ESB configuration editor? Or do we need to create one? | --Fitz I'll chase this up and see what is happening, will include you in the distribution. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258472#4258472 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258472

15 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2009