[Design of AOP on JBoss (Aspects/JBoss)] - Re: ManagedObject stuff for AOP
by kabir.khan＠jboss.com
I have most of this working, but need a bit of guidance on where to take it further.
The way it currently works is that you deploy similar xml to -aop.xml in a -beans.xml, for example:
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <bean name="AspectManager" class="org.jboss.aop.AspectManager">
| <constructor factoryClass="org.jboss.aop.AspectManager" factoryMethod="instance"/>
| </bean>
|
| <interceptor xmlns="urn:jboss:aop-beans:1.0" class="org.jboss.test.microcontainer.beans.TestInterceptor"/>
|
| <bind xmlns="urn:jboss:aop-beans:1.0" pointcut="execution(* org.jboss.test.microcontainer.beans.POJO->*(..))">
| <interceptor-ref name="org.jboss.test.microcontainer.beans.TestInterceptor"/>
| </bind>
|
| <bean name="Bean" class="org.jboss.test.microcontainer.beans.POJO"/>
|
| </deployment>
|
More examples can be found in http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/aop-.... The *BeansTestCase.xml files show the underlying beans, while the *AopTestCase.xml files show the -aop.xml style configuration.
1) Am I ok using -beans.xml files for this? Or should I be using -aop.xml? If so, how do the -aop.xml files get recognised by the deployer that deploys -beans.xml files? I think that means scrapping the AspectDeployer?
2) I will probably need to do something similar for aspects configured via annotations. So we might need the AspectDeployer anyway. I should be able to easily create the BeanMetaDataFactory from the annotations, but what would the entry point of getting these beans into the MC be?
3) Is adding the ManagedObject/Operation stuff my task? How do I test that I am exposing the right stuff?
4) With the current xml it is by default looking for an org.jboss.aop.AspectManager called "AspectManager" (as shown in the example above), in AS 5 this does not exist, so instead we need to do (from http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/resources/aop/...:
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <aop:aspect xmlns:aop="urn:jboss:aop-beans:1.0"
| name="DependencyAdvice"
| class="org.jboss.test.aop.mcdefaultannotation.AnnotationReaderInterceptor"
| manager-bean="AspectManager"
| manager-property="aspectManager">
| </aop:aspect>
|
| <aop:bind xmlns:aop="urn:jboss:aop-beans:1.0"
| pointcut="execution(* @org.jboss.test.aop.mcdefaultannotation.TestAnnotation->getAnnotationValue())"
| manager-bean="AspectManager"
| manager-property="aspectManager">
| <aop:interceptor-ref name="DependencyAdvice"/>
| </aop:bind>
| ...
| </deployment>
|
i.e. we need to specify the manager-bean and manager-property attributes, which isn't ideal. I'd like to configure the name of where to find this somehow, maybe at the deployer level? Alternatively, something like:
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
| <aop:manager name="AspectManager" property="aspectManager"/>
| <aop:aspect xmlns:aop="urn:jboss:aop-beans:1.0"
| name="DependencyAdvice"
| class="org.jboss.test.aop.mcdefaultannotation.AnnotationReaderInterceptor">
| </aop:aspect>
|
| <aop:bind xmlns:aop="urn:jboss:aop-beans:1.0"
| pointcut="execution(* @org.jboss.test.aop.mcdefaultannotation.TestAnnotation->getAnnotationValue())">
| <aop:interceptor-ref name="DependencyAdvice"/>
| </aop:bind>
| ...
| </deployment>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4125127#4125127
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4125127
16 years, 11 months
[Design of POJO Server] - Re: EJB/War deployer ordering problem
by alesj
"pete.muir(a)jboss.org" wrote :
| Note, the deployment order is different if you deploy to the already running app server.
What do you mean by deployment order?
Here is my analysis of the problem:
anonymous wrote :
| Indexer EJB depends on persistence.units:ear=jboss-seam-dvd.ear,jar=jboss-seam-dvd.jar,unitName=dvdDatabase
|
| persistence.units:ear=jboss-seam-dvd.ear,jar=jboss-seam-dvd.jar,unitName=dvdDatabase depends on jboss.jca:name=dvdDatasource,service=DataSourceBinding
|
| jboss.jca:name=dvdDatasource,service=DataSourceBinding is picked up by RARDeployer which creates matching ServiceMetaData
|
| TomcatDeployer also creates ServiceMetaData
| And it's TomcatDeployer that deploys/starts Seam applications (for those unfamiliar with Seam).
| And in there Indexer EJB is being looked-up in JNDI. Resulting in failure.
|
| So, both TomcatDeployer and RARDeployer, need to be before ServiceDeployer (which deploys ServiceMetaData)
|
| And therefore why Indexer EJB is only fully installed after TomcatDeployer.
|
| I currently don't see how to solve this w/o Seam knowing about the dependency.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4125085#4125085
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4125085
16 years, 11 months
[Design of JCA on JBoss] - Re: JBAS-1808 - MCF MBeans
by vickyk
"adrian(a)jboss.org" wrote :
| * making the ManagedConnection an MBean, which is possible since ManagedConnections
| are relatively long lived.
| * forcing the MCF MBean to consolidate connection stats
|
I have started looking at JBAS-1808 and would like to get some pointers regarding the implementation details
* making the ManagedConnection an MBean
1) When ManagedConnection is created it should be registered as MBean.
2) The ManagedConnection MBean will have to expose the management/statistics data.
3) Finally we need management/statistics related operations defined in MCF MBean which will look/consolidate the data. The MCF MBean being referred here is org.jboss.resource.connectionmanager.RARDeployment .
The other option
* forcing the MCF MBean to consolidate connection stats
The org.jboss.resource.connectionmanager.RARDeployment can be updated to pull all the PreparedStatementCache data from the associated MCF instance which is available through getMcfInstance() method .
The connection creation/destruction in MCF should update the PreparedStatementCache related data in the MCF implementation(LocalManagedConnectionFactory Or XAManagedConnectionFactory) , this needs to be implemented .
This option looks complex .
Looking at the original requirement I could think of pulling the PreparedStatementCache from the JbossManagedConnectionPool MBean per DataSource.
As per the original requirement we need to
1) Get all the ManagedConnection from the Pool.
2) Find out the PreparedStatementCache associated with these ManagedConneciton in the pool.
Here I see the related data being pulled from the JbossManagedConnectionPool/InternalManagedConnectionPool .
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4125078#4125078
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4125078
16 years, 11 months
[Design of JBoss jBPM] - Re: Command facade API
by heiko.braun＠jboss.com
anonymous wrote : it's up to the process languages or products to use that block and create public API's with it.
OK, so we are talking about a JPDL web service facade.
anonymous wrote : another approach is not to leverage the current domain model objects (ProcessInstance, Token, ProcessDefinition,...) but instead just to define a completely separate set of limited DTO's just for the web service publication. then the web service would be fixed (not very extensible). and it would be easy to implement with JAXB since the DTO's are under control of the web service.
I think this is the way to go. I cannot pull the domain model because of it's dependencies and marshalling depth and furthermore I would like to keep control of the API that's getting exposed. Otherwise any change to the domain model could easily break the web service.
Another aspect that hasn't been mentioned is is versioning [1] and evolution of the web service facade. Obviously we won't have a one shot solution.
[1] http://www.ibm.com/developerworks/webservices/library/ws-version/
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4125042#4125042
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4125042
16 years, 11 months