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

[Design of JBoss/Tomcat Integration] - Re: java2ClassLoadingCompliance

by scott.stark＠jboss.org

"dimitris(a)jboss.org" wrote : Regarding http://jira.jboss.com/jira/browse/JBAS-3047, I did some adjustments on top of Scott's changes, that I want them to be reviewed. | | They way I understand it is: | | a) To use the jboss web loader, either it has to be configured as the default setting for tomcat, OR a <loader-repository> entry in jboss-web.xml will activate it. In this case the parent/child first classloading behaviour is controlled by loader-repository java2ParentDelegation, and the java2ClassLoadingCompliance flag is ignored, e.g: | | | <class-loading java2ClassLoadingCompliance='false'> | | <loader-repository>dot.com:loader=unique-archive-name | | <loader-repository-config>java2ParentDelegaton=true | | </loader-repository-config> | | </loader-repository> | | </class-loading> | | | | b) if the web loader is used, then jboss-web.xml can override the tomcat configured default java2ClassLoadingCompliance setting, e.g: | | | <class-loading java2ClassLoadingCompliance='true'> | | | | Is this correct? Yes, currently, but you should be able to use either the config you show, or something like: | <class-loading java2ClassLoadingCompliance='true'> | <loader-repository>dot.com:loader=unique-archive-name</loader-repository> | </class-loading> | to create a UCL that is not scoped. There is inconsistent handling of the UCL creation in the LoaderRepositoryFactory for this though. It defaults to a scoped ULR, and requires a ctor that does not exist in the unscoped ULR. The WebIntegrationUnitTestCase.testJava2ClassLoadingComplianceOverrideULR is failing because of this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041893#4041893 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041893

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Problem with performance tests

by timfox

You are probably using the JBoss Messaing client side libraries to attempt to do stuff with JBoss MQ. You need to use the JBoss MQ client side libraries with JBoss MQ. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041890#4041890 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041890

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Problem with performance tests

by sergeypk

I'm trying to get the performance framework to work and I'm having a problem with this JNDI lookup in JobSupport.initialize: destination = (Destination)ic.lookup(destinationName); When run against JBossMQ using the remote executor, ic.lookup returns a javax.naming.Reference instead of javax.jms.Destination, and thus the code throws a ClassCastException. When run against JBoss Messaging, both local (colocated) and remote, or against JBossMQ colocated, everything is fine. What can be the problem? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041883#4041883 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041883

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by Kevin.Conner＠jboss.com

rofl. Okay, will take care of it tomorrow morning. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041876#4041876 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041876

17 years

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: java2ClassLoadingCompliance

by anil.saldhana＠jboss.com

I think the understanding is correct? Test cases will validate it. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041875#4041875 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041875

17 years

1
0
0 / 0

[Design of JBossCache] - Re: Channel creation - mux vs. old style

by bstansberry＠jboss.com

"manik.surtani(a)jboss.com" wrote : | Looking at JBCACHE-1023, and with reference to this, how would we deal with potentially injecting both a ChannelFactory as wel as a Channel? | | If the Channel is null, fall back to the ChannelFactory and use the CF to create a channel? And if the CF is null, create a new JChannel with cluster props (or default cluster props?) +1. That's the intuitively understandable way. anonymous wrote : | A bit of a PITA that org.jgroups.jmx.JChannelFactoryMBean doesn't extend org.jgroups.ChannelFactory - as this would be the cleanest interface to use here. I think the type in RuntimeConfig should be org.jgroups.ChannelFactory. I see now that AS 5 will have no problem instantiating a ChannelFactory, injecting it into a RuntimeConfig and also injecting it into an instance of org.jgroups.jmx.JChannelFactory. It can then register the org.jgroups.jmx.JChannelFactory in JMX in order to expose the management interfaces. Key thing in the above is JMX is just a mechanism for exposing management interfaces. It doesn't and shouldn't play the service integration role it did in AS 4-style architectures. Service integration should be done by injecting pojos -- i.e. the plain org.jgroups.ChannelFactory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041871#4041871 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041871

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by adrian＠jboss.org

I don't really care. Just so long as there isn't somewhere that less diligent committers think they put any old shit. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041867#4041867 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041867

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by Kevin.Conner＠jboss.com

"adrian(a)jboss.org" wrote : On a related issue, I don't think osgi-services belong in the MC project anyway. | | There is an osgi-int project that provides the core platform. These aren't intended to be service implementations, only the APIs which are required by the osgi-int module. They should reside in a different project though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041863#4041863 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041863

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by Kevin.Conner＠jboss.com

"adrian(a)jboss.org" wrote : Not varia. Varia is a bad idea in JBossAS and a bad idea here. Given the structures already discussed, what would you prefer to see? Would you prefer the first one which was proposed or a different one altogether? It's easy to move these around. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041860#4041860 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041860

17 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Removing dependency on concurrent.jar

by kabir.khan＠jboss.com

I copied this across to the old thirdparty repository http://repository.jboss.com/jboss/common-core/2.2.0.snapshot/ I don't think there is a way to make the old builds get the snapshots from Maven? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041859#4041859 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041859

17 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2007