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

[Design the new POJO MicroContainer] - Re: New ClassLoader initial checkin

by adrian＠jboss.org

"alesj" wrote : I see that a couple of classes from .spi reference some of the .plugins classes. | I saw the same problem with my BeanMetaDataBuilder - moved impl details in the plugins. | Shouldn't we keep them separate -> only plugins depend on spi? No. API/SPI is always allowed to reference plugins. Otherwise factories wouldn't be able to define a default implementation for example. The important part is that the implementation doesn't leak out to the client code, e.g. by appearing as parameters on methods. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041345#4041345 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041345

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New ClassLoader initial checkin

by adrian＠jboss.org

Some details Loaders A lot of the code is based on Loaders, well really DelegateLoaders. https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... which do what you might expect. Although I can support raw Loaders in some places (e.g. as parents of a Domain), most places need DelegateLoaders. That is a Loader associated with a ClassLoaderPolicy and transitively a ClassLoader. DelegateLoaders The DelegateLoaders are Loaders associated with a Policy. https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... They can also implement additional rules. e.g. for handling imports or exports you can add a filter. https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... ClassFilter ClassFilters let you decide what parts of a delegate classloader you are going to import or export. https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... There are some standard ones defined like EVERYTHING and NOTHING in that class. Examples. A DelegateLoader that imports only a certain package | new FilteredDelegateLoader(policy, new PackageClassFilter(new String[] { "com.acme" }); | Only importing java.* and javax.* from the parent of your domain | ClassLoadingSystem system = ClassLoadingSystem.getInstance(); | system.createAndRegisterDomain("MyDomain", ParentPolicy.BEFORE_BUT_ONLY_JAVA); | See https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... for more on the parent policy. Domains allow multiple hierarchies and not just delegation to another domain. | Loader parent = ...; | system.createAndRegisterDomain("MyDomain", ParentPolicy.BEFORE, parent); | this works because ClassLoadingDomains are also Loaders. If you don't specify a parent then it uses the ClassLoader that defines the org.jboss.classloader classes as the parent, via an adapter https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041344#4041344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041344

18 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: jbossesb-properties.xml filters

by mark.little＠jboss.com

There was a bug in the filter not checking for all possible EPR types. Should be fixed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041343#4041343 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041343

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New ClassLoader initial checkin

by alesj

I see that a couple of classes from .spi reference some of the .plugins classes. I saw the same problem with my BeanMetaDataBuilder - moved impl details in the plugins. Shouldn't we keep them separate -> only plugins depend on spi? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041341#4041341 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041341

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New ClassLoader initial checkin

by adrian＠jboss.org

Design. ClassLoaderPolicy In the new ClassLoader, you don't really deal with classloaders at all. You deal with ClassLoaderPolicys. https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... This includes things like what packages you export, what you import, how to get resources and other things related to defining classes. ClassLoaderSystem and Domains Additionally, the idea of a LoaderRepository is replaced with a ClassLoaderDomain [url]https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/cla...' and a ClassLoaderSystem acting as a factory and a repository of domains. https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... Each ClassLoaderSystem has a "default domain". Example psuedo code: | // NOTE: Singleton using the spi, but implementations can be instantiated | // directly to produce multiple classloading systems | // (which has proved useful in the tests) | | ClassLoaderSystem system = ClassLoaderSystem.getInstance(); | | // Whatever | MyClassLoadPolicy policy = ... | | // Register with the default domain, there are other methods to create | // and register with different domains | ClassLoader cl = system.registerClassLoaderPolicy(policy); | Uglyness and security To remove some ugliness from the code, the spi is split into 2 parts. The main part is what people will use https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... but these extend base implementations https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classlo... The idea is that the base implementations use package private methods to talk to each other about state, registration, etc. and issue well defined "callbacks" into the main spi. The advantages being: 1) Removal of ugliness - you don't see "nitty gritty" in the main spi 2) Security - you can't break the spi nor can anybody get access to things they shouldn't. For the same reason, I've defined a lot of callbacks methods in the main spi as protected since they should only be used as callbacks not by any random code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041338#4041338 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041338

18 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: jbossesb-properties.xml filters

by beve

Our current requirements are not variable lenght but this might change , plus I might need to specifiy a different delimiter then a comma, so I'll change to the EdiSax parser and update the quickstart when I'm done. Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041337#4041337 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041337

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - New ClassLoader initial checkin

by adrian＠jboss.org

The new ClassLoader is in SVN. https:/svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/classloader (for non jboss committers replace https://svn.jboss.org/... with http://anonsvn.jboss.org/ when the mirroring catches up). First some housekeeping points. 1) Although I committed this to the microcontainer project, it doesn't really belong there. It's only real dependency is the jboss logger. I'm leaving it their for now while I work on the VFS/Deployer integration. Eventually it should be moved to a top level project. 2) The original intention was to use the Felix ClassLoader and retrofit it with UnifiedClassLoader/Repository like behaviour. In fact, it was easier to refactor the UCL/R style classloader to add OSGI style behaviour. The only things I've really used from the felix as the idea of delegate/filtered classloaders and the hack you can find in ClassLoaderUtils::isRequestFromJDK() This was mainly because the Felix classloader links directly into the OSGi module system and more importantly doesn't include the fixes/workarounds for the ClassCircularityError/deadlock problems. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041335#4041335 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041335

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DependencyBuilder chain

by adrian＠jboss.org

You need to speak to Kabir. I will eventually get around to looking at/fixing this stuff to how I think it should work. e.g. A lot of this stuff should apply to JMX as well (although I don't think we can really integrate AOP with JMX without changing the JBossMX interceptor model?). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041332#4041332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041332

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by timfox

But if at least gives the desired behaviour when using JBoss that is ok for now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041330#4041330 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041330

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by timfox

"clebert.suconic(a)jboss.com" wrote : I have talked to Weston... | | if I used "jms-message-inflow-driven-bean" as the invoker for Standard Message Drive Bean on standardjboss.xml, the transaction was started before onMessage. | Of course. This is what I was saying previously about how one of the main motivations for JCA 1.5 inflow was to remove this issue anonymous wrote : | But I suggest we keep the if listener instanceof ServerSession. I have talked to Weston and he thinks that is pretty standard. As this will save the expected behavior on both invokers. Pretty standard in what way? This is an implementation detail AFAICT. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041327#4041327 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041327

18 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 2007