[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by adrian@jboss.org
"kabir.khan(a)jboss.com" wrote : Reading this thread http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134204#4134204 I came back to this. Regarding 3) What would this xsd:refine map to in jaxb annotations? My understanding was that using jaxb it generates a schema from the annotations?
|
It doesn't map to anything .
The xsd:redefine, just specifies what is the default behaviour the JBossXBBuilder
which is to include types reachable from your hierarchy in your namespace
(absent any explicit namepace= in the annotations).
anonymous wrote :
| Apart from that, if I have understood you correctly, mc-commons.xsd would contain the current bean_deployer_2_0.xsd.
|
Yes, except the root elements (deployment, bean, etc.) and without a namspace
anonymous wrote :
| I would then be able to do
|
| | <aop>
| | <bean name="Bean" class="Foo"/>
| | <aspect class="MyAspect" scope="PER_VM">
| | <property name="thing">XXX</property>
| | </aspect>
| | </aop>
| |
|
Correct
anonymous wrote :
| If I wanted to do this the other way around, I would need to use xmlns on the aop specific elements
|
| | <deployment>
| | <bean name="Bean" class="Foo"/>
| | <aspect xmlns:aop="urn:jboss:aop-beans:1.0" class="MyAspect" scope="PER_VM">
| | <property name="thing">XXX</property>
| | </aspect>
| | </deployment>
| |
|
| I'm not sure what the xmlns should be for property, but apart from that is my understanding correct?
The idea is you don't need one.
What you defined is probably not correct unless your schema allows urn:jboss:bean-deployer:2.0:property
as an element of aspect.
The correct usage would be either
explicit
| <deployment>
| <bean name="Bean" class="Foo"/>
| <aspect xmlns:aop="urn:jboss:aop-beans:1.0" class="MyAspect" scope="PER_VM">
| <aop:property name="thing">XXX</aop:property>
| </aspect>
| </deployment>
|
or change the default namespace
| <deployment>
| <bean name="Bean" class="Foo"/>
| <!-- HERE - simple xmlns -->
| <aspect xmlns="urn:jboss:aop-beans:1.0" class="MyAspect" scope="PER_VM">
| <property name="thing">XXX</property>
| </aspect>
| </deployment>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134250#4134250
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134250
18 years, 1 month
[Design the new POJO MicroContainer] - Re: WiredMicrocontainerTest
by adrian@jboss.org
"alesj" wrote : "adrian(a)jboss.org" wrote :
| | I already went through and fixed this once and combined three or four classes you'd created in the package back into the main test class. :-)
| | There's a previous thread about it somewhere?
| |
| You call it 'N<->M problem', I call it OO approach. :-)
|
No. If it is OO you ask the question, isA (inheritance) or hasA (encapsulation)
In this case it isn't very clear, you can make arguments for either.
My test isA wired test
My test hasA wired controller registration
In general, if it is not clear, use hasA because it avoid the N<->M problem
(absent multiple inheritance :-) and enables greater reuse.
NOTE: Many people would argue that setters are not a correct use of encapsulation
(I just call it externalising the policy ;-).
But you can just make it a protected setter if you think it really breaks encapsulation
and you want policy controlled by subclasses (that ways its really no different from
constructor parameters except you don't have to create 5,000 constructors
for all the different policy parameters and their permutations. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134240#4134240
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134240
18 years, 1 month
[Design the new POJO MicroContainer] - Re: Wildcards and JBossXb Builder
by alesj
"adrian(a)jboss.org" wrote :
| I don't understand the question. Did you even read the thread I had with
| Kabir? You're a fast reader if you did, it was a long thread.
|
I did, post by post when they came up.
But like you said, it's a long thread, which took quite some time to 'grow', so probably some details got blurred. :-)
"adrian(a)jboss.org" wrote :
| The idea is to make the value type and group (and other xsd artificats from the mc) part of your schema/namespace.
|
I get the idea.
It was this automagic that I didn't see/understand:
"adrian(a)jboss.org" wrote :
| e.g. this will automagically create a value element/type in your
| namespace with the MC's value group defined in your namespace
|
| | @XmlElement(name="value")
| | public void setValue(ValueMetaData value)
| |
|
So the only work to be done is to split those common elements into mc-commons.xsd?
But will that jaxb automagic work currently ootb?
Since I believe I tried something similar already and got exception on the types that need special adapter, e.g. AutowireType --> AutowireTypeValueAdapter.
Not being able to handle them, saying there is no existing adapter for that particular type.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134230#4134230
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134230
18 years, 1 month