February 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: [JBMESSAGING-1367] Create JCA resource adapter for JBM 2

by ataylor

he's a summary of what i've found so far. JBMResourceAdapter:setup(). I'm not sure we need the constructors that use discoveryaddress, discoverygroupname etc. We should always fall back to a default something like this: | else | { | HashMap<String, Object> params = new HashMap<String, Object>(); | params.put("jbm.remoting.invm.serverid", 0); | factory = new JBossConnectionFactory(new TransportConfiguration("org.jboss.messaging.core.remoting.impl.invm.InVMConnectorFactory", params)); | } | Since we always use the local transport it should always be the invm transport and the default server id is 0. Things like block on acknowledge should also be supported and if not we gfall back to the defaults in ClientSessionFactoryImpl. There was a slight issue at JBMMessageHandler line 387 where getTransactionTimeout() was returning null and throwing a NPE. We should change this to Integer and only set the tx timeout if not null. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210817#4210817 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210817

17 years, 1 month

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Reimplementing AspectManager/Domains to understand jboss-cl

by kabir.khan＠jboss.com

I have almost completed the reimplementation of the classpools http://www.jboss.org/index.html?module=bb&op=viewtopic&t=143639 To understand the classloading rules used in JBoss AOP, all that is outstanding is a bit of work in AS 5 which will be possible following the upgrade to jboss-cl 2.0.3.GA. The next part is to reimplement the AspectManagers and Domains that are used in AOP to understand the classloading rules. Before I start, here is how the classloader scoping currently works. It works by classloader domain, and the deployment containing AOP information determines where the AOP information is deployed. For woven classes, the classloader domain of its loading class determines which AOP information is applied to that class. Currently, if a deployment is not scoped (i.e. the classloader belongs to the default domain) the AOP information is deployed to the main AspectManager. The AOP information used is shared among all classes loaded by classloaders belonging to the default domain. If a deployment is scoped (i.e. the classloader belongs to a child of the default domain) the AOP information is deployed to an AOP Domain, which is mapped onto the classloader Domain. Again, all the information deployed into that AOP Domain is applied to all classes loaded by classloaders belonging to the corresponding classloader Domain. Domains are hierarchical with a parent link that takes you to the parent Domain, with the "root" the main AspectManager. A child domain will inherit AOP information from its parents in this scenario with parent-first/-last ordering controlled by the behaviour of the classloader Domain. In a nutshell, everything is visible to everything else that belongs to that classloader domain, which is fine at the moment since to my knowledge nobody is really using the more advanced features of the classloaders in AS 5 yet. With the new classloaders there can be some visibility constraints between classloaders deployed within a domain, making us need some way to define what AOP information is visble between different loaders. There are a few main use-cases and scenarios in which jboss aop is deployed, I will try to outline some problems I can see at the moment wrt how these are deployed, assuming that there are two classloaders deployed to a classloader domain, where: | ClassLoader A: | Imports: pkg.b | Private packages: pkg.a | | ClassLoader B: | Exports: pkg.b | ImportAll: false | The main problem I can see is with AOP "introducing" new classes to the woven POJOs. In the examples given the new classes are from added interceptors, but the same holds true for interface introductions, mixins, annotation-introductions, metadata-loaders etc. 1) AOP deployed as part of a standalone jboss-aop.xml ===================================================== Assuming that the classes have been prepared, an -aop.xml file is deployed containing binding information that is used to apply bindings to the classes. What happens is a) New class is visible from the affected classes classloader | <bind pointcut="all(pkg.a.PojoA) OR all(pkg.b.PojoB)"> | <interceptor name="pkg.b.MyInterceptor"/> | </bind> | This should work out of the box since CL B has the pkg.b.MyInterceptor class , and it can be seen from both PojoA's loader (CL A) and PojoB's loader (CL B). b) New class is not visible from the affected classes classloader | <bind pointcut="all(pkg.a.PojoA) OR all(pkg.b.PojoB)"> | <interceptor name="pkg.a.MyInterceptor"/> | </bind> | Here PojoA would get the extra interceptor, PojoB's would currently cause an error since pkg.a.MyInterceptor cannot be loaded from CL B. 2) AOP deployed as part of a deployment ======================================= An .aop file is deployed containing a META-INF/jboss-aop.xml file that is used to apply bindings to the classes. Normally, this should contain the interceptor classes (discussed below) , but could also refer to external classes (which is discussed in point 1 above) a) New class is visible from the affected classes classloader Deployment against CL B contains a .aop file containing the following | <bind pointcut="all(pkg.a.PojoA) OR all(pkg.b.PojoB)"> | <interceptor name="pkg.b.MyInterceptor"/> | </bind> | This will work since pkg.b.MyInterceptor is visible from both CL A and CL B. b) New class is not visible from the affected classes classloader Deployment against CL B contains a .aop file containing the following | <bind pointcut="all(pkg.a.PojoA) OR all(pkg.b.PojoB)"> | <interceptor name="pkg.a.MyInterceptor"/> | </bind> | Here PojoA would get the extra interceptor, PojoB's would currently cause an error since pkg.a.MyInterceptor cannot be loaded from CL B. c) New standalone class is not visible from the affected classes classloader If I deploy a c.aop on its own that gets the classloader CL C deployed against the same domain as A and B, containing | <bind pointcut"all(pkg.a.PojoA) OR all(pkg.b.PojoA)"> |  | <interceptor name="pkg.c.MyInterceptor"/> | </bind> | As far as I can tell, neither CL A nor CL B will be able to load pkg.c.MyInterceptor? I am slightly unsure what happens when the classes are woven in the examples given. When weaving PojoA, that gets additional interfaces such as the the org.jboss.aop.Advised interface, references to org.jboss.aop.Advisor etc., which I am not sure off the top of my head are visible from CL A? In the examples I gave, JBoss AOP will currently throw an error if a required interceptor class cannot be found. A few ideas to fix this is I) Swallow Exceptions If an interceptor class or introduced interface cannot be found, just log the error and continue. I don't think that is a good thing though, but included it for completeness. II) Use a special classloader for interceptors etc. A special aop classloader could be used for the aspects at runtime, but that would require changes to the woven code to set the correct classloader, which we don't really want to do when weaving/running outside of the AS. Also, as in the cases of interface introductions the interface/mixin must be visible when the class is loaded. III) Somehow make new classes from AOP globally visible How? IV) Set up delegating AOP domains for each class(loader) Instead of giving a reference to the whole AOP Domain when getting the domain for a classloader, it should return a AOPClassLoaderManager that is unique to that classloader, and contains the things from the underlying AOP Domain that are visible from the classloader. For example in 2b) above the AOPClassLoaderManager for CL A would contain the binding, while the AOPClassLoaderManager for CL B would not contain that particular binding. I am unsure how that would work for 2c) if pkg.c.MyInterceptor is not visible from CL A or B? While this might be another flavour of "Swallow Exceptions", at least we could include some management capability to see what exists in the classloading domain vs what is visible from the classloader. As to how to use these rules in the domains, we were able to delegate a lot of work for the classloading rules to jboss-cl. Maybe the easiest is to do the same here as well? When adding a binding or something else that needs to load a class make sure that the AOPClassLoaderManager is able to load up that class using its classloader, and if not blacklist that binding? When a classloader joins the classloader Domain later, recheck all the AOP Domain's blacklisted bindings etc. and unblacklist the newly found ones? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210816#4210816 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210816

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Logging integration requirements

by david.lloyd＠jboss.com

"bstansberry(a)jboss.com" wrote : Just an FYI in case relevant: the AS uses a forked version of commons-logging, particularly the Log4jLogger class. And, at least for a portion of startup, JBossTS programatically sets the default implementation of the commons-logging Log interface, setting it to com.arjuna.common.internal.util.logging.jakarta.Log4JLogger. | | A thread where some issues related to that were discussed: | | http://www.jboss.org/index.html?module=bb&op=viewtopic&t=129207 | Ugh. I remember this problem, but I didn't remember that the solution was such crap. Well, one good thing about the MC is that we can just give JBossTS its own commons-logging instance. That might just be the solution - isolate it and let it do its own thing. I'll look more once I get closer to completing the integration... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210812#4210812 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210812

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: logging too verbose

by david.lloyd＠jboss.com

Since this problem only applies to JBTM in the AS, why not have a deployed logger filter that does this conversion just for the JBTS logging category(/ies), rather than fiddling with clogging? This is purely a configuration issue afaict. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210808#4210808 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210808

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBREFLECT-50, determining need for setAccessible bug

by scott.stark＠jboss.org

A problem with the workaround of obtaining the BeanInfo using the interface the bean implements is that the IntrospectionTypeInfoFactoryImpl.getSuperClass does not return the superinterface for an interface. Obtaining a BeanInfo for an interface like java.lang.management.GarbageCollectorMXBean which extends java.lang.management.MemoryManagerMXBean fails to include the MemoryManagerMXBean properties: | public void testGarbageCollectorMXBeanIface() | throws Throwable | { | BeanInfo info = super.getBeanInfo(GarbageCollectorMXBean.class, BeanAccessMode.ALL); | PropertyInfo name = info.getProperty("name"); | assertNotNull(name); | } | | ... | | java.lang.IllegalArgumentException: No such property name for bean java.lang.management.GarbageCollectorMXBean available [collectionCount, collectionTime] | at org.jboss.beans.info.plugins.AbstractBeanInfo.getProperty(AbstractBeanInfo.java:147) | at org.jboss.test.beaninfo.test.PlatformMXBeanTestCase.testGarbageCollectorMXBeanIface(PlatformMXBeanTestCase.java:47) | name is a property in the MemoryManagerMXBean interface. Is this expected or a limitation of the current BeanInfo reflection implementation? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210804#4210804 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210804

17 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: [JBAS-6519] JCA / XAResourceRecovery

by adrian＠jboss.org

You only need to return one XAResource and it shouldn't be one from the pool. Go back a few years and read the discussions between Bill and myself about this. There are complications, especially relating to security. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210797#4210797 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210797

17 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - [JBAS-6519] JCA / XAResourceRecovery

by jesper.pedersen

I have started looking into this task which builds on the discussion in the thread http://www.jboss.com/index.html?module=bb&op=viewtopic&t=100435 The org.jboss.tm.XAResourceRecovery interface specifies that registered components should return an array of XAResource objects. We have access to the XAResource objects in the org.jboss.resource.connectionmanager.TxConnectionManager class where they are handled through ManagedConnection.getXAResource() or at the ConnectionListener level - optional wrapped by the org.jboss.tm.XAResourceWrapper interface providing more information about the underlying EIS. Getting the array of XAResource objects should be handled in such a way that it doesn't block the operation of the TxConnectionManager. Btw - I don't see an usage of the org.jboss.tm.XAResourceWrapper interface in the transaction trunk/ module. Is this correct ? As the current JCA implementation isn't fully exposed through the *-jboss-beans.xml - I would say that the hooks into the org.jboss.tm.XAResourceRecoveryRegistry should be handled using reflection in the startService() / stopService() method calls. Feel free to add feedback. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210792#4210792 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210792

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Kernel beans initialization in JBossAS

by adrian＠jboss.org

If I understand it correctly, this could just go in deployers.xml alongside the other bean deployment stuff? Now there could be a case for further modularising deployers.xml, but until we really get to the stage where parts of the file are truly optional, I don't see the point? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210784#4210784 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210784

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Logging integration requirements

by bstansberry＠jboss.com

Just an FYI in case relevant: the AS uses a forked version of commons-logging, particularly the Log4jLogger class. And, at least for a portion of startup, JBossTS programatically sets the default implementation of the commons-logging Log interface, setting it to com.arjuna.common.internal.util.logging.jakarta.Log4JLogger. A thread where some issues related to that were discussed: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=129207 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210781#4210781 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210781

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Kernel beans initialization in JBossAS

by dimitris＠jboss.org

Is kernel.xml a good name for that (I don't know :) In any case, this looks more like a change for 5.1 not 5.0. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210780#4210780 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210780

17 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009