[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by kabir.khan＠jboss.com
The output is too long to paste here, but I think this part of the dumped schema is relevant:
| <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
| targetNamespace="urn:jboss:aop-beans:1.0"
| xmlns="urn:jboss:aop-beans:1.0"
| >
|
| <element name="{urn:jboss:aop-beans:1.0}bean" type="{urn:jboss:aop-beans:1.0}abstract-bean-meta-data">
| </element>
| <element name="{urn:jboss:bean-deployer:2.0}bean" type="{urn:jboss:aop-beans:1.0}abstract-bean-meta-data">
| </element>
| ....
| <complexType name="{urn:jboss:aop-beans:1.0}abstract-bean-meta-data" base="xsd:anyType">
| <sequence>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}alias" minOccurs="0" type="{http://www.w3.org/2001/XMLSchema}string">
| </element>
| </sequence>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}annotation" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-annotation-meta-data">
| </element>
| </sequence>
| <element name="{urn:jboss:aop-beans:1.0}classloader" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-class-loader-meta-data">
| </element>
| <element name="{urn:jboss:aop-beans:1.0}constructor" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-constructor-meta-data">
| </element>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}property" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-property-meta-data">
| </element>
| </sequence>
| <element name="{urn:jboss:aop-beans:1.0}create" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-lifecycle-meta-data">
| </element>
| <element name="{urn:jboss:aop-beans:1.0}start" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-lifecycle-meta-data">
| </element>
| <element name="{urn:jboss:aop-beans:1.0}stop" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-lifecycle-meta-data">
| </element>
| <element name="{urn:jboss:aop-beans:1.0}destroy" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-lifecycle-meta-data">
| </element>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}depends" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-dependency-meta-data">
| </element>
| </sequence>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}demand" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-demand-meta-data">
| </element>
| </sequence>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}supply" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-supply-meta-data">
| </element>
| </sequence>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}install" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-install-meta-data">
| </element>
| </sequence>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}uninstall" minOccurs="0" type="{urn:jboss:aop-beans:1.0}abstract-install-meta-data">
| </element>
| </sequence>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}incallback" minOccurs="0" type="{urn:jboss:aop-beans:1.0}install-callback-meta-data">
| </element>
| </sequence>
| <sequence minOccurs="0">
| <element name="{urn:jboss:aop-beans:1.0}uncallback" minOccurs="0" type="{urn:jboss:aop-beans:1.0}uninstall-callback-meta-data">
| </element>
| </sequence>
| </sequence>
| <attribute name="autowire-type" type="CDATA" optional="true"/>
| <attribute name="abstract" type="{http://www.w3.org/2001/XMLSchema}boolean" optional="true"/>
| <attribute name="class" type="{http://www.w3.org/2001/XMLSchema}string" optional="true"/>
| <attribute name="mode" type="CDATA" optional="true"/>
| <attribute name="autowire-candidate" type="{http://www.w3.org/2001/XMLSchema}boolean" optional="true"/>
| <attribute name="name" type="{http://www.w3.org/2001/XMLSchema}string" optional="true"/>
| <attribute name="parent" type="{http://www.w3.org/2001/XMLSchema}string" optional="true"/>
| </complexType>
| ...
|
My AOPDeployment class
| @JBossXmlSchema(namespace="urn:jboss:aop-beans:1.0", elementFormDefault=XmlNsForm.QUALIFIED)
| @XmlRootElement(name="aop")
| @XmlType(propOrder={"annotations", "classLoader", "beanFactories", "create", "start", "stop", "destroy", "aliases"})
| public class AOPDeployment extends AbstractKernelDeployment
| {
| private static final long serialVersionUID = 1L;
|
|
| @XmlElements
| ({
| @XmlElement(name="bean", type=AbstractBeanMetaData.class),
| @XmlElement(name="bean", namespace="urn:jboss:bean-deployer:2.0", type=AbstractBeanMetaData.class),
| @XmlElement(name="beanfactory", type=GenericBeanFactoryMetaData2.class),
| @XmlElement(name="beanfactory", namespace="urn:jboss:bean-deployer:2.0", type=GenericBeanFactoryMetaData2.class),
| @XmlElement(name="lazy", type=AbstractLazyMetaData.class),
| @XmlElement(name="lazy", namespace="urn:jboss:bean-deployer:2.0", type=AbstractLazyMetaData.class),
| @XmlElement(name="aspect", type=AspectBeanMetaDataFactory.class),
| @XmlElement(name="interceptor", type=InterceptorBeanMetaDataFactory.class),
| @XmlElement(name="bind", type=BindBeanMetaDataFactory.class),
| @XmlElement(name="stack", type=StackBeanMetaDataFactory.class),
| @XmlElement(name="typedef", type=TypeDefBeanMetaDataFactory.class),
| @XmlElement(name="cflow-stack", type=CFlowStackBeanMetaDataFactory.class)
| })
| @XmlAnyElement
| public void setBeanFactories(List<BeanMetaDataFactory> beanFactories)
| {
| super.setBeanFactories(beanFactories);
| }
| }
|
If that is not enough, the code is commited and aop-mc-int/src/tests/org.jboss.test.microcontainer.beans.test.AspectSimpleJaxbAopTestCase demonstrates the problem
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132285#4132285
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132285
17 years, 10 months
[Design of Messaging on JBoss (Messaging/JBoss)] - New package structure
by timfox
I have just committed a refactoring to our new package structure.
Here is how it goes:
org.jboss.messaging.core and sub packages.
Contain the messaging core - this is all the stuff needed to make a fully functioning transactional, reliable messaging system.
It does not include jms, nor does it have any dependencies on JEE, JNDI etc. It basically will just depend on J2SE and MINA (if not using an invm transport).
Please be extra careful not to introduce any such dependencies in this layer.
Inside core, it is further split into modules:
core/module-name (e.g. core/management)
this contains the *interfaces* exported by that module. It should only contain interfaces and possible very simple struct like classes.
The implementation of the interfaces goes in:
core/module-name/impl
The idea is that one interface can depend on interfaces from another module, but it *must not* depend on implementations from another module.
This is currently broken in some modules (e.g. deployment, security etc) and this will need fixing, where code depends directly on concrete classes rather than interfaces. (More on this later).
The current modules are:
channelfactory - channel factory stuff (TBD)
cluster
config - the Configuration interface and implementations (Basic, File)
deployers
filter - core filters
list - priority list
logging
management - the core management interface and implemementation
memory- the memory manager (TBD)
messagecounters
persistence - persistence manager implementations
this contains subdirectories:
e.g.
nullpm - the null persistence manager
bdbje - the BDB JE persistence manager
and then we have
remoting - our remoting layer
security - core security store interface and implementation
server - the core server interfaces and implementation
e.g. messaging server, server connection, server session, queue etc etc
settings - the hierarchical repository stuff that handles queue and security settings
version
client - this contains the core client interfaces and implementation
Then we have the jms stuff.
This is in:
org.jboss.messaging.jms.client -
This is the client side JMS code
org.jboss.messaging.jms.server -
This is the server side JMSServerManager and related stuff.
Then we have microcontainer stuff which is specific to the bootstrapping of the MC - much of this can probably be removed now.
In more detail, some modules are currently exposing implementations to other modules, they are:
1) Config - we need to create a Configuration interface which lives in the config module - currently there is a concrete class in the server module and another concrete class RemotingConfiguration in the remoting module. These should be combined and put in the config module.
2) Deployers. Currently abstract class Deployer is exported from the module. This should be an interface. Also DeploymentManager should be an interface. We should also avoid singletons throughput JBM, this is to allow multiple JBM instances to co-exist in the same VM without interacting.
3) messagecounter - currently these are concrete classes - shoud be abstracted out to interface + implementation
4) remoting - there are various concrete classes in this module which are exported to other modules - should be made interfaces
5) security
6) settings - implemtation is used directly
Other things to note:
1) much of the stuff in the microcontainer module doesn't seem necessary any more.. can we remove?
2) If a class is serializable it should be given a serialVersionUID
3) please observe the order of static, public, private etc methods in a class. I've seen quite a few occasions of say, a provate method inserted into the middle of a load of public methods etc.
4) Please avoid K & R style of braces:
e.g.
if (foo) {
//do something
} else if (bar) {
//do somehting else
}
Is not the style we use.
That's about it for now :)
If any of the above comments apply to your areas, can you add to your TODO list to correct.
Cheers.
It's really starting to take shape now :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132265#4132265
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132265
17 years, 10 months
[Design of JBoss jBPM] - Re: jBPM Classloading
by bwand
The code looks like this:
| public static final String JBPM_CLASSLOADER = "jbpm.classloader";
| public static final String JBPM_CLASSLOADER_CLASSNAME = "jbpm.classloader.classname";
|
| ...
|
| public static ClassLoader getClassLoader() {
| if (System.getProperty(JBPM_CLASSLOADER).equals("jbpm")) {
| return ClassLoaderUtil.class.getClassLoader();
| } else if (System.getProperty(JBPM_CLASSLOADER).equals("context")) {
| return Thread.currentThread().getContextClassLoader();
| } else if (System.getProperty(JBPM_CLASSLOADER).equals("custom")) {
| try {
| String customClassLoaderClassName = System.getProperty(JBPM_CLASSLOADER_CLASSNAME);
| if (customClassLoaderClassName == null) {
| throw new JbpmException(
| "'jbpm.classloader' system property set to 'custom' but 'jbpm.classloader.classname' is empty!");
| }
| return (ClassLoader) Thread.currentThread().getContextClassLoader().loadClass(
| customClassLoaderClassName).newInstance();
| } catch (InstantiationException e) {
| throw new JbpmException("Error instantiating custom classloader "
| + System.getProperty(JBPM_CLASSLOADER_CLASSNAME), e);
| } catch (IllegalAccessException e) {
| throw new JbpmException("Error accessing custom classloader "
| + System.getProperty(JBPM_CLASSLOADER_CLASSNAME), e);
| } catch (ClassNotFoundException e) {
| throw new JbpmException("Custom classloader "
| + System.getProperty(JBPM_CLASSLOADER_CLASSNAME) + " not found ", e);
| }
| } else {
| return ClassLoaderUtil.class.getClassLoader();
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132264#4132264
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132264
17 years, 10 months