[Design the new POJO MicroContainer] - Re: ClassPool for JBoss Reflection
by flavia.rainone＠jboss.com
"Kabir" wrote : Do you mean this:
|
| | protected boolean convertReferences(CtClass clazz, ClassAdvisor clazzAdvisor) throws Exception
| | {
| | boolean converted = false;
| | String ref = null;
| | try
| | {
| | AOPClassPool pool = AOPClassPool.createAOPClassPool(clazz.getClassPool(), AOPClassPoolRepository.getInstance());
| |
| It is something I've always assumed was there for a reason and taken for granted since it has been there since before my time. However, all that seems to do is to delegate to the parent classpool so maybe it can be removed and clazz.getClassPool() can be used?
I'll test that and see what happens.
"Kabir" wrote :
| It looks like StandaloneClassPool(Factory) is used when run standalone, i.e. in the testsuite. But that can maybe live in AOP?
Yes, that's what I'm thinking. The whole point here is that if JBoss Reflection is used with a standalone application, the javassist ClassPool can be used.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4243558#4243558
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4243558
17 years
[Design of JCA on JBoss] - Re: Implement WorkContextProvider Check
by gurkanerdogdu
anonymous wrote : Figure 11-1 shows that the getWorkContexts() method is called by the WorkManager after the Work instance has been submitted by doWork(), startWork() and scheuleWork().
|
| Chapter 10.3.3.5 states that a WorkCompletedException can be thrown with an appropriate error code which in this case is one of the WorkContextErrorCodes.
Then, place that I put "setupWorkcontext" is wrong. I have to setup work contexts just before "Work" is run by the "WorkManager".
In current codebase, it seems that there are several different methods that are responsible for setting up "ExecutionContext", namely "WorkManagerImpl#importWork" and "WorkManagerImpl#startWork". *Import* work is called by the "doWork()..." methods but *Start* work is called from "WorkWrapper#execute" method. But according to the spec., context has to be setup after *Work* is accepted and just before it is run. Then it seems that current implementation is wrong because context is imported before submitting work instance via "importWork" method.
AFAIK from the specification, execution context is setup in "start" phase of the work lifecycle (submit->accept->start). And again according to the specification, if execution context is not setup succesfully within "start" phase, it throws "WorkCompletedException".
But in WrapperImpl#execute method, it first calls "WorkManagerImpl#startWork" to do some execution context specific actions. If it gets exception it throws WorkRejectedException, otherwise it calls "run" method of the work instance. But spec says to throws WorkCompletedException.
Sorry for pollution, but I do not exactly understand which methods in the codebase correspond to work's lifecycle phases "submitted, accepted, rejected, started and completed". Therefore, I do not know where to put "setupWorkContext" implementation.
Morever, I guess that current execution context setups has to be changed also using new work context provider semantic. Effected places are "WorkManagerImpl#importWork,startWork, cancelWork,endWork" methods.
anonymous wrote : There is a bit more work in regards to custom contexts if you see the last paragraph in 11.4.2 - the container must always check the most specific context first - and then go up the in hierarchy to find a supported one.
|
Specification says that this must done by the resource adapter before it submits work instance to the server via BootstrapContext#isContextSuported.
I think that this is not related with the application server. Currently, I checked specific context support via method "WorkManagerImpl#getSupportedWorkContextClass(Class". This method checks given context class with application server supported context classes using ".equals". If it does not support specific instance, it falls through "super class" of the adaptor context class.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4243554#4243554
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4243554
17 years
[Design of JCA on JBoss] - Re: Implement WorkContextProvider Check
by jesper.pedersen
Figure 11-1 shows that the getWorkContexts() method is called by the WorkManager after the Work instance has been submitted by doWork(), startWork() and scheuleWork().
Chapter 10.3.3.5 states that a WorkCompletedException can be thrown with an appropriate error code which in this case is one of the WorkContextErrorCodes.
There is a bit more work in regards to custom contexts if you see the last paragraph in 11.4.2 - the container must always check the most specific context first - and then go up the in hierarchy to find a supported one.
You can just attach a single patch with all the changes needed if you don't want to split the patch into separate pieces. And more tests are always good :)
You can get additional checkstyle checks by uncommenting
| <module name="UnusedImports"/>
|
in tools/checkstyle/checkstyle.xml. A couple of checkstyle bugs does that we can't enable this module by default at the moment.
Thanks for your contributions !
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4243531#4243531
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4243531
17 years