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

[Design of JBossCache] - Re: Amazon S3 cache loader

by manik.surtani＠jboss.com

I'm happy to put this in the distro for now - perhaps later set up a separate repo for contribs like this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126734#4126734 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126734

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Classloader problem with NamingRestartUnitTestCase

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : The ClassAdapter is retrieved during this processing in AbstractKernelConfigurator | I should have also mentioned that is invoked from org.jboss.kernel.plugins.dependency.PreInstallAction | protected void installActionInternal(KernelControllerContext context) throws Throwable | { | KernelController controller = (KernelController)context.getController(); | Kernel kernel = controller.getKernel(); | KernelConfigurator configurator = kernel.getConfigurator(); | | BeanMetaData metaData = context.getBeanMetaData(); | if (metaData.getBean() != null) | { | BeanInfo info = configurator.getBeanInfo(metaData); | context.setBeanInfo(info); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126723#4126723 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126723

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Classloader problem with NamingRestartUnitTestCase

by adrian＠jboss.org

The ClassAdapter is retrieved during this processing in AbstractKernelConfigurator | public BeanInfo getBeanInfo(BeanMetaData metaData) throws Throwable | { | ClassLoader cl = Configurator.getClassLoader(metaData); | String className = metaData.getBean(); | if (className == null) | return null; | return getBeanInfo(className, cl); | } | The links are: BeanInfo -> ClassAdapter -> ClassInfo -> Class The AnnotatedElement is just the real Class. The Configurator.getClassLoader(...) uses the thread context classloader to load the class if there isn't a specific one configured (which in your case there isn't - that comes with the next gen of the MC :-). So it looks like there are three options for why it fails. 1) The TCL is wrong. e.g. something is setting the TCL on the RMI thread and not resetting it. 2) Somehow it is able to lookup the old class in the old classloader without getting an error 3) There is some bad caching going on somewhere (the BeanInfo/ClassInfo caches are based on classloader so (1) would also appear as this problem). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126722#4126722 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126722

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Amazon S3 cache loader

by genman

I've been playing around with the Amazon S3 service. For those of you unfamiliar, it's a distributed, reliable storage solution that's a paid service from Amazon.com. I thought it'd be pretty neat to be able to use the JBoss Cache API for accessing and storing objects from the service. I'm not sure this would be of any use to JBoss itself but I wouldn't mind putting an implementation together. There's a REST and SOAP API. The existing REST library Amazon provides is fairly crude but could be used as a basis. Where would this code get checked in? And where would the cache loader itself belong? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126720#4126720 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126720

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: FileStructure and FileMatcher

by adrian＠jboss.org

A similar argument could be made for the jar suffixes in the JarStructure. e.g. the SARdeployer could automatically add itself as a JARMatcher accepting .sar extensions, etc. Of course we should still hardwire .jar and .zip ;-) In this case, it isn't as much of an issue of recognition since they are all jars and the real test is whether something in META-INF/*.xml gets processed. I say it is not an issue of recognition because everything can now be .jar files, but there will be legacy deployments that use the old extensions like .beans or .hibernate for subdeployments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126710#4126710 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126710

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Classloader problem with NamingRestartUnitTestCase

by bstansberry＠jboss.com

Quick report as I poke around in this as well. Looking more into what AOPDependencyBuild.getDependencies does, following from the AspectManagerFactory.getAspectManager() call you highlighted: | AspectManager manager = AspectManagerFactory.getAspectManager(metaData); | try | { | ClassInfo classInfo = classAdapter.getClassInfo(); | String className = classInfo.getName(); | if (className != null) | { | ClassLoader loader = classAdapter.getClassLoader(); | if (loader == null) | { | loader = Thread.currentThread().getContextClassLoader(); | } | Class clazz = loader.loadClass(className); | The classAdapter.getClassLoader() call is returning the BaseClassLoader from the previous deployment. That happens before any usage is made of the AspectManager. Looking more into that, I see a chain of AbstractBeanInfo.classAdapter.classInfo.getType().getClassLoader(). Looking at classInfo.getType() I see it's actually ClassInfoImpl.annotatedElement. I'm going to poke a bit more and see if I can figure out where the AbstractBeanInfo and the ClassInfoImpl.annotatedElement are coming from. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126708#4126708 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126708

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by charles.crouch＠jboss.com

I have no idea which jira the war CL changes went into, so I created a new one http://jira.jboss.com/jira/browse/JBAS-5211 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126706#4126706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126706

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by alesj

"charles.crouch(a)jboss.com" wrote : do we have a jira for this yet? No. Can you create one? Perhaps as a subtask of Scott's war CL change (if it exists). And assign it to Scott, since he's currently the suspect. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126703#4126703 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126703

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - FileStructure and FileMatcher

by adrian＠jboss.org

A while ago we discussed adding FileMatcher "incallbacks" to the FileStructure so we automatically added recognised file suffixes as subdeployments. But this wasn't completed properly. Instead of making all AbstractParsingDeployerWithOutputs (which knows about suffixes) into FileMatcher implementations, only the bean shell deployer does this. If we did this for every parsing deployer, then there would be no need for any hardwiring in the FileStructure, e.g. -ds.xml and -service.xml It would also correctly fail those deployments when the relevant parsing deployer wasn't present. e.g. currently it will add -ds.xml as a subdeployment even if the DataSource deployer isn't installed and then fail it with "nobody processed the subdeployment" later on. An additional request from Mark Newton is to apply the file matching process to top level deployments as well. Currently we allow a top level deployment to be called anything, but that doesn't mean it will be correctly processed if the parsing deployer doesn't recognise it. The reasoning behind this was that I didn't want to have configure all the suffixes in two places (the FileStructure and the ParsingDeployer), but if the above change is implemented this argument goes away. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126700#4126700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126700

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VersionImpl is not correct.

by adrian＠jboss.org

"alesj" wrote : | If you let any Version type to be present in our VersionRange, then you would have to let version be Object, which is a lot less type safe than our Version approach with comparators and thin wrappers present. | You read my mind. That is the approach I'm taking. i.e. I've removed the Version interface altogether and just use an Object in its place in the spi. I originally tried Comparable but that was redundant and messy since we don't really use the compareTo() directly except when when comparing versions of the same type (and even then that's not really a requirement ;-). I'm also adding a default String <-> Version comparator so in prinicple you could just a String as your version. But this isn't as efficient since potentially it has to parse the String ever time it wants to compare it, e.g. probably twice to do a VersionRange check. What this does mean is that there is no VersionImpl in what is now a public spi. There is just our Version class that can be compared to other version classes (including Strings :-) using the VersionComparators. P.S. The hashCode() problem is unsolvable. So it is probably best to just document that "versions" (and anything that uses a "version" in its identity) should be stored in Sorted Sets and Maps using a comparator based on the VersionComparatorRegistry NOT the hashed collections. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126688#4126688 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126688

18 years, 2 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 February 2008