[Design of POJO Server] - Pushing correct aspect manager for a deployment
by kabir.khan＠jboss.com
I am working on an edge case for deploying aop in AS using aop-mc-int. I have a deployment1 using default classloading:
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <bean name="GlobalDependency" class="org.jboss.test.aop.scopeddependency.GlobalDependency"/>
|
| </deployment>
|
and a deployment2 using a scoped classloader
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <interceptor xmlns="urn:jboss:aop-beans:1.0"
| name="ScopedInterceptor"
| class="org.jboss.test.aop.scopeddependency.ScopedInterceptor"
| manager-bean="AspectManager"
| manager-property="aspectManager">
| <property name="scopedDependency"><inject bean="ScopedDependency"/></property>
| </interceptor>
|
| <bind xmlns="urn:jboss:aop-beans:1.0"
| pointcut="execution(* org.jboss.test.aop.scopeddependency.ScopedTester->*(..))"
| manager-bean="AspectManager"
| manager-property="aspectManager">
| <interceptor-ref name="ScopedInterceptor"/>
| </bind>
|
| <bean name="ScopedTester" class="org.jboss.test.aop.scopeddependency.ScopedTester"/>
|
| </deployment>
|
ScopedTester is incorrectly deployed since the dependencies are not picked up. The problem seems to be that AOPDependencyBuilder calls AspectManager.instance() which uses TCL to determine the scoped aspect domain to use, however in the DESCRIBE phase this classloader has not been set yet, and so the top-level AspectManager which does not contain the bindings deployed to the scoped aspect domain is used. My deployer has created the scoped aspect domain at this stage, but I need some nice way to make it available to AOPDependencyBuilder. I could push it onto a ThreadLocal, but that might be a bit hacky. What would be nice would be to be able to add it to the bean's MetaData, but as far as I can tell I have no control/access to that, I think the bean's MetaData is created by the BeanMetaDataDeployer? If such a thing exisits, is adding it to the deployments metadata an option? How do I do that?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168481#4168481
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168481
15 years, 9 months
[Design of JBoss Portal] - Permission Issue
by dsulliva
Hi,
I have several portals configured within my JBoss Portal instance.
If for one of the portals I want to give access to Add/Modify content, but not for the others what can I do.
I was thinking that I could use the Roles and Security Permissions but this doesn't seem to work as I would have expected.
Let's say I have two Portals, Portal1 and Portal2. I was thinking that I could leave Portal1 permissions to View Recursive and Personalize Recursive for Role Administrators. Then in Portal2 I could add the AdminPortletInstance to a page. I was thinking this would allow non Administrators access to adding Pages/Content to Portal2, but because they did not have the Administrator Role, they would not be able to see or manage Portal1. After running this test, I was wrong.
So, my question is am I missing something. Or are the security permissions not working the way that I thought they would be.
If there are other ways that I can accomplish this, I'm all ears.
Thanks,
Dave
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168478#4168478
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168478
15 years, 9 months
[Design of JBoss jBPM] - Re: Making the BPM API more generic?
by KrisVerlaenen
"thomas.diesler(a)jboss.com" wrote : Using the BPMN spec we created a model which is meant to accommodate the conceptual constructs from the BPM world
All these constructs sound extremely familiar of course, basically all workflow specifications and languages define these in one way or another. What I don't see is this language is different from for example the jPDL language, WS-BPEL, XPDL or Drools Flow? Why not use an existing process model (and possibly extend that if necesary)?
"thomas.diesler(a)jboss.com" wrote : With respect to DroolsFlow, I would expect that you can map your model to the API model implementing a DialectHandler
This would mean that the common API is some kind of uber process model that can be used to execute any process and that all process languages could be mapped to this language? The PVM idea on the other hand tries to offer the flexibility of different process languages on the same execution platform without having to map everything to one core language. Different contexts typically require different types of nodes: service orchestration is quite different from pipelining events and from healthcare processes for example. Sometimes it's just better to allow users to plug in their own implementation (based on a generic core) than force them to translate to one specific model.
However, regardless of which process model is used internally, I think that it is possible however to define a high-level generic API in how the user interacts with the different BPM components: repository, runtime engine, monitoring, etc.
Kris
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168475#4168475
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168475
15 years, 9 months
[Design of JBoss jBPM] - Re: Making the BPM API more generic?
by tom.baeyens＠jboss.com
"KrisVerlaenen" wrote : I believe that the idea of creating a public API for jPDL or BPM in general is very interesting. We (the JBoss Drools team) try to achieve close integration between processes and rules. A generic BPM API could be very useful here. Our vision is to create a unified platform where rules and processes are simply different ways of expressing (some of your) business logic and can be seamlessly integrated. This would allow users to select the most appropriate paradigm for their problem and integrate rules and processes without requiring them to learn and integrate different products themselves.
|
| This is partially based on the observation that both rules and processes have a very similar life cycle: creation in a custom editor, storing your business logic in a repository, deployment to a runtime environment, monitoring and management of the execution, etc. We believe that is should be possible to offer an unified environment where this life cycle is supported as much as possible and both rules and processes are considered different types of business logic.
|
| Drools has a RuleFlow language (for specifying the order in which rules should be executed using a flow chart) since v4.0 and is now extending that scope to become a more generic workflow language as well, where rules and processes can be integrated seamlessly (called Drools Flow). It would be interesting to see whether Drools Flow (or any other language like e.g. BPEL) can also fit in this common API effort, and maybe in the long term whether we can offer a similar API for both rules and processes.
|
| I think it would be possible to achieve this if we split the API into a more generic part (offering methods to interact with processes of any type) and allow specific process languages (like jPDL3 or 4 or Drools Flow) to extend this API with more specific constructs. For example, different languages would probably have a different process model, but they all could implement a generic process interface. I also believe that the API for interacting with a process engine (starting processes, signalling events , communicating with external services, etc.) can all be made independent of the underlying process model and implementation (the user should not be confronted with these details in most cases). The interfaces defined by the WfMC are a very good example of this.
|
| I'd be glad to provide more details on the different APIs Drools Flow is currently using to communicate with the outside world if needed !
|
| Kris
PVM contains 3 different API views:
1) client
2) activity implementation
3) event listener
In its current shape, Thomas' BPM API has the same scope and target then the client API part (1) of the PVM. I think this is to be considered a learning excercise in Thomas' start to work out the BPM product requirements.
But to answer your question, I think it is always good to compare each other's work. Are your API docs online ? A link would be great.
PVM API lastest version is here: http://docs.jboss.com/jbpm/pvm/api/ This is still in flux, but the next version to a couple of weeks will be pretty much stable.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168469#4168469
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168469
15 years, 9 months
[Design the new POJO MicroContainer] - Re: Controller's execution env
by alesj
"adrian(a)jboss.org" wrote : You just use the kernel as a factory to create a seperate context
| that references the controller. Then you change whatever parameters you like
| (subject to security).
|
|
| | <bean name="ReferenceToController">
| | <constructor>
| | <factory bean="jboss.kernel:service=Kernel"
| | method="getController"/>
| | </constructor>
| | <property name="executor"><inject bean="CustomExecutor"/></property>
| | ...
| | </bean>
| |
|
That's what I said:
"alesj" wrote :
| looks like we might even inject something into the entry
| via some factory
|
;-)
But this wasn't doable until we added BeanKernelRegistryEntry and
actually made it implement InvokeDispatchContext.
"adrian(a)jboss.org" wrote :
| That's why I said that it is probably not required to be on the interface,
| except that it would make programmatic config easier (e.g. testing)
| if you don't have to cast/know the implementation detail.
I'll leave it on the interface - as you said, programmatic usage is much simpler - while it also makes sense as a spi contract.
e.g. Controller has an execution environment ~ executor
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168468#4168468
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168468
15 years, 9 months
[Design of JBoss jBPM] - Re: Making the BPM API more generic?
by thomas.diesler＠jboss.com
anonymous wrote :
| the 'BPM API' is something that is separated from the PVM, since it is a refactoring of jBPM3
|
This is not true. The JBossBPM API, together with its RI and CTS is a separate project with no relation to jBPM3
anonymous wrote :
| I call myself a 'jbpm power-user' since I use it on a daily basis in real-life projects. But I find it quite confusing that these 'BPM API' and 'PVM' ideas seem separated while efforts should be bundled to have a better product. If I'm wrong (which would be good), please correct me.
|
Yes, it'd be good if we could actually see some of the PVM concepts and API - so we can discuss them at a conceptional level. Implementation detail is not useful for that purpose.
CONCEPTS not detail is what needs to be discussed in a early design phase.
The first release of the API will come out 1-Sep-2008
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168462#4168462
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168462
15 years, 9 months