April 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: AOPConstructorJoinpoint::methodHasAnnotations is wrong

by alesj

"alesj" wrote : | How do we know level hierarchy? OK, ScopeLevel implements Comparable. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140413#4140413 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140413

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AOPConstructorJoinpoint::methodHasAnnotations is wrong

by alesj

"alesj" wrote : | Whether property annotations are put to the wrong place, or we are doing a wrong level lookup. I suspect the other. :-) | Looking at Kabir's comment on recent change: anonymous wrote : | [JBMICROCONT-250] When checking component metadata for a method, only return that we have joinpoint annotations if they exist at instance level or below. | Looks like a case of wrong impl or wrong conclusion on how MetaData.getScopeMetaData(ScopeLevel) works. Should we really always check for all levels below and including INSTANCE? How do we know level hierarchy? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140411#4140411 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140411

16 years, 9 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Problem with MBean

by alesj

I'll move this to user forum - Management, JMX/JBoss. See what the exception tells you - Unable to find operation sftp(). Are you sure you have this exposed as an MBean operation? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140407#4140407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140407

16 years, 9 months

1
0
0 / 0

[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, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Sending SOAP Message through HttpListener rather than JM

by Kevin.Conner＠jboss.com

It is a listener which wraps JBoss Remoting and, at present, provides support for HTTP and socket transports. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140399#4140399 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140399

16 years, 9 months

1
0
0 / 0

[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, 9 months

1
0
0 / 0

[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, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Sending SOAP Message through HttpListener rather than JM

by coejboss

Hi Ema, Thanks for your immediate response but I want to know what actually is a JBRListener? Is it a HttpListener for JBoss? Regards COE-JBOSS View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140380#4140380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140380

16 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Move dependency management back into app server svn stru

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | Anyway, I've given up on this argument. | If you want to integrate against implementation details then don't come crying ... | Well it was nearly my last post. :-) I should have added don't expect or force others to go down the same brain-dead route. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140379#4140379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140379

16 years, 9 months

1
0
0 / 0

[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, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2008