[Design the new POJO MicroContainer] - Re: scoped contexts example
by adrian@jboss.org
"tom.baeyens(a)jboss.com" [/quote wrote :
| Adrian, this might be interesting for you to have a look at before you start implementing/adding the real thing in the MC.
|
It's already being implemented in the MC, but I've already expressed
concerns that it is being done without reference to the use cases. :-)
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=102686
The other parts of your requirement (passing scopes under the wire)
was done last year, although it is still a very internal/mechanistic api
that needs some helpers/wrappers to make it look pretty. :-)
e.g. Your create a bean from the scoped information:
| "Helper".createBean("name");
|
would translated into something like:
| // Get the scoped metadata attached to the thread
| MetaData scopedMetaData = MetaDataStack.peek();
| // Get the scoped controller
| KernelController controller = scopedMetaData.getMetaData(KernelController.class);
| // Get the factory for the bean from this scope
| BeanFactory factory = controller.getInstalledContext("name").getTarget();
| // Create the bean (do all the inject wiring in the current scope, etc.
| return factory.create()
|
or alternatively you can do more work yourself, e.g.
| // Get the scoped metadata attached to the thread
| MetaData scopedMetaData = MetaDataStack.peek();
| // Get the wiring implementation for this context
| MyWiring wiring = scopedMetaData.getMetaData(MyWiring.class);
| // Do any custom wiring based on the controller and scoped metadata
| KernelController controller = scopedMetaData.getMetaData(KernelController.class);
| return wiring.createBean(controller, scopedMetaData);
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030227#4030227
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030227
19 years
[Design the new POJO MicroContainer] - scoped contexts example
by tom.baeyens@jboss.com
moving mail discussion to forum:
anonymous wrote : On Wed, 2007-03-21 at 12:42 +0100, Ales Justin wrote:
| > > If you could direct me to your (IoC) work, use cases, ... I will have a
| > > look to see more precisely what you may need. And we can discuss this
| > > further (at J1, ...).
|
| Tom wants the scoped kernels so he can setup factories at different
| levels (in particular "runtime scopes" for his jbpm processes).
|
| e.g. Not Tom's exact example, but probably more familiar to
| you from a JavaEE/Seam point of view (note the runtime scopes
| web session and seam conversation).
|
| "Application Scope"
| DataSource - default for the application
|
| "Web Session Scope"
| DataSource -> *override* for the session
|
| "Seam Conversation Scope"
| DataSource -> *override* for the conversation
|
| There's a bit more too it than what I describe, but
| this is the basic mechanism to the solution.
|
| If you want to discuss this further with me, I'll be
| happy to do it in the forums.
| -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx
actually, i have now an implementation with scopes that i'm pretty much satisfied with.
Adrian, this might be interesting for you to have a look at before you start implementing/adding the real thing in the MC.
it's in module lightning of jbpm cvs repo.
src/org/jbpm/ctx --> context and scopes
src/org/jbpm/wire --> wiring
regards, tom.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030208#4030208
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030208
19 years
[Design of JBoss jBPM] - Re: Timer problem in 3.1.4 -- bug or feature?
by tom.baeyens@jboss.com
yes that is expected and not tunable in 3.1.x with configurations only. in 3.1.x the scheduler service (like all other services used by jbpm) are pluggable. so you could build your own scheduler service that e.g. leverages ejbtimer service.
that is exactly what we did added in 3.2.GA, which was just released. in 3.2, the pojo implementation is now multithreaded. and there is also an enterprise service implementation that maps to the enterprise services for async messaging and timers.
there is one known limitation with the enterprise services. because of a limitation in the ejb timer spec, we have to loop over all the timers in case we want to delete one by name during process execution. that might not scale very well in some situations. we are going to work out a solution for this in the next version (by replacing the usage of the timer service of one single SLSB with one entity bean per timer)
hope this gives you some insight
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030138#4030138
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030138
19 years