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

[Design of POJO Server] - Re: JSR-299 servlet injection

by alesj

Actually, Emanuel mentioned an existing component factory project: - http://anonsvn.jboss.org/repos/jbossas/projects/component-factory/trunk Scott, what's the status of this? Should I rather work on this instead of integration? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218682#4218682 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218682

17 years

1
0
0 / 0

[Design of POJO Server] - Re: JSR-299 servlet injection

by alesj

"pete.muir(a)jboss.org" wrote : | It also seems deeply bound to EJB3 to me - IMO all that should be needed is the ability to register injection providers which are called for each possible injection point on a bean, with metadata on the injection point passed to the injection provider. I'll see if I can re-factor this into integration project: - http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/ What exactly would you both need on Injector? Or is there anything else that we need? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218668#4218668 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218668

17 years

1
0
0 / 0

[Design of POJO Server] - Re: JSR-299 servlet injection

by pete.muir＠jboss.org

"wolfc" wrote : I don't like the InjectionContainer SPI right now, because it ended up with too much stuff in it. So the current EJB3 model is not sufficient. It also seems deeply bound to EJB3 to me - IMO all that should be needed is the ability to register injection providers which are called for each possible injection point on a bean, with metadata on the injection point passed to the injection provider. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218598#4218598 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218598

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: programmatic passing of environment objects

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : You can skip the 'finally' when using the callback because it's managed outside of the task service: | i don't think so. if the services remain process-engine-context scoped objects, then the callback object would have to be removed just like the provided objects themselves... i think. internally we only have 1 option: use a thread local to pass these objects down till the environment is created. in that case the services can remain process-engine-context scoped. if we use thread locals to pass the user provided objects or the callback handlers, that thread local cleanup is also needed for callback handlers. another alternative would be to create a new service object for each request. but then we would not be able to configure the services. users will not be able to configure customized services. maybe that is an other option to consider. but i don't yet see the full implications of that. feels scary to go that route View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218535#4218535 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218535

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by kabir.khan＠jboss.com

"stale.pedersen(a)jboss.org" wrote : | i made those in the beginning hoping that kabir would finish his classloading stuff before i added this to trunk. We need a release of jboss-reflect before we can start implementing its ClassPoolFactory :-) The implementation in AOP will be very simple | class AOPReflectClassPoolFactoryImpl implements ClassPoolFactory | { | public ClassPool getPoolForLoader(ClassLoader cl) | { | return AOPClassPoolRepository.getInstance().registerClassLoader(cl); | } | } | The question is when/how do we put this into jboss-reflect? Do we initialise it with a bean in AS conf/bootstrap/aop.xml? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218532#4218532 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218532

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: programmatic passing of environment objects

by heiko.braun＠jboss.com

You can skip the 'finally' when using the callback because it's managed outside of the task service: | [...] | finally { | taskService.removeEnvironmentObjects(); | } | Same applies to the lookup key. Using a callback would force the task service to engage the lookup with it's key and not the client environment. | taskService.setEnvironmentObject("authentication", authentication); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218527#4218527 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218527

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: programmatic passing of environment objects

by tom.baeyens＠jboss.com

maybe this is better: TaskService taskService = processEngine.getTaskService(); | | | try { | Authentication authentication = new UserProvidedAuthentication("johndoe"); | taskService.setEnvironmentObject(authentication); | | taskService.take(taskdbid); | | } finally { | taskService.removeEnvironmentObjects(); | } | or by name TaskService taskService = processEngine.getTaskService(); | | Authentication authentication = new UserProvidedAuthentication("johndoe"); | taskService.setEnvironmentObject("authentication", authentication); | | taskService.take(taskdbid); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218520#4218520 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218520

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: programmatic passing of environment objects

by heiko.braun＠jboss.com

Callbacks would be another possibility. Clients would need to provide an implementation of that callback interface: | TaskService getTaskService(CallbackInterface callback); | So, instead of 'pushing' the information into the service, the service would 'callbacl' the client environment when needed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218517#4218517 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218517

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by stale.pedersen＠jboss.org

"alesj" wrote : org.jboss.reflect.spi shouldn't contain Javassist specific classes. | | Make it spi.javassist or something similar. | e.g. we sometimes use helpers pckg i moved the Body implementations to org.jboss.reflect.plugins.javassist. i was kinda uncertain about where they should be placed since they didnt expose any javassist classes and they are needed to use the mutable classes. - but the user need to specify javassist specific implementations when he want to create a mutable object, so i guess it fits in the javassist package too. "alesj" wrote : I guess this is gonna be log.trace or removed? its already removed, totally forgot to remove them. "alesj" wrote : | | public class DummyClassPoolFactory implements ClassPoolFactory | | { | | | | public ClassPool getPoolForLoader(ClassLoader cl) | | { | | return ClassPool.getDefault(); | | } | | | | } | | | Why Dummy if it's default? i made those in the beginning hoping that kabir would finish his classloading stuff before i added this to trunk. when it didnt happen i kept the dummy just to show that this is something that will be changed later. this isnt something that is exposed to the user, so i felt it was ok to just leave it. - its the same code that was used earlier though, so it works like before. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218516#4218516 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218516

17 years

1
0
0 / 0

[Design of JBoss jBPM] - programmatic passing of environment objects

by tom.baeyens＠jboss.com

there are some situations where we need to support passing of environment objects into the service method invocations: * user provided JDBC connection * user provided hibernate session * programmatic specification of the current authenticated user Of coure, we should not add those as optional parameters to all our service method invocations. One solution I thought of was something like this: /** the {@link TaskService task service} that exposes the | * runtime human task lists. */ | TaskService getTaskService(); | | /** the {@link TaskService task service} and supply some | * transactional resources. The given transactional resources will only | * be associated to the returned task service. */ | TaskService getTaskService(Map<String, Object> envObjects); | that way, environment objects could be passed in to the service objects. TaskServices that are created with the second method would typically be used for only one invocation as transactional resources are passed into it. Still trying to figure out how we can cleanly handle typed objects... When the engine e.g. gets the Authentication with Environment.getFromCurrent(Authentication.class) then we should be able to do something like: Map<String, Object> envObjects = new HashMap<String, Object>(); | envObjects.put("authentication", new UserProvidedAuthentication("johndoe")); | TaskService taskService = processEngine.getTaskService(envObjects); | taskService.take(taskdbid); View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218513#4218513 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218513

17 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2009