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

[Design of JBoss jBPM] - Re: meeting context

by kukeltje

Afaik, but could not find it directly, BPMN is based on structured graphs Well, we just borrow the terminology (i.e. parallel gateway) and need think about what it means for the implementation. This is exactly the kind discussion I'd like to have. anonymous wrote : | In JPDL 3 it is fully clear, you need a fully nested fork-join pair. This differs from the statement in the workflow patterns for parallel split: | Exactly, hence the need for verification. They leave it open, we decided to make a choice since it impacted implementation and there have not been real problems regarding this choice "heiko.braun(a)jboss.com" wrote : | What you said about previous discussions is something I don't agree with at all: | | anonymous wrote : | | This has been discussed several years ago, so unless bpmn requires otherwise, the decision for this is simple I think ;-) | | | | Sorry, this statement was mend solely in the context of the nested fork/join "heiko.braun(a)jboss.com" wrote : | Let's put it the other way around: Why do all the vendors support workflowpatterns.com [1] and BPMN [2] opposed to jbpm? | | [1] http://www.workflowpatterns.com/vendors/ | [2] http://www.bpmn.org/BPMN_Supporters.htm#current | Ahh.....this is an interesting one... A really interesting one.... or even two (separate) interesting ones. Lets get the facts and history straight on the first one. [1] is 'old' and for the 'original' patterns. That is not very clear to people who are fairly new to these things. I remember the discussions I had with Tom about the discussions he had with Prof. van der Aalst (I also personally met him twice on workflow non-related events) about the workflow patterns. jBPM 3.0 (look in the source for the pattern tests) engine wise supports them. JPDL language wise not (but most), at least not with writing some small reusable java classes. They did not want to evaluate jBPM at that time due to the different views on things. They wanted everything in the 'language' while we said that basic things were supported in the language and less used things were possible in the engine with some small java code. In all these years there has been one pattern users in the forum asked me about (well actually two, but the implementation in jBPM is 98% the same, two multiple-instance patterns [3], and [4]. In the wiki we've described how that can be achieved in jBPM. Nobody complained. In fact, we are even more flexible, since these multiple instances can easily be assigned to different actors. But... I won't complain that they did not evaluate us (users in the forum did not, so who am I). We could have implemented language constructs for them, but it was a trade-off between time and the number of times it was requested. Therefore it was not done. But.. things have changed a little. First of all, on the evaluation pages [5] of the workflowpatterns, they did evaluate jbpm [6]. With some of the patterns they now explicitly that they are supported with some java code. Regarding [3] they state: "workflowpatterns.com" wrote : | jBPM does not support this pattern. There is a proposed implementation in Java of a node-type Node to capture this semantics. As the solution relies on java-coding we consider it outside the capabilities of the proposed jPDL language | This has (in our opinion) never been a problem and the extensibility is part of jBPM thourgh JPDL. Regarding [4] they state "workflowpatterns.com" wrote : | jBPM does not support this pattern. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181067#4181067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181067

16 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Policy Implementation for VFS

by david.lloyd＠jboss.com

Ah, I see. It's obvious now that I try it out: the policy file parser is literally constructing a URL instance during the parsing stage, which fails because the appropriate URL handler is missing. So I guess the real question is: it the best solution to implement a custom policy interpreter that can handle arbitrary URIs, or to come up with a way to trick the URL protocol registry system to allow the URL handler to be "lazy-loaded"? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181065#4181065 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181065

16 years, 3 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing ClassPools for AS

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | The requested rules are on the Module, e.g. importAll, exportAll and requirements/capabilities | So to get this straight I can get the exported packages from the ExportedPackages(PackageCapability) of the Modules's capabilites and the imported packages from the OptionalPackages(PackageRequirement/UsesPackageRequirement)? Will these only be set if importAll and exportAll are false? What is the difference between PackageRequirement and UsesPackageRequirement? The method name is getOptionalPackageNames(). What does that mean? I also see that AbstractRequirement has an optional flag. If false, does that mean it is required? If that is the case, I don't really get what an optional import means. "adrian(a)jboss.org" wrote : | or by looking at the actual ClassLoaderPolicy used to create the classloader, | e.g getPackageNames() and getDelegates(). Are you saying I should really be using this instead of Module? How do I obtain this from a deployer? What about version ranges? How are they represented? What I am doing is implementing one DelegatingClassPool per classloader, and having that backed by a ClassPoolDomain which corresponds to a classloading domain. If a CtClass cannot be found in a DelegatingClassPool it will delegate to the domain which will then look in the registered pools. Should things like parentFirst be handled on pool or domain level? I originally had that on the domain, but from what I gather the other settings importAll/exportAll/imports/exports should be handled on the pool level. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181057#4181057 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181057

16 years, 3 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing ClassPools for AS

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : I'm going to bite the bullet and attempt to reimplement how the JBoss ClassPools work. I am currently working on pre-OSGi with classloaders organised by domains. Although I doubt I will have time to implement the OSGi part before AS 5.0.0.GA I would at least like to add the correct properties to my classes at this stage. A few questions | | *I seem to mention you saying that if using OSGi, the classloaders are typically in the same domain with correct import/export rules set? | *How can I access all the rules for import/export for a (sub-)deployment from a deployer? That should give me the information I need about the available options. | The requested rules are on the Module, e.g. importAll, exportAll and requirements/capabilities What they actually get resolved to will only be available on the DependencyInfo (which is really an implementation detail), or by looking at the actual ClassLoaderPolicy used to create the classloader, e.g getPackageNames() and getDelegates(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181046#4181046 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181046

16 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Policy Implementation for VFS

by adrian＠jboss.org

It didn't work when we tried an experiment with an njar url in 3.0.0.alpha View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181044#4181044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181044

16 years, 3 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Reimplementing ClassPools for AS

by kabir.khan＠jboss.com

I'm going to bite the bullet and attempt to reimplement how the JBoss ClassPools work. I am currently working on pre-OSGi with classloaders organised by domains. Although I doubt I will have time to implement the OSGi part before AS 5.0.0.GA I would at least like to add the correct properties to my classes at this stage. A few questions *I seem to mention you saying that if using OSGi, the classloaders are typically in the same domain with correct import/export rules set? *How can I access all the rules for import/export for a (sub-)deployment from a deployer? That should give me the information I need about the available options. >From dev list: anonymous wrote : | On 7 Oct 2008, at 17:25, Adrian Brock wrote: | | anonymous wrote : | | On Tue, 2008-10-07 at 16:56 +0100, Kabir Khan wrote: | | Finally, this still hasn't been updated to understand | | how subdeployment classloaders work. It should be asking | | whether the (sub-)deployment has an | | org.jboss.classloading.spi.dependency.Module | | attachment and hence its own classloader. | | | | Just to be clear, can there be arbitrary levels of classloaders within | | a deployment's sub-deployments now? | | | | That's really two different questions/issues. | | The old HeirarchicalLoaderRepository only supported one level | of hierarchy, but it could only be used with top level deployments. | | The war classloader was a special case, hence all the hacks | you had to do. :-) | | Now the ClassLoaderDomains can go to abitrary levels, | and Subdeployment classloaders are no longer restricted | to just wars. | Subdeployment classloaders are created in their own domains. | | You can determine the rules from the Module attachments | of the deployment structure. | | domain/parent -> result | | 1) DefaultDomain/Nothing -> this is in the default domain | with a parent of the jboss bootstrap classloader | | 2) Domain1/Domain2 -> in domain1 with parent domain2 | This applies to both top level and subdeployment classloaders. | i.e. if a subdeployment specifies a parent domain, it is | not a child of the top level deployment classloader | | 3) Domain1/Nothing -> A subdeployment classloader in domain1 | with a parent domain equal to the subdeployment's parent | deployment's classloader (phew! :-). | | The last one is harder to explain in English, here's an example | which should make it clearer. | | Suppose you have an ear in Domain1, which has | a parent domain of DefaultDomain. | Inside the ear is a war in Domain2. | | Domain2 is not directly a child of Domain1 like (2). Instead it goes | through the ear's classloader. That way it can see | unexported classes in the ear that others in Domain1 might | not be able to see (this is the OSGi stuff again :-). | | NOTE: We may in future support (3) for top level deployments. | i.e. you could have multiple root domains for your classloaders. | That case would be similar to (3) except now the parent | is the jboss bootstrap classloader like (1) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181042#4181042 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181042

16 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Policy Implementation for VFS

by david.lloyd＠jboss.com

"adrian(a)jboss.org" wrote : The default implementation using system properties | http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html | won't understand the vfs urls because the VFS code isn't even in the classpath | when the server boots and reads the file. My understanding may well be flawed, but when I was researching this for secure classloading in Remoting, my conclusion was that the URLs need not be resolvable at load time; rather they are somehow compared against the ClassLoader's CodeSource (by way of the ProtectionDomain used to load each class) at the time the permission is checked, or possibly at the time the class is loaded. I think that as long as the VFS classloader is properly configuring the ProtectionDomain when loading classes, including the proper VFS URL for each class (using one of the ClassLoader.defineClass() methods which accepts ProtectionDomain), it should Just Work, even with the default policy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181035#4181035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181035

16 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Policy Implementation for VFS

by adrian＠jboss.org

I said the jacc stuff would be interesting, but the real issue is making the policy file stuff understand the vfs urls. The default implementation using system properties http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html won't understand the vfs urls because the VFS code isn't even in the classpath when the server boots and reads the file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181028#4181028 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181028

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Security Policy implementation for VFS

by anil.saldhana＠jboss.com

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=143531 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181024#4181024 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181024

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: meeting context

by heiko.braun＠jboss.com

anonymous wrote : | Afaik, but could not find it directly, BPMN is based on structured graphs | Well, we just borrow the terminology (i.e. parallel gateway) and need think about what it means for the implementation. This is exactly the kind discussion I'd like to have. anonymous wrote : | In JPDL 3 it is fully clear, you need a fully nested fork-join pair. This differs from the statement in the workflow patterns for parallel split: | Exactly, hence the need for verification. What you said about previous discussions is something I don't agree with at all: anonymous wrote : | This has been discussed several years ago, so unless bpmn requires otherwise, the decision for this is simple I think ;-) | Let's put it the other way around: Why did all the vendors support workflowpatterns.com [1] and BPMN [2] opposed to jbpm? [1] http://www.workflowpatterns.com/vendors/ [2] http://www.bpmn.org/BPMN_Supporters.htm#current View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181019#4181019 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181019

16 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 2008