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

[Design the new POJO MicroContainer] - Context ClassLoader - POJO

by adrian＠jboss.org

Most of the containers are already setting the correct context classloader, e.g. MBeans and EJB do it But the POJO deployment runs with a "random" context classloader. The changes required to fix this are: 1) Set the context classloader in the callbacks (e.g. instantiate, configure, create, start, etc.) 2) Add ClassLoaderMetaData - the POJO version of this class, not be confused with the deployment metadata with the same name :-( - to use the classloader of the deployment (if the -beans.xml or bean does not already override it to use an explicit classloader). My preference in the past would be to make this an aspect (since it should arguably do it for methods that are not part of the IOC protocol, e.g. runtime methods), but I'm now convinced that the MC should be doing it itself. First the MC should be able to run without AOP, so it isn't really the full solution. (Of course you could argue that the feature is only available with AOP :-) Second, there are times when you might want the correct classloader during configuration, but use the caller's context classloader at runtime. Third, configuring the aspect (even with a simple annotation) on every relevant POJO would be a configuration nightmare. So the solution I propose is set the context classloader in the IOC callbacks, but require the aspect for this behaviour at runtime. Also, this won't change the behaviour for standalone MC usage since if the classloader is not configured (it will be always inside JBoss since it will set to the deployment classloader when not configured) it will just "redundantly" reset the classloader to context classloader, i.e. no change View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122221#4122221 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122221

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Remaing classLoader changes

by adrian＠jboss.org

This thread brings together some previous discussion in other threads, but a small part of it (JBOSGI-15) has not been fully discussed before. Not all of this needs to be done for Beta4/RC1 since a lot of this is implementation detail and tidyup. The remaining work for the classloader changes falls into three main categories (I'll ignore fixing problems found using the new classloader which is just on going maintenance). 1) Setting of the correct context classloader 2) Using the new classloader in the bootstrap 3) Finishing the OSGi classloading rules I'll discuss the details in other posts and link them here so we don't have yet another incomprenisble free for all. This thread can be used to raise issues not part of the other discussion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122218#4122218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122218

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ManagedObject attachment serialization

by adrian＠jboss.org

The original intention was that the ManagedObject would be used by the management layer to configure the attachments. As such for remote management, the attachments needed to be serialzable such that the remote management tool could use the ManagedObject api to change the attachment, retriefve the object and place it in the preconfigured part of the deployment. The notion of ManagedObject has changed a lot since the original design. i.e. * ManagedProperty can exist by itself * ManagedObject is just an implementation detail with a new api for the managed layer You'd need to ask Scott, et. al. how they are adding the changed attachments into the Deployment when doing work remotely to change/persist the values in for example a remote agent. If they don't have the metadata classes on the client side, I'd guess there either needs to be some proxy work (possibly inside the deployment layer?) that can reconstruct the attachment on the server side from the "ManagedObject" or the Deployment itself is reconstructed on the server side from the management artifacts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122204#4122204 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122204

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - ManagedObject attachment serialization

by alex.loubyansky＠jboss.com

Looking into http://jira.jboss.com/jira/browse/JBMICROCONT-225 Is this supposed to be a general rule or should it only affect the metadata classes? Currently, an attachment in the api is represented as Serializable. If attachments were not serialized then it would not make sense to require them implement Serializable? If clients should not see the metadata api is there a reason for metadata classes implement Serializable? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122187#4122187 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122187

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-structure help needed

by adrian＠jboss.org

"alesj" wrote : "anil.saldhana(a)jboss.com" wrote : | | I tried the .xml files outside the METADataPath in the structure file in vain. | | | Can you try this: | | | <metaDataPath> | | <path name="META-INF"/> | | <path name=""/> | | </metaDataPath> | | What on earth are you doing? The -ds.xml files in the root are subdeployments and the login-config.xml is a resource. None of these are metadata (unless you are going to write a new securty deployer that creates policies from META-INF/login-config.xml). | Can you please give me some examples of jboss-structure files? | Have you tried looking the testsuite? For future reference, the jboss-structure.xml should have looked something like this: | <structure> |  | <context> | <path name=""/> | |  | <metaDataPath> | <path name="META-INF"/> | </metaDataPath> | |  | <classpath> | <path name=""/> | </classpath> | </context> | |  | <context name="notxfs-ds.xml"/> | |  | </structure> | But these should be the default rules anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122183#4122183 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122183

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders

by adrian＠jboss.org

"anil.saldhana(a)jboss.com" wrote : Ales, do not want to obscure your last discussion post with Adrian. | | I just want to tell you that adding a jboss-structure.xml to the AS security test deployment, got the particular tests to pass. I will need to add the structure to other deployments with the same resource(properties files) detection issue. Fix it properly by placing the resources somewhere that IS in the classpath. The root of an ear should NOT be in classpath. I really am fed up with all this "I'll add a workaround for a workaround for a bug" that leads to stupid code and irrelevant features rather than doing a proper job. Fix the original bug then you don't need any of the workarounds! :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122174#4122174 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122174

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Data gravitation cleanup process and stale nodes

by manik.surtani＠jboss.com

Y'know, I'm leaning towards pushing this out for 2.2 or something. It won't be an API change or anything. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122164#4122164 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122164

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-structure help needed

by anil.saldhana＠jboss.com

"scott.stark(a)jboss.org" wrote : A jboss-structure.xml should not be needed. The problem is that the local login-config.xml resource is not being found preferentially over the conf/login-config.xml. The DynamicLoginConfig service is loading that url: | | vfsfile:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta4/server/default/conf/login-config.xml | | | and so the custom login config names are all mapping to the default login config, and there are no users/roles.properties found. | Scott, I understand that the custom application policies are not being found, hence it is defaulting to "other". But what I do not understand is from where is the DynamicLoginConfigService kicking in, for this test case? It is neither explicitly defined in this test deployment nor anything is done from the test case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122157#4122157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122157

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Remote-bisocket JMS test fail on Mac OSX

by apwalker

I get a NullPointerException from the following in the ServerContainer when running the remote tests | ServiceContainer.java | ...... | | private void readConfigurationFile() throws Exception | { | InputStream cs = getClass().getClassLoader().getResourceAsStream(CONFIGURATION_FILE_NAME); | | ..... | It appears to be a bug in the Apple JVM I put a local hack which uses a FileInputStream if the above call returns null and it uses a relative path but this mean you need to always run the tests from the tests directory. LocalTestServer.java needs a simialr hack and with both of these all the tests pass. I would like to commit these work arounds to the stable branch as I really don't think we'll get this one fixed for sometime and with the refactoring of the tests to use the microcontainer I think this may go away. Here is the JIRA Issue for this http://jira.jboss.org/jira/browse/JBMESSAGING-1222 Aaron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122155#4122155 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122155

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-structure help needed

by alesj

"anil.saldhana(a)jboss.com" wrote : org.jboss.deployers.spi.DeploymentException: Only one file is allowed, found=[Ja | | rEntryHandler(a)29129210[path=calleridentity-ds.xml context=file:/C:/cygwin/home/a | | saldhana/jboss-5.0/jboss-head/testsuite/output/lib/jca-securedejb.jar real=jar:f | | ile:/C:/cygwin/home/asaldhana/jboss-5.0/jboss-head/testsuite/output/lib/jca-secu | | redejb.jar!/calleridentity-ds.xml], JarEntryHandler(a)15480059[path=notxfs-ds.xml | | context=file:/C:/cygwin/home/asaldhana/jboss-5.0/jboss-head/testsuite/output/lib | | /jca-securedejb.jar real=jar:file:/C:/cygwin/home/asaldhana/jboss-5.0/jboss-head | | /testsuite/output/lib/jca-securedejb.jar!/notxfs-ds.xml]] | | at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse | | (AbstractVFSParsingDeployer.java:108) | | at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithO | | utput.createMetaData(AbstractParsingDeployerWithOutput.java:225) | | at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithO | | utput.createMetaData(AbstractParsingDeployerWithOutput.java:199) | | at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithO | | utput.deploy(AbstractParsingDeployerWithOutput.java:162) | | Ah, yes, JBMICROCONT-184. Need to touch on that subject asap. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122089#4122089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122089

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 January 2008