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

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - ClassPoolRepository vs JBossclDelegatingClassPoolRepository

by Flavia Rainone

Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion "ClassPoolRepository vs JBossclDelegatingClassPoolRepository" To view the discussion, visit: http://community.jboss.org/message/537974#537974 -------------------------------------------------------------- IMO, the ideal would to be use always ClassPoolRepository and set only the factoy. This would be cleanest possible. But, since the registering of jboss-cl ClassLoaders requires an extra step, we ended up with a JBossClDelegatingClassPoolRepository. My suggestion is to get rid of JBossClDelegatingClassPoolRepository and, instead, change the spi to something like: public class ClassPoolRepository { public void setProfile(Profile profile) } Whereas profile would tell you both the factory and provide an extra plugin class containing any extra steps that may be required for classloader registration. Another option would be keeping ClassPoolRepository the way it is, getting rid of JBossClDelegatingClassPoolRepository, and having the ClassPoolFactory providing a plugin class containing the extra steps required for classloader registration. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537974#537974] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

[JBoss Microcontainer Development] - ClassPoolRepository vs JBossclDelegatingClassPoolRepository

by Flavia Rainone

Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] created the discussion "ClassPoolRepository vs JBossclDelegatingClassPoolRepository" To view the discussion, visit: http://community.jboss.org/message/537965#537965 -------------------------------------------------------------- Since we updated the classpool and AOP versions at JBoss AS, we've been seeing some warning messages showing that unregistering of ClassPool is not working correctly. The reason for these failures is that AspectManager is using ClassPoolRepository to register ClassLoaders, whereas the unregistering of ClassLoaders, performed by RegisterModuleCallback, is using JBossClDelegatingClassPoolRepository. As JBossClDelegatingClassPoolRepository.registeredModules map lacks the the register info, unregisterClassLoader is throwing an exception: public void unregisterClassLoader(ClassLoader classLoader, Module module) { ScopedClassPool classPool = registeredModules.remove(module); if (classLoader == null) { if (classPool == null) { throw new IllegalStateException("Module " + module + " is not registered"); } So, to fix this, AspectManager must start using JBossClDelegatingClassPoolFactory instead of ClassPoolFactory: public ClassPool registerClassLoader(ClassLoader ucl) { return ClassPoolRepository.getInstance().registerClassLoader(ucl); } But this cannot be hard coded because JBossClDelegatingClassPoolFactory provides support to modules and assumes that you are using jboss-cl, which is only true in AS 5/6 environment. When using JBoss AOP in standalone mode or in JBoss AS 4, we need to use ClassPoolRepository. The way that the ClassPool architecture is today, I'll have to make this configurable on the AOP side (e.g., I'll probably add this to AspectManagerJDK5). Is this the best option? Or should we rethink ClassPool architecture, making this configurable on the ClassPool side? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537965#537965] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection

by Flavia Rainone

Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/537959#537959 -------------------------------------------------------------- > Kabir Khan wrote: > > The question is what differentiator to use? A few ideas: > * Keep a counter in Javassist[Method/Field/Constructor]Info and once it has been called several times switch to the generated class. The problem with this is, what if this counter kicks in and we end up generating the class and then we don't have enough subsequent accesses to reap the performance benefits, i.e. in this case it would slow it down. > * Use some annotation to say that for a particular class we should always use generated members. If this annotation comes from MC BeanMetaData it could be put into the TypeInfo attachments. > I vote for using a combination of those two diferentiators. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537959#537959] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection

by Kabir Khan

Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/537944#537944 -------------------------------------------------------------- I've attached the classes I put together for measuring this. I think I included everything needed to make them run, let me know if you have any problems. I used asm 3.2. I haven't looked too deeply into why the performance is different, but I think it is due to how Bytecode and ConstPool make use of ByteVector and LongVector while their asm counterparts seem to modify the byte array directly. Javassist, on the other hand, needs to convert those to create the byte arrays. I have not done any measurements of this, but I guess with things the way they are that once the class bytes are parsed that javassist would be faster for calling things like getMethod() etc.? The reason why this becomes important is that this is something that gets called huge numbers of times. However, there are other problems with this approach of generating accessors with bytecode, which means I am not 100% sure we should go with this approach. This is that we end up with: * having to load a lot of extra classes which takes a lot of time and fills up PermGenSpace * a lot of instances (although the number of instances probably holds true when we just use java.lang.reflect.Method instead) My idea of creating bigger accessors isn't that viable either. If you have a class that has 300 members, but only 30 of those are used with the original method you end up with 30 small classes. With the "bigger accessor" idea, you end up with only one class, but with the code to access all 300 members, so that is a waste of memory. If an accessor is called a lot of times it makes sense to generate a class for it. However, if it is called only a few times, then generating and loading a class for it will be slower due to having to load the class. The main use-cases I know of are: * Configuring the properties of the MC beans. For most bean classes I think each property is only installed once. However, in other cases, e.g. the properties of the beans for the AOP metadata + the beans installed by EJB 3 probably get accessed a lot of times, so for these it would make sense to generate classes. * JBossXB parsing. It is used for parsing the schema, which only happens once, but when parsing the xml files, I think the accessors are used a lot. I think we need some kind of differentiator, so that for accessors that only get called a few times we just go with norrnal reflection, but for heavily used accessors we go with generating the classes. I'll try to come up with some numbers for how many times we need to access the member for generating the class to be the cheapest option. The question is what differentiator to use? A few ideas: * Keep a counter in Javassist[Method/Field/Constructor]Info and once it has been called several times switch to the generated class. The problem with this is, what if this counter kicks in and we end up generating the class and then we don't have enough subsequent accesses to reap the performance benefits, i.e. in this case it would slow it down. * Use some annotation to say that for a particular class we should always use generated members. If this annotation comes from MC BeanMetaData it could be put into the TypeInfo attachments. I will build some statistics into JavassistConstructorInfo.newInstance(), JavassistMethodInfo.invoke() etc. so it is possible to get a report of the type of accessor used and the number of calls to help with being able to tune it using annotations unless somebody has some different ideas. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537944#537944] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [EJB 3.0 Development] - HornetQ Resource Adapter and DLQ handling

by jaikiran pai

jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion "HornetQ Resource Adapter and DLQ handling" To view the discussion, visit: http://community.jboss.org/message/537914#537914 -------------------------------------------------------------- > jaikiran pai wrote: > I am still looking at the hornetq configs in AS and reading through the docs to see how the (hornetq) DLA is being setup. I guess, there needs to be some layer which sets up a (HornetQ) queue subscription to the DLA to make it look like the (JMS) DLQ. More specifically, I am checking how this is any different from a MDB listening to a "normal" queue in HornetQ -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537914#537914] Start a new discussion in EJB 3.0 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [EJB 3.0 Development] - HornetQ Resource Adapter and DLQ handling

by jaikiran pai

jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion "HornetQ Resource Adapter and DLQ handling" To view the discussion, visit: http://community.jboss.org/message/537910#537910 -------------------------------------------------------------- By the way, currently we also allow MDB specific dead letter queue which overrides the global DLQ. We'll have to see how that works out with HornetQ. The entire set of JBoss specific (actually JBM specific) activation config properties are here http://www.jboss.org/file-access/default/members/jbossejb3/freezone/docs/... http://www.jboss.org/file-access/default/members/jbossejb3/freezone/docs/... in the second table. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537910#537910] Start a new discussion in EJB 3.0 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [EJB 3.0 Development] - HornetQ Resource Adapter and DLQ handling

by jaikiran pai

jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion "HornetQ Resource Adapter and DLQ handling" To view the discussion, visit: http://community.jboss.org/message/537907#537907 -------------------------------------------------------------- Actually, there are 2 things to be considered here: 1) Provider specific activation config properties : As Andy says - JBM used to support some of the activation config props which are no longer valid in HornetQ. As Andy and I discussed over IRC, I'll see if EJB3 code mandates some of these properties to be available. If it does, then we will have to move it out of EJB3 (including the related documentation) to make it a JMS provider specific config. 2) The meaning/usage of DLQ : In HornetQ, there are just Dead letter Addresses. But from the point of view of a JMS client (like MDB) which are just aware of (JMS) queues and (JMS) topics, how would they subscribe to a dead letter (JMS) queue. I am still looking at the hornetq configs in AS and reading through the docs to see how the (hornetq) DLA is being setup. I guess, there needs to be some layer which sets up a (HornetQ) queue subscription to the DLA to make it look like the (JMS) DLQ. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537907#537907] Start a new discussion in EJB 3.0 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

[EJB 3.0 Development] - HornetQ Resource Adapter and DLQ handling

by Andy Taylor

Andy Taylor [http://community.jboss.org/people/ataylor] created the discussion "HornetQ Resource Adapter and DLQ handling" To view the discussion, visit: http://community.jboss.org/message/537904#537904 -------------------------------------------------------------- Theres currently an issue with DLQ handling in the HornetQ resource Adapter. Basically we ignore the DLQ settings in the Activation spec. These were only added because there is some code that calls these and sets these with defaults, but basically they are no ops. The problem is that these methods dont really make sense in a HornetQ context, for instance one seting is for the providers JNDI, but in our RA code we dont use JNDI at all, this is so our RA will work with any container. Also we dont have the notion of a DLQ we have a dead letter address which could have n queues bound to it. As far as I can see there are the following solutions. 1. We change the activation spec to have HornetQ specific settings. This means however that apps being migrated will have to be ported. 2. We keep the same spec and handle this at th ejb3 layer. 3. We keep the same spec but change our RA to somehow handle this, altho it would be a huge hack and we dont really want to do this. thoughts guys, any other possible solutions. P.S Jaikirin is looking in the ejb3 code to see where these defaults are set as this would need changing too -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537904#537904] Start a new discussion in EJB 3.0 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss ESB Development] - consume web service with complex data type

by bill zhang

bill zhang [http://community.jboss.org/people/billzhang1123] replied to the discussion "consume web service with complex data type" To view the discussion, visit: http://community.jboss.org/message/537852#537852 -------------------------------------------------------------- After I moved to the next sample, I figured out why this didn't work. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537852#537852] Start a new discussion in JBoss ESB Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

[JBoss ESB Development] - consume web service with complex data type

by bill zhang

bill zhang [http://community.jboss.org/people/billzhang1123] created the discussion "consume web service with complex data type" To view the discussion, visit: http://community.jboss.org/message/537851#537851 -------------------------------------------------------------- I have been playing with webservice_consumer1 sample in JBoss ESB. I modified the sample code to invoke another web service which has an array of string as input parameter along with another String type paramter. Here is my code of process method in webservice_consumer1 MyRequestAction method. No changes on jboss-esb.xml. public Message process(Message message) throws Exception { logHeader(); String msgBody = (String) message.getBody().get(); * HashMap requestMap = new HashMap(); String[] arrayOfStr = new String[2]; arrayOfStr[0] = "b"; arrayOfStr[1] = "b1";* * requestMap.put("sayHello.arg1.name", "vicky"); requestMap.put("sayHello.arg1.kids", arrayOfStr); * *message.getBody().add(requestMap); } *After I ran the SendJMSMessage, on the web service side I can see the incoming value of name which is a String type. However web service can only see the number of elements but not the values. If I use SOAPUI to call the service I can see the array of kids that I send.* *Therefore, I guess the use of 'requestMap.put("sayHello.arg1.kids", arrayOfStr);' is wrong for array as input. Can someone please give me a hint of how to send an array of string using HashMap? Thanks.** * **** * * * * * ** -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/537851#537851] Start a new discussion in JBoss ESB Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

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 April 2010