[Design the new POJO MicroContainer] - Re: classloading dependencies
by adrian@jboss.org
"jhalliday" wrote :
| > That's already been fixed
|
| .. but the fix is not in AS branch 5.x yet.
|
The fix is in Branch_5_0
| 12:54:24,440 INFO [ServerImpl] Release ID: JBoss [Morpheus] 5.0.1.GA (build: SVNTag=JBoss_5_0_1_GA date=200902091457)
| <snip/>
| 12:54:32,351 WARN [RequirementDependencyItem] VFSClassLoaderPolicyModule bindings-classloader:0.0.0 resolved ModuleRequirement{jmx-classloader [0.0.0,?)} to VFSClassLoaderPolicyModule jmx-classloader:0.0.0 which has import-all=true. Cannot check its consistency.
|
anonymous wrote :
| One further question: Assuming I have a choice between the -beans.xml and -classloading.xml techniques for specifying the dependency, what is considered best practice? This is for a transactions demo app we'll be shipping from JBoss, so if there is a 'right way' of doing things I guess I should use it :-)
Best practice is to depend upon packages rather than modules
because it is less susceptable to refactoring problems.
That requires the jboss-classloading.xml
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208510#4208510
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208510
15 years, 4 months
[Design of POJO Server] - JBMETA-110: CreateDestination metadata feature / new metadat
by wolfc
We need a way to add new vertical features without affecting the horizontal layers. For example CreateDestination required a change to metadata. It'll will also require a new annotation processor, but that one can (/should) be configured on the EjbAnnotationMetaDataDeployer. (Right now hardcoded in JBoss50Creator.)
For EJBTHREE-987 I stuffed it into the activation properties, which are filtered out when the end point needs to be created. (Let me take the liberty to give myself Brock points for that kind of solution.)
https://jira.jboss.org/jira/browse/EJBTHREE-987
We may end up with tons of features which should not be coded within jboss-metadata itself (cache configurations for example). And I want to abuse it to allow EJB 3.1 to become a true extension.
So we need a blueprint which can us forward.
To ramble a bit on: maybe an xsd that allows for 'random' elements within bean metadata and then have a deployer split those up. Next deployer picks up and deploys something.
<session>
| <ejb-name>MyEjb</ejb-name>
| <cache xmlns:mycache><max>10</max></cache>
| </session>
For the jboss xsd that should not pose a problem, but how will this be reflected into code without losing type safety?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208486#4208486
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208486
15 years, 4 months