[Design the new POJO MicroContainer] - AOPConstructorJoinpoint::methodHasAnnotations is wrong
by alesj
When doing a check if current underlying context needs to be instantiated as an AOP proxy, we were looking in both cases - class and methods - if there is an INSTANCE scope metadata present.
But in case I have this, adding annotations to property:
| <bean name="Bean6" class="org.jboss.test.microcontainer.support.SimpleBeanImpl">
| <property name="property">
| <annotation>@org.jboss.test.microcontainer.support.SomeNonIA</annotation>
| <annotation>@org.jboss.test.microcontainer.support.ContainsIA</annotation>
| <value>123</value>
| </property>
| </bean>
|
this is called - a place where this xml annotations get put into metadata:
KernelScopeInfo
| /**
| * Add annotations for a method
| *
| * @param classloader the classloader
| * @param mutable the mutable metadata
| * @param methodInfo the method info
| * @param annotations the annotations
| */
| private void addAnnotations(ClassLoader classloader, MemoryMetaDataLoader mutable, MethodInfo methodInfo, Set<AnnotationMetaData> annotations)
| {
| ScopeKey scope = new ScopeKey(CommonLevels.JOINPOINT_OVERRIDE, methodInfo.getName());
| MemoryMetaDataLoader loader = new MemoryMetaDataLoader(scope);
| addAnnotations(classloader, loader, annotations);
| mutable.addComponentMetaDataRetrieval(new MethodSignature(methodInfo), loader);
| }
|
Property annotations are added to JOINPOINT_OVERRIDE level, not to INSTANCE.
So, this really never worked in AOPConstructorJoinpoint - to get a proxy for beans that have annotations added to methods via xml.
Whether property annotations are put to the wrong place, or we are doing a wrong level lookup. I suspect the other. :-)
I'll fix code to use JOINPOINT_OVERRIDE level when checking whether methods have 'instance' metadata.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140406#4140406
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140406
16 years
[Deployers on JBoss (Deployers/JBoss)] - Problem with MBean
by Sudharshans
Hi,
I tried to run MBean in jboss , i tried created MBean and Impl class
with jar file and created sar.
We deployed the .sar file in the $JBOSS_HOME/server/default/deploy
We had the required classes in the WEB-INF/classes and the JNDI properties are also
present in the same location.
Now through JBoss console we are able to invoke the MBean and are able to place the .
file in the local SFTP server.
Still while invoking through in app, it is giving âunknown operation sftp()â¦â error.
java.lang.IllegalArgumentException: Unable to find operation sftp()
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:231)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:175)
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.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195)
at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
at $Proxy60.sftp(Unknown Source)
at com.trilliantnetworks.svc.NUbiapps.impl.SFTP.testConnection(SFTP.java:57)
at com.trilliantnetworks.svc.servlet.ConfigParams.doUpdateConfigParams(ConfigParams.java:140)
at com.trilliantnetworks.svc.servlet.ControllerServlet.doPost(ControllerServlet.java:113)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Unknown Source)
Please give replay with any suggestions.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140398#4140398
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140398
16 years
[Design of Security on JBoss] - Security and JCA
by adrian＠jboss.org
I've just reinstated org.jboss.security.Util which is used by a JCA login module (PBE)
that hadn't been ported to jboss-head.
On a more general note:
We've had this discussion on the jca forum and basically we don't understand
why there are login modules in the connector project?
All we want is to inject a Subject factory into the connection manager.
So we should have is some kind of interface in jboss-integration/jca-spi
(or maybe it should belong in a security integration spi?)
| public interface SubjectFactory
| {
| Subject getSubject();
| }
|
None of jboss security specifc code (login modules, crypto calls, etc.)
should be in the connector project at all.
Can we get this fixed for JBoss5?
The JCA login modules aren't exactly JCA specific. :-)
They are things like login with a given identity or take it from the thread assocation, etc.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140394#4140394
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140394
16 years
[Design of JBoss Build System] - Re: Move dependency management back into app server svn stru
by adrian＠jboss.org
This forum software is getting really buggy.
Here's my last comment in a seperate comment.
anonymous wrote :
| "adrian(a)jboss.org" wrote :
| | 5) The correct way to integrate things is via interfaces NOT implementations.
| |
| If you mean public API/SPI then I completely agree with you.
|
| The main problem I see is that AS trunk defines facilitating components which are used by a lot of projects (not just EJB 3) (dare I mention jboss-as-aspects ;-) ). As Andrew says, we're just the messengers.
|
Messengers from whom?
Can you imagine what would happen if everybody took your approach.
How would this mechanism scale to 10 or 20 component projects
all wanting to try to go in lock step with AS dependencies but still claim their own
independent status?
Anyway, I've given up on this argument.
If you want to integrate against implementation details then don't come crying
to me when it all breaks or you find its very difficult to do.
I've worked on that kind of software before, eventually you get to a point where
you can't change anything for fear of knocking over the whole house of cards.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140369#4140369
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140369
16 years