[Design the new POJO MicroContainer] - aop-mc-int tests with maven
by kabir.khan@jboss.com
I'm seeing a load of failures here that worked before the maven integration (the output really, really sucks, and yes I have read the thread about the surefire plugin)
The test classes fall into 3 categories:
1) Tests that should be run without any special classloader/weaving set up
2) Tests that should be run with a special classloader/weaving set up
3) Tests that should be run both with and without special classloader/weaving set up
There were 4 sub-targets of test in the old ant build-test.xml
a) Run classes 1) and 3) with no security enabled, and no weaving
b) Run classes 1) and 3) with security enabled, and no weaving
c) Run classes 2) and 3) with no security enabled, and weaving
d) Run classes 2) and 3) with security enabled, and weaving
Can this be replicated sometime soon?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039875#4039875
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039875
18 years, 11 months
[Design of JBoss Portal] - Exception while deploying IPC Portlets
by davidson
Hi,
I am new to the JBoss and Portals. I was trying portal IPC in 2.6 Alpha Server, but getting the following exception while starting the server. Kindly help on this...
Exception
=========
20:11:45,015 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml
20:11:48,906 ERROR [MainDeployer] Could not create deployment: file:/D:/David-Projects/JBoss/jboss-portal-2.6-ALPHA1/server/default/deploy/HelloIPC.sar
org.jboss.deployment.DeploymentException: No ClassLoaders found for: org.jboss.portal.common.system.JBossServiceModelMBean; - nested throwable: (java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.portal.common.system.JBossServiceModelMBean)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:196)
at org.jboss.system.ServiceController.install(ServiceController.java:226)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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 $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039869#4039869
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039869
18 years, 11 months
[Design of JBossCache] - Re: Channel creation - mux vs. old style
by bstansberry@jboss.com
It's really just a matter of whether we want to support a bit of convenience code. My inclination is to think we shouldn't as it's just cruft. But I don't feel that strongly about it.
I don't know that much about what kind of facilities other environments offer.
a) Can they parse a deployment descriptor (a la -service.xml, but their format), use it instantiate a pojo (aka CacheLegacyJmxWrapper) and inject config elements into it and then register that pojo in JMX?
If no, then the user is going to have to deal with JMX themselves anyway (programatically). In that case, providing a convenience method doesn't buy much. User still has to provide us a ref to the MBeanServer and the ObjectName of the JChannelFactory. They just avoid the trivial lookup call.
If yes to a), then
b) Does the facility in a) have the ability to inject complex mbeans a la the AS's "depends optional-attribute-name" feature?
If yes, then it's the same case as JBoss AS -- they should just inject the JChannelFactory.
If no, then we have a use case for JMX lookup.
If we do decide to support this, the ObjectName should be removed from Configuration, and be added as an attribute of CacheLegacyJmxWrapper (or maybe CacheJmxWrapper). That object then does the lookup during it's create call, and injects the JChannelFactory into the Configuration.
This will only work if user registers the CacheJmxWrapper in JMX before calling create(). Otherwise, no MBeanServer will be available to CacheJmxWrapper to do the lookup. I definitely think we shouldn't support attempting to find a JMX server the way we do in 1.4. That just leads to trouble. If people want JMX, they register the wrapper; wrapper gets a preRegister callback during registration, and from that the wrapper has a ref to the MBeanServer to use to register cache internals like the interceptors.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039849#4039849
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039849
18 years, 11 months