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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Comments in code about large message replication

by clebert.suconic＠jboss.com

Ahhh.... I just remembered.. the "// FIXME - this won't work with replication!!!!!!!!!!!" is yours... for something else beyond LargeMessage I will remove the JIRA reference, and only keep its reference on the method copy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205560#4205560 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205560

15 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployment cleanup & modifications

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | The "simplist" solution to this problem should be that when somebody creates a root | VFSContext it is against that object that the "temp" information should be stored | or at least linked. | | That root VFSContext should always be "live" while somebody holds a | link to the root VirtualFile. | | Then when somebody asks to cleanup a VirtualFile within that context, it can workout | which parts of the temp information need to be removed. | | The context should still be usable, its just removed the temp data which would need to be | reconstructed. Which is why close() or destroy() is a bad name/semantic. By way of a more concrete example using your example: deploy/ * myapp.ear (exploded) ** myweb-ui.war (packed) *** WEB-INF/lib **** some-persistence.jar ***** META-INF/persistence.xml Typically the root VFS context is going to be the deploy folder. When you want to unpack myweb-ui.war or some-persistence.jar you tell the root context what you've done. (As usual this is pseudo code) | VFSContext ctx = getRootContext(); | ctx.addCacheInfo(getPath(), origName, new TempJarInfo(...)); | | public class TempJarInfo implements VFSCacheInfo | { | ... | | public void cleanup() { ... } | } | This avoids also trivially allows you to avoid unpacking them again, since you can ask this cache. | // Already unpacked? | VFSContext ctx = getRootContext(); | tempName = ctx.getCacheInfo(getPath(), origName); | Then when the deployment says you can cleanup "deploy/myapp.war" you can iterate over these cached objects that being with that VFS path and clean them up. | VFSContext ctx = getRootContext(); | ctx.cleanupCache(getPath()); | | i.e. | | for (Map.Entry<String, VFSCacheInfo> entry : allCacheItems) | { | if (entry.getKey().startsWith(path)) | getValue().cleanup(); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205557#4205557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205557

15 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Finding RealClassLoader in ServiceDeployer

by alesj

I see ThomasD already applied my patch to 5_0: | Modified: | branches/Branch_5_0/system-jmx/src/main/org/jboss/system/deployers/ServiceDeployer.java | Log: | [JBAS-6425] full hirarcy search for RealClassLoader | And I doubt (I actually know he didn't :-)) he ran all the tests or waited for Hudson to puke some error. Ccccc Thomas ... too global change to not let it pass some testing before commit. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205554#4205554 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205554

15 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployment cleanup & modifications

by adrian＠jboss.org

Why are you trying to "destroy" the Deployment object? That is a client side object. That is supposed to be under the caller's control you shouldn't be modifying it or giving it some "stateful" representation. All the book keeping for temp data of a VFS file should be inside the VFS itself. I said this before WRT to the horrible explicit VFS Cache you did, but I was ignored. The "simplist" solution to this problem should be that when somebody creates a root VFSContext it is against that object that the "temp" information should be stored or at least linked. That root VFSContext should always be "live" while somebody holds a link to the root VirtualFile. Then when somebody asks to cleanup a VirtualFile within that context, it can workout which parts of the temp information need to be removed. The context should still be usable, its just removed the temp data which would need to be reconstructed. Which is why close() or destroy() is a bad name/semantic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205553#4205553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205553

15 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Comments in code about large message replication

by clebert.suconic＠jboss.com

I have made the file-copy for now... so it does work. 1468 still there for a later improvement. and I thought I had removed this comment " This won' t work with replication". Where did you find it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205548#4205548 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205548

15 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Comments in code about large message replication

by timfox

| // (JBMESSAGING-1468) | // FIXME - this won't work with replication!!!!!!!!!!! | Isn't this supposed to be complete now?? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205522#4205522 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205522

15 years, 2 months

1
0
0 / 0

[Design of JBossCache] - JBoss Cache Options API

by manik.surtani＠jboss.com

This has come up in the past, and I want to revisit this for a potential future improvement to the API. Options are hugely useful in being able to provide additional per-invocation context and overrides. But the current mechanism is nothing short of kludgey: | cache.getInvocationContext().getOptionOverrides().setXYZ(); | cache.doSomething(); // your invocation | Ugly since it involves thread locals and there is a lot of code to check for leaks, proper cleanup, context leaking to additional calls, nested calls with notifications, etc etc etc. So I'm looking for suggestions for a better approach here. FYI, the way this was done in JBC 1.4.x (which is still ugly IMO) was to overload all methods on the cache with versions that took in an Option class. e.g., | cache.get(Fqn f, Object key); | cache.get(Fqn f, Object key, Option o); | Thoughts and suggestions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205521#4205521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205521

15 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: [JBCACHE-1470] Option to disable cache event generation

by manik.surtani＠jboss.com

Welcome back. :-) Looks good, and in general, I prefer a blanket approach where all notifications are suppressed if the option is present rather than specifying the listener class to skip since the latter implies knowledge of listeners registered. Actually, thinking about it, perhaps notifications should never be issued to a listener that *generates* a notification anyway, to prevent cyclic behaviour? No, I foresee code that may well have been written to take advantage of this. An explicit option is probably better. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205518#4205518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205518

15 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: BPMN in jbpm4

by tom.baeyens＠jboss.com

"camunda" wrote : - Multiple leaving flows in a activity with XOR semantic. This is not BPMN, BPMN has AND semantic but allows for conditions on the outgoing flows. The behaviour implemented makes sense if you know jPDL, but it is not correct BPMN. I think this is somehow problematic | as heiko already indicated. we'll be fixing spec violations like this one. if you have good suggestions on how we could represent a wait state best in bpmn, or how we could best use bpmn-extension pluggability to indicate that we're doing something jPDL-specific, let us know. "camunda" wrote : End which terminates Executiuon only. For this end the End-Event should be used, not the Termination-Event (which is only a signle circle). With the termination event BPMN specifies that the whole process instance is terminated. good point. we'll fix it. koen didn't have the option yet to put distinct icons on different configurations of the same activity. "camunda" wrote : Missing stuff | A lot of stuff is still missing: Attached events, Pools, Lanes, a lot of events (like message, compensating, ...). | | The question here is: To what extend will the missing features be implemented? Is this one of the goals? Or not? I am not currently up to date here, maybe I had to leave Antwerp to soon :-/ extending to what heiko already said: * jpdl 4 will be an improved version of jpdl 3. this will make sure we capture the value of jpdl and extend on it. * for each jpdl construct we'll search for the exact matching BPMN construct. * if no proper match exist, we'll clearly indicate that this construct is not BPMN and that it is jPDL specific * we'll also plan to go over the BPMN constructs and see if we can easily find or build a suitable match in BPMN to extend the BPMN coverage. "camunda" wrote : Will spec-conformability be targeted? Or is BPMN more for nice looking diagrams and marketing? of course spec conformity is the target... but whether we will reach 100% remains questionable. at this stage marketing is an important driving factor. to adopt it for jPDL. in teh BPMN 2.0 spec committee, they are working out exact execution semantics and a file format. after jBPM 4 goes GA, we have to make a choice between 2 directions: further move away from jPDL and make it fully executable BPMN 2.0. or we can decide to go for BPMN 2.0 as a separate process language. i am pretty confident that BPMN as it is today, can not be made as usable as jPDL for the use cases that we target. over the last two years, bruce silver has pointed out on numerous occasions that people (even bpmn software vendors) do not get the full details of the spec. michael zur muehlen has pointed out that only the first 9 out of 40 bpmn concepts are actually used in practice. further more, the scope of BPMN at this stage is still pretty vague as it includes things like choregraphy. the process on how we deal with bpmn in jbpm 4 is outlined above. that will make sure that we don't loose the jPDL audience we have today and help to make inroads in the levels where BPMN is a marketing checkmark. after jBPM 4 GA we'll have to choose. (side note: given the focus on executability and file format in bpmn 2.0 committee, i am certaint that bpmn is intended and going to deprecate bpel over time) bpmn as a spec is definitely of another kind to us then bpel. bpmn has the potential to become mainstream sustainable process modelling notation. but it will require that a limited intro level is established. sort of like the HTTP GET as the 10% of the spec that covers the 90% of all HTTP operations. we always knew that bpel only remained hyped till the ora's and ibm's give up their marketing to push their shitty technological choices. once that marketing effort disappears, bpel will be legacy. if bpmn does make that distinction --chances are significant for that-- then i'm convinced bpmn can end up being sustainable. bruce silver already introduced the notion of levels of bpmn. so the idea is on the table. in conclusion, we'll be examining to what extend we can comfortably fit BPMN on top of jPDL in this jBPM 4 GA iteration. after the GA and once BPMN 2.0 is out, we'll have more experience and info if we can sustain that the combined BPMN-jPDL route or if we have to split both of them in dedicated languages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205514#4205514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205514

15 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployment cleanup & modifications

by alesj

"alesj" wrote : | But while we're trying to recognize the structure, to create a DeploymentContext instance, | we already potentially do some temp unpacking, ... | That's why a need to do cleanup also on client side Deployment. | And even this is not enough. As we might not even know how to cleanup all that we've temped. e.g. VFSDeployment only has an access to top root. But if our deployment looks like this * myapp.ear (exploded) ** mywep-ui.war (packed) *** WEB-INF/lib **** some-potential-persistence.jar ***** META-INF/persiostence.xml In this case our WarStructure would temp that some-potential-persistence.jar leaving us with no handle to clean it up. This might work if Deployment had a knowledge of structure, as we would be able to call cleanup on sub-deployment (the war), but this again means it's messing with sever-side info. Since it's only temps I wouldn't loose too much sleep over it if there is no quick/non-dirty solution. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205510#4205510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205510

15 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2009