[Design the new POJO MicroContainer] - Re: JBMICROCONT-243 - parsing and managed objects
by scott.stark＠jboss.org
"alesj" wrote :
| You could perhaps change that type to which ICF is mapped against
| is contract of ICF:
|
| | public interface ICF<T>
| | {
| | Class<T> getType();
| | }
| |
| then you could use callback mechanism on ManagedObjectFactory,
| reducing this installs xml. ;-)
|
I'll do that when I add the MetaData api change.
"alesj" wrote :
| Meaning you would remove current man+deployers code
| and create new deployer - at INSTALLED stage?
|
Its just the current ManagedObjectCreator implementation in AbstractParsingDeployerWithOutput that would be moved into a new deployer that would be added to deployers.xml and runs at the INSTALLED stage.
"alesj" wrote :
| I'll probably cut new MC and Deployers release.
| To at least test current changes for a few days in AS.
| Let me know when you're done with your changes.
Ok. I need a jboss-managed 2.0.0.CR4 to be able to pass the deployment unit MetaData in the new ManagedObjectCreatorDeployer. I'll test in first in the jbossas codebase.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185478#4185478
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185478
15 years, 11 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing ClassPools for AS
by kabir.khan＠jboss.com
I started off replicating the AS 4 classloaders with my new classpools, and stumbled upon the following inconsistency when trying out how they work. Does anybody have any pointers?
| public void testUndeployParentDomainClassLoader() throws Exception
| {
| ClassLoader globalA = null;
| ClassLoader globalB = null;
| ClassLoader child = null;
| try
| {
| try
| {
| globalA = createGlobalClassLoader(JAR_A_1); //Contains CLASS_A
| assertCannotLoadClass(globalA, CLASS_B);
|
| child = createChildClassLoader(JAR_C_1, true); //Contains CLASS_C
| assertCannotLoadClass(child, CLASS_B);
|
| globalB = createGlobalClassLoader(JAR_B_1); //Contains CLASS_B
| Class<?> bFromChild = child.loadClass(CLASS_B);
| Class<?> bFromA = globalA.loadClass(CLASS_B);
| assertSame(globalB, bFromA.getClassLoader());
| assertSame(bFromA, bFromChild);
| }
| finally
| {
| removeClassLoaderFromRepository(globalB); //This should remove the classloader containing JAR_B_1/CLASS_B
| }
| assertCannotLoadClass(child, CLASS_B); //Fails since we can still find CLASS_B
| }
| finally
| {
| removeClassLoaderFromRepository(globalA);
| }
| }
|
If I try the same from sibling loaders it works as expected
| public void testUndeploySibling() throws Exception
| {
| ClassLoader clA = null;
| ClassLoader clB = null;
| try
| {
| try
| {
| clA = createGlobalClassLoader(JAR_A_1);
| assertCannotLoadClass(clA, CLASS_B);
|
| clB = createGlobalClassLoader(JAR_B_1);
| Class<?> bFromA = clA.loadClass(CLASS_B);
| assertSame(clB, bFromA.getClassLoader());
| }
| finally
| {
| removeClassLoaderFromRepository(clB);
| }
| assertCannotLoadClass(clA, CLASS_B);
| }
| finally
| {
| removeClassLoaderFromRepository(clA);
| }
| }
|
The helper functions are here:
| protected ClassLoader createGlobalClassLoader(URL url) throws Exception
| {
| ClassLoader cl = globalRepository.newClassLoader(url, true); //This is the main repository
| registeredClassLoaders.add(cl);
| return cl;
| }
|
| protected ClassLoader createChildClassLoader(URL url, boolean parentFirst) throws Exception
| {
| HeirarchicalLoaderRepository3 repository = new HeirarchicalLoaderRepository3(getServer(), MAIN_LOADER_REPOSITORY_OBJECT_NAME);
| repository.setUseParentFirst(parentFirst);
| ClassLoader cl = repository.newClassLoader(url, true);
| registeredClassLoaders.add(cl);
| return cl;
| }
|
| protected void removeClassLoaderFromRepository(ClassLoader cl)
| {
| if (cl != null)
| {
| if (cl instanceof RepositoryClassLoader)
| {
| LoaderRepository repository = ((RepositoryClassLoader)cl).getLoaderRepository();
| repository.removeClassLoader(cl);
| }
| }
| }
|
| protected void assertCannotLoadClass(ClassLoader cl, String className)
| {
| try
| {
| cl.loadClass(className);
| fail("Should not have been able to load " + className);
| }
| catch(Exception expected)
| {
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185459#4185459
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185459
15 years, 11 months
[TODO - DEVELOPMENT] - JBOSS and Windows COM Integration
by vikramrc
Hello There,
I hope to provide a short background before setting the context for my proposal.
I am the author of j-Interop - Java COM Middleware (www.j-interop.org). This library implements the DCOM protocol published by Microsoft in pure Java thus allowing an application to interoperate with Windows COM components from any platform supporting Java. From Windows OS perspective it behaves just like any other Windows COM client would. It is maintained and released under LGPL.
Quite a few of our users are working with JBoss AS and using j-Interop as an artifact (servlet or EJB) of their application. Sometime back one of them pointed us to BEA Weblogic jCOM (http://e-docs.bea.com/wls/docs92/jcom/index.html) which provides this functionality of COM interoperability as part of the application server itself. They also mentioned that JBoss already has a similar functionlity wrt CORBA (jbossiiop project).
To me this sounded like a good usecase of providing support for seamless access to native Windows COM applications from JBoss AS itself.
I wanted to propose forming a similar component such as jbossiiop for COM access. This component "jbosscom" (if I may take the liberty) would be enabled using j-Interop. I would very much like this to be our contribution to the growing popularity and users of JBoss AS and j-Interop projects respectively.
I would be grateful for any thoughts, ideas or alternatives you have on this proposal.
thanks for your time,
best regards,
Vikram
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185452#4185452
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185452
15 years, 11 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-243 - parsing and managed objects
by alesj
"scott.stark(a)jboss.org" wrote :
|
| | <!-- The ManagedObjectFactory -->
| | <bean name="ManagedObjectFactory">
| | <constructor factoryClass="org.jboss.managed.api.factory.ManagedObjectFactory" factoryMethod="getInstance"/>
| | </bean>
| | ...
| | <!-- POJO Deployment -->
| | <bean name="BeanMetaDataICF" class="org.jboss.deployers.plugins.managed.BeanMetaDataICF">
| | <install bean="ManagedObjectFactory" method="setInstanceClassFactory">
| | <parameter>
| | <value>org.jboss.beans.metadata.spi.BeanMetaData</value>
| | </parameter>
| | <parameter>
| | <this />
| | </parameter>
| | </install>
| | <uninstall bean="ManagedObjectFactory" method="setInstanceClassFactory">
| | <parameter>
| | <value>org.jboss.beans.metadata.spi.BeanMetaData</value>
| | </parameter>
| | <parameter>
| | <null />
| | </parameter>
| | </uninstall>
| | <property name="controller"><inject bean="jboss.kernel:service=KernelController"/></property>
| | </bean>
| | ...
| | <!-- JMX Deployment -->
| | <bean name="ServiceMetaDataICF" class="org.jboss.system.deployers.managed.ServiceMetaDataICF">
| | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property>
| | <install bean="ManagedObjectFactory" method="setInstanceClassFactory">
| | <parameter>
| | <value>org.jboss.system.metadata.ServiceMetaData</value>
| | </parameter>
| | <parameter>
| | <this />
| | </parameter>
| | </install>
| | <uninstall bean="ManagedObjectFactory" method="setInstanceClassFactory">
| | <parameter>
| | <value>org.jboss.system.metadata.ServiceMetaData</value>
| | </parameter>
| | <parameter>
| | <null />
| | </parameter>
| | </uninstall>
| | </bean>
| |
|
You could perhaps change that type to which ICF is mapped against
is contract of ICF:
| public interface ICF<T>
| {
| Class<T> getType();
| }
|
then you could use callback mechanism on ManagedObjectFactory,
reducing this installs xml. ;-)
"scott.stark(a)jboss.org" wrote :
| I would like to break the ManagedObjectCreator into a separate DeploymentStage.INSTALLED deployer that has the ManagedObjectFactory injected into it.
|
| Any objections?
|
Meaning you would remove current man+deployers code
and create new deployer - at INSTALLED stage?
"scott.stark(a)jboss.org" wrote :
| Is this the last change to cut the JBDEPLOY-2.0.0.GA, or is a JBDEPLOY-2.0.0.CR4 needed?
|
I'll probably cut new MC and Deployers release.
To at least test current changes for a few days in AS.
Let me know when you're done with your changes.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185446#4185446
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185446
15 years, 11 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-243 - parsing and managed objects
by scott.stark＠jboss.org
This is now JBDEPLOY-79. Another issue with the current AbstractParsingDeployerWithOutput implementation of ManagedObjectCreator is that its using the ManagedObjectFactoryBuilder.create() to obtain the ManagedObjectFactory. This is only coincidentally mapping to the ManagedObjectFactory bean now being created in the bootstrap deployers.xml, against which the BeanMetaDataICF and ServiceMetaDataICF beans register:
| <!-- The ManagedObjectFactory -->
| <bean name="ManagedObjectFactory">
| <constructor factoryClass="org.jboss.managed.api.factory.ManagedObjectFactory" factoryMethod="getInstance"/>
| </bean>
| ...
| <!-- POJO Deployment -->
| <bean name="BeanMetaDataICF" class="org.jboss.deployers.plugins.managed.BeanMetaDataICF">
| <install bean="ManagedObjectFactory" method="setInstanceClassFactory">
| <parameter>
| <value>org.jboss.beans.metadata.spi.BeanMetaData</value>
| </parameter>
| <parameter>
| <this />
| </parameter>
| </install>
| <uninstall bean="ManagedObjectFactory" method="setInstanceClassFactory">
| <parameter>
| <value>org.jboss.beans.metadata.spi.BeanMetaData</value>
| </parameter>
| <parameter>
| <null />
| </parameter>
| </uninstall>
| <property name="controller"><inject bean="jboss.kernel:service=KernelController"/></property>
| </bean>
| ...
| <!-- JMX Deployment -->
| <bean name="ServiceMetaDataICF" class="org.jboss.system.deployers.managed.ServiceMetaDataICF">
| <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property>
| <install bean="ManagedObjectFactory" method="setInstanceClassFactory">
| <parameter>
| <value>org.jboss.system.metadata.ServiceMetaData</value>
| </parameter>
| <parameter>
| <this />
| </parameter>
| </install>
| <uninstall bean="ManagedObjectFactory" method="setInstanceClassFactory">
| <parameter>
| <value>org.jboss.system.metadata.ServiceMetaData</value>
| </parameter>
| <parameter>
| <null />
| </parameter>
| </uninstall>
| </bean>
|
I would like to break the ManagedObjectCreator into a separate DeploymentStage.INSTALLED deployer that has the ManagedObjectFactory injected into it.
Any objections?
Is this the last change to cut the JBDEPLOY-2.0.0.GA, or is a JBDEPLOY-2.0.0.CR4 needed?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185438#4185438
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185438
15 years, 11 months
