[Design of EJB 3.0] - Re:
by bstansberry＠jboss.com
Looking at the current usage in ejb3-interceptors-aop.xml I don't see anything that looks like changing the value of the attribute of an existing annotation; just the addition of annotations if they are missing. There may be some secret sauce in jboss-aop to do this, although I doubt it. Even if there is, I gotta imagine the xml to specify it would be really complex/breakable.
"scott.stark(a)jboss.org" wrote : Falling back to hard-coded defaults seems ok, but the code that is setting up the proxy factory should be also getting the full configuration setup based on a container default configuration. I'd rather move away from the injected default annotations to a complete pojo metadata model where the "Stateless Bean" aop domain has a complete specification.
|
Yes, the way EJB2 metadata is merged from standardjboss.xml, jboss.xml container-configuration and the bean declaration itself is nice. Obviously EJB3 has different requirements with the use of annotations and nothing like standardjboss.xml.
I'll leave the hard-coded defaults; my concern was less with having those than with launching a discussion on having an external way to change the default.
"scott.stark(a)jboss.org" wrote : The only thing I can see to do here is to change the default to something like DefaultClusteredCache and expect that the factory bean is configured to alias this correctly.
Perhaps "DefaultCache". Al points out this attribute could be consumed by a non-clustered cache as well. A value like that seems better than "" since if we ever wanted to externalize the aliasing its easier to map in xml.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106157#4106157
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106157
18 years, 4 months
[Design of Management Features on JBoss] - Re: Using xinclude in config files
by snacker
I can't get it to work with JBossXB with jboss app server 4.2.2GA:
| 13:08:30,076 INFO [ServiceConfigurator] Problem configuring service jboss.cache:service=CacheA
| org.jboss.deployment.DeploymentException: Exception setting attribute ClusterConfig = [xi:include: null] on mbean jboss.cache:service=CacheA; - nested throwable: (java.lang.StringIndexOutOfBoundsException: String index out of range: -1)
| at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:707)
| at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:332)
| at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:462)
| at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
| at org.jboss.system.ServiceController.install(ServiceController.java:226)
| at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy4.install(Unknown Source)
| at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
| at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
| at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
| at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy9.deploy(Unknown Source)
| at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
| at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
| at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
| at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy4.start(Unknown Source)
| at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
| at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
| 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:597)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy5.deploy(Unknown Source)
| at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
| at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
| at org.jboss.Main.boot(Main.java:200)
| at org.jboss.Main$1.run(Main.java:508)
| at java.lang.Thread.run(Thread.java:619)
| Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
| at java.lang.AbstractStringBuilder.setLength(AbstractStringBuilder.java:143)
| at java.lang.StringBuffer.setLength(StringBuffer.java:153)
| at org.jboss.cache.TreeCache.setClusterConfig(TreeCache.java:847)
| 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:597)
| at org.jboss.mx.interceptor.AttributeDispatcher.invoke(AttributeDispatcher.java:136)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:103)
| at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:461)
| at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:608)
| at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:703)
| ... 83 more
|
I will try the beta2 version, since you said it is only supported in the "most recent" version.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106128#4106128
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106128
18 years, 4 months
[Design of POJO Server] - Re: Proper definition of embedded jboss
by bill.burke＠jboss.com
http://wiki.jboss.org/wiki/Wiki.jsp?page=EmbeddedJBoss
Use cases in order of importance (in my opinion):
1. Junit testing "outside" of application server. This means making it as easy as possible in IDE's to right click on a set of unit tests and just run them from the IDE without any special IDE plugins
2. Small lightweight SE apps that can boot quickly and in which the app developer controls directory structure, and bootstrapping.
3. Tomcat integration and abstraction. Ability to provide JBoss projects a la carte to Tomcat.
4. App server abstraction. Framework to provide other JBoss projects with an easy way, common way to plugin into other application servers.
If you look at the embedded project, there's really not much code. A lot of it is to work around old JMX Microcontainer issues, or issues with Tomcat. This codebase should be getting smaller, faster, and simpler over time as we convert older jboss projects to use the new kernel
API:
There's only a few exposed APIs. Specifically a bunch were written that ease-of-use wrappers around the MainDeployer to provide a programmatic API for users to this service. Specifically:
org.jboss.embedded.Bootstrap
org.jboss.embedded.DeploymentGroup
There's also VFS apis that should be exposed and supported, specifically the:
org.jboss.virtual.plugins.context.vfs.AssembledContextFactory;
org.jboss.virtual.plugins.context.vfs.AssembledDirectory;
CONFIGURATION:
Configuration should be no different than JBOSS AS, except that maybe we don't want to ship with the profile service or management layers. (Also, see refactoring comments below, specifically point #7
TESTING:
I also worked on an extension to JBoss Test framework that could take existing JBoss unit tests and run them within embedded. This worked by subclassing existing Junit tests and running with the embedded container. Of course, you couldn't work with tests that required non-jar file formats or special classloading features as embedded is supposed to work in the environments classloader. As many of these tests should be converted so that we are sure various JBoss components do not require special app server configurations.
WHAT REFACTORINGS SHOULD BE DONE:
The embedded project should be a very small project. If the rest of JBoss is designed correctly, the embeded project should really just be a packaging and integration project. Integration being whatever bridges that need to be built to environments we want to run in.
IMO, most of the refactorings that should be done are not within embedded.
1. Gut the requirement for special protocol handlers for URLs (i.e. "vfsfile:", "resource:"). What sucks about the JDK is that once the URL Handler factory is set, you can never unset it. This required me to hack Tomcat to allow our deployment system to work.
2. For the VFS provide default behavior for when it doesn't recognize a URL protocol. Like, for instance, following the rule of if the URL ends in "/", then abort, if not, treat the VFS root as a JAR.
3. Allow injectable MBeanServer. Currently, we have a hard dependency on the JBoss JMX implementation mainly because we put JBoss specific mbeans within private JMX namespaces (like the MBeanRegistry).
4. Move old services over to the new kernel and beans.xml format wherever possible.
5. Improve bootstrap times. Previously 20% of embedded boottime was within all the JAXB shit you guys do. Would be cool if we could precalculate and persist models at build time, rather than at runtime.
6. Refactor Seam so that it as a JBoss Kernel deployment component. This is going to become more and more important as we get to the deployment model we want to get to. That is, a model where you just throw a bunch of shit in your WEB-INF/lib or classpath and everything just works.
7. Seam is an interesting model in that everything is turned on by default (they have to do this model because all their services are defined using annotations). To turn things off you explicitly turn them off within a configuration file. If you want to tweak a service's default configuration, you again, have to do this in a specific central configuration file. WHY IS THIS A GOOD THING? Well, if JBoss MC allowed this, the Embedded packaging could be just everything JARRED up in one jar that is put in the user's Classpath. No exposed configuration files or directory structure. If the user wants to turn off/configure things, they just add a bit of configuration to the area's they are used to tweaking.
INTEGRATION PLUGINS:
* SE (already discussed)
* Junit (already discussed)
* Tomcat. Please read the issues I encountered in the embedded wiki. I got a lot of shit from the Seam division for how I did the Tomcat integration. Some of it was unavoidable (specifically, the URL Handler junk), others, specifically the JNDI hacks could have been avoided, but the consequence would have been changes throughout the JBoss AS codebase. Changes I was unwilling to do. The whole idea of embedded is that we should have to have a whole team dedicated to maintaining it because it would be a thin packaging around the AS distribution. The less code that's in embedded, the better it is.
* Other app servers. If done correctly, JBoss AS should be reusable in other application server environments. We should be able to use the environments TM, JNDI, etc. services. But I think this should be a LOW PRIORITY. Given resource constraints, we'd need at least one dedicated person on embedded to be able to make this a reality.
Well, that's all I can think of right now....
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106121#4106121
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106121
18 years, 4 months