[Design of EJB 3.0] - Re: [long read] Info/help needed on extending EJB3 container
by Sintel
Hey
Took me a while to read up on aspect oriented programming and the aop framework, it was the first time I was confronted with it. Went through the following links to learn (most of which are yours..). Am aware that the first link is outdated when it comes to syntax etc.
http://www.onjava.com/pub/a/onjava/2003/05/28/aop_jboss.html?page=1
http://www.onjava.com/pub/a/onjava/2004/08/25/aoa.html?page=1
http://docs.jboss.org/aop/1.3/aspect-framework/reference/en/html/index.html
http://docs.jboss.org/aop/1.3/aspect-framework/examples/examples.html
I have a pretty good grasp of it now, as much as you can get without doing some actual development with it anyway.
Does all this also mean that I have to throw out the model which I worked out thus far, or only that it is implemented in a different way? I'll lay out a bit more thoroughly how I thought about solving the problem before, as I do not clearly see yet how my old idea maps on the service+aspect, but am getting there. Most of it is repetition from before, but there are a few specific problems highlighted that I see with the change.
The two basic parts of the model I had in mind is extending the container (by the in-between class) to hold and manage multiple implementations of one bean with a certain configuration, and routing the invocation through a dispatcher, which fires the invocation to the beanimplementation it is told to. The selecting of implementation is done by some classes/service instantiated per application, based on external context information for each client and a configuration file that maps context situations to application profiles, so it selects and changes the current implementation per client for each application. There exists one dispatcher for every client, and the client holds a reference to that dispatcher in its proxy, so no lookup of the configuration for that particular client needs to be done serverside (performance). Dispatchers would also be held and created for every client in the container. The deployment plan etc. would need to change of course, but that's a worry for after I get the plumbing of the container done, right now loading a file that describes the configurations and giving the other implementations of the bean is entirely meant to be done by new classes. This all means that stateless interactions aren't really stateless anymore and changing of implementations can be done in a 'safe' way, if no invocations/transactions are running.
When I look at what you wrote, I see the aspect taking over the role of the dispatcher, and using a service to keep all the configurations for each client over all the applications?
Since I'm not a seasoned JBOSS developper, I assume what you mean with a service is what is described in chapter 5 of the document:
http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html_s...
How I see it now, this represents a scaling problem in the real world, where you have a single instance/service keep all the routing information for every client of each reconfigurable application on your server. Maybe the service could make some routing-management instances per application, but in the end the aspect still needs to do a thorough lookup (->service->per application manager->clientID->which implementation for this bean) for each invocation, whereas the dispatcher would just have it's pool/cachereference changed and that's the end of it, invocations go to the right implementation. This is assuming I read your hints right, or did I miss anything? Maybe there's an easy solution.
The next question is, where do I keep the other implementations if not in a specific container extension, or is there a way to expand it? I would like to have the beancontext/cache/pooling abilities if possible... But I can't really deploy every implementation to a different container since the original thesis proposition is supporting adaptation through a container extension, hence the reason why we proposed the requirement of having each beanimplementation have the same containerconfiguration.
Also, org.jboss.ejb3.stateless.StatelessInstanceInterceptor (the current 'implementation selector' -as an example) will probably have to be removed from the interceptor stack and replaced by the new server aspect I assume. There isn't any specific order to the interceptors that will make or break the container currently in the ejb3-..-aop.xml file? I'm asking because, if I change the target of an invocation, will the next interceptor still be run... And uhm lastly, where do I 'deploy' any new server-side aspect :)
Are there any docs on developing a service? Using all the links I found on google regarding developing on JBOSS EJB3 container, none of the eclipse configurations I found recognised the @service tag to start with.
And a stupid one: assuming I have read up on everything I need to and have the right development tools/config, developing an aspect and service to do this and changing the necessary configurations, how much development time would I (only me) be looking at approximatly? A matter of days, weeks or months? :)
Thanks for reading this far, just writing it down brought a lot of insights already. I'm hoping to make significant headway soon :D
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4018734#4018734
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4018734
19 years, 1 month
[Design of POJO Server] - Re: HEAD errors with profile service
by scott.stark＠jboss.org
An example of a full error is this one:
| lController] Error installing to Instantiated: name=JAXWSDeployerEJB3 state=Described
| java.lang.ClassFormatError: Failed to load dyn class: AOPContainerProxy$25
| at org.jboss.aop.deployment.JBossClassPool.toClass(JBossClassPool.java:112)
| at javassist.ClassPool.toClass(ClassPool.java:847)
| at javassist.ClassPool.toClass(ClassPool.java:805)
| at javassist.CtClass.toClass(CtClass.java:1037)
| at org.jboss.aop.instrument.TransformerCommon$ToClassAction$2.toClass(TransformerCommon.java:296)
| at org.jboss.aop.instrument.TransformerCommon.toClass(TransformerCommon.java:127)
| at org.jboss.aop.proxy.container.ContainerProxyFactory.generateProxy(ContainerProxyFactory.java:139)
| at org.jboss.aop.proxy.container.ContainerProxyFactory.getProxyClass(ContainerProxyFactory.java:127)
| at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.generateProxy(GeneratedAOPProxyFactory.java:128)
| at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.getProxy(GeneratedAOPProxyFactory.java:114)
| at org.jboss.aop.proxy.container.GeneratedAOPProxyFactory.createAdvisedProxy(GeneratedAOPProxyFactory.java:83)
| at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:109)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
| at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:52)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:430)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:540)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:474)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
| at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:67)
| at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
| at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:56)
| at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
| at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:121)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:110)
| at org.jboss.profileservice.aop.DeployerAspects.commitDeploy(DeployerAspects.java:159)
| at org.jboss.profileservice.aop.DeployerAspects.invoke(DeployerAspects.java:98)
| at org.jboss.aop.advice.org.jboss.profileservice.aop.DeployerAspects_z_invoke_381299.invoke(DeployerAspects_z_invoke_381299.java)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.profileservice.aop.DeployerAspects.commitDeploy(DeployerAspects.java:159)
| at org.jboss.profileservice.aop.DeployerAspects.invoke(DeployerAspects.java:98)
| at org.jboss.aop.advice.org.jboss.profileservice.aop.DeployerAspects_z_invoke_381299.invoke(DeployerAspects_z_invoke_381299.java)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at AOPContainerProxy$4.commitDeploy(AOPContainerProxy$4.java)
| at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:170)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:592)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:603)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:476)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:406)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:121)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:110)
| at org.jboss.profileservice.aop.MainDeployerAspect.process(MainDeployerAspect.java:53)
| at org.jboss.profileservice.aop.MainDeployerAspect.invoke(MainDeployerAspect.java:46)
| at org.jboss.aop.advice.org.jboss.profileservice.aop.MainDeployerAspect_z_invoke_381299.invoke(MainDeployerAspect_z_invoke_381299.java)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.profileservice.aop.MainDeployerAspect.process(MainDeployerAspect.java:53)
| at org.jboss.aop.advice.org.jboss.profileservice.aop.MainDeployerAspect_z_process_381299.invoke(MainDeployerAspect_z_process_381299.java)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at AOPContainerProxy$7.process(AOPContainerProxy$7.java)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:360)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247)
| at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
| at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
| at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
| at org.jboss.Main.boot(Main.java:210)
| at org.jboss.Main$1.run(Main.java:508)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.ClassNotFoundException: Unexpected error during load of: AOPContainerProxy$25, msg=class AOPContainerProxy$25 overrides final method .
| at org.jboss.mx.loading.UnifiedClassLoader.loadClassImpl(UnifiedClassLoader.java:329)
| at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:409)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| at org.jboss.aop.deployment.JBossClassPool.toClass(JBossClassPool.java:108)
| ... 68 more
| Caused by: java.lang.VerifyError: class AOPContainerProxy$25 overrides final method .
| at java.lang.ClassLoader.defineClass1(Native Method)
| at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
| at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
| at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
| at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
| at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
| at java.security.AccessController.doPrivileged(Native Method)
| at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
| at org.jboss.mx.loading.RepositoryClassLoader.findClassLocally(RepositoryClassLoader.java:569)
| at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:549)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
| at org.jboss.mx.loading.RepositoryClassLoader.loadClassLocally(RepositoryClassLoader.java:193)
| at org.jboss.mx.loading.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:131)
| at org.jboss.mx.loading.LoadMgr3.nextTask(LoadMgr3.java:403)
| at org.jboss.mx.loading.UnifiedClassLoader.loadClassImpl(UnifiedClassLoader.java:296)
| ... 71 more
|
The printed method name is garbage, but the base class does declare deploy/undeploy as final:
| public final void deploy(org.jboss.deployers.spi.deployer.DeploymentUnit)
| throws org.jboss.deployers.spi.DeploymentException;
| public final void undeploy(org.jboss.deployers.spi.deployer.DeploymentUnit);
|
I'll raise this problem with the webservice team.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4018661#4018661
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4018661
19 years, 1 month
[Design of JBoss ESB] - Scripting Language ESB Action
by burrsutter
Purpose: To discuss the design of possible scripting language support in the JBoss ESB (post 4.0 GA)
Groovy scripts can already be used inside of the transformation engine. quickstarts\transform_EDI2XML_Groovy_XSLT illustrates this capability.
Here are the primary questions to be answered when designing a scripting language ESB action:
A- Which scripting languages should be supported? Limit it to Groovy or more?
B- Support for Java 5 and Java 6? Java 6 using JSR 223 introduces the javax.scripting package which allows for plug & play with various scripting engines: https://scripting.dev.java.net/
If Java 5 is a requirement then perhaps we leverage the capabilities of http://jakarta.apache.org/bsf/
C- What should the jbossesb.xml look like (here is an example to start the discussions):
| <action class="org.jboss.soa.esb.actions.ScriptingAction" name="ScriptingAction">
| <property name="scriptEngine" value="MyScriptingEngine"/>
| <property name="scriptName" value="MyGroovyScript.groovy"/>
| </action>
|
D- How should the scripting language interact with org.jboss.soa.esb.message.Message
|
E- What documentation/samples need to be included? At a minimum, a quickstart that illustrates the use of scripting. It should also be "hot redeployable" much like the Rules-based ContentBasedRouting (illustrated by quickstarts\fun_cbr)
F- Any volunteers who wish to pursue this item? If you download the SRC for JBoss ESB you can review:
trunk\product\core\listeners\src\org\jboss\soa\esb\actions
for examples on how to build an "internal" action that would be part of the JBoss ESB download.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4018553#4018553
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4018553
19 years, 1 month