[Design of POJO Server] - Re: property values in ManagementViewImpl.applyTemplate
by alex.loubyansky@jboss.com
Because, during template's start we create managed properties. That belong to managed objects. So, we create template managed objects before receiving property values from the user. There is no JNDI name at this point.
So, if I just use mo.getName() it will fail to find the MO.
java.lang.IllegalArgumentException: Failed to map key: org.jboss.resource.metadata.mcf.LocalDataSourceDeploymentMetaData to managed attachments for deployment
| at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:624)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:56)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:795)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
| at org.jboss.remoting.Client.invoke(Client.java:1634)
| at org.jboss.remoting.Client.invoke(Client.java:548)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at AOPProxy$1.applyTemplate(AOPProxy$1.java)
| at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.createComponentTest(ProfileServiceUnitTestCase.java:711)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121816#4121816
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121816
18 years, 2 months
[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders
by alesj
"adrian(a)jboss.org" wrote :
| But it's one of those N^2 problems in writing comparators between
| all the different versions, e.g. our own, maven, osgi, java manifest, jdk7 module system, etc.
|
I've taken this approach.
Since I doubt the N will be big. :-)
Adding VersionComparator:
| public interface VersionComparator<T extends Version, U extends Version>
| {
| /**
| * Compare the two version impls.
| *
| * @param t T version impl
| * @param u U version impl
| * @return compare the two version impls
| */
| int compare(T t, U u);
| }
|
and a VersionComparatorRegistry singleton to keep all the known implementations.
And changing the Version class to delegate the compareTo to the registry:
| public int compareTo(Version v)
| {
| VersionComparatorRegistry registry = VersionComparatorRegistry.getInstance();
| return registry.compare(this, v);
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121688#4121688
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121688
18 years, 2 months