"alesj" wrote :
| We're back to the same problem:
| How to map some ID from deployers (we set some predetermined metadata),
| to a bean's ScopeInfo, where our only info is className and bean's name,
| no idea if the bean is gonna be scoped.
|
The idea is that every Component/ControllerContext has a GUID.
When you create the ControllerContext from the Component, you copy the GUID.
The INSTANCE scope would then just be INSTANCE/GUID rather than
INSTANCE/BeanName.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170273#4170273
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170273
"wolfc" wrote :
| What is the exact function of MethodSignature as opposed to Method?
The idea is that eventually MDR will support loading annotations before the
class is loaded, e.g. for AOP using javassist in that case
you can't use the Method as the key, you've got to use the "signature".
Of course, people that use it at runtime can still use the Method.
Your problem is that there is no way to define @Inherited for a non-class Annotation.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/annotation/Inherited.html
Sub.class.getMethod("postConstruct").getAnnotation(PostConstruct.class) == null
is the correct behaviour absent some other semantic/hack
and therefore it should be the behaviour of the MetaData.
We could try to simulate this behaviour where you could configure
somewhere that @PostConstruct should do an @Inherited like behaviour
at the method level then make the
AnnotatedElementMetaDataLoader
do the extra work for those annotations.
I remember discussing this issue about 6 months ago?
e.g. whether it should also search interfaces (with the multiple inheritance
problem it would cause) but nothing came of the discussion.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170268#4170268
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170268
The pojo version of SBM is now being used in AS trunk. Let me know what bindings you'll want and I can add them to the bindings.xml file the AS uses (or, if you want to do it yourself, it's at https://svn.jboss.org/repos/jbossas/trunk/server/src/etc/conf/default/bin....)
Currently it has this related to the transaction manager:
| <!-- ********************* deploy/transaction-jboss-beans.xml ********************** -->
|
| <!-- JBossTS Recovery Manager -->
| <bean class="org.jboss.services.binding.ServiceBinding">
| <constructor>
| <parameter>TransactionManager</parameter>
| <parameter>${jboss.bind.address}</parameter>
| <parameter>4712</parameter>
| </constructor>
| </bean>
But that is unused, really more of a temporary placeholder, so it can be changed as you wish.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170202#4170202
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170202
This implementation was just checked in -- like 30 seconds ago ;)
To get the implemenation jar, you'd need to check out the current head of the AS trunk and build it. Once you've done that the jar can be found in build/output/jboss-5.0.0.CR2/server/.../lib/jboss-bindingservice.jar or in varia/output/lib/jboss-bindingservice.jar
I'm curious what you'd do with just the jar though, as opposed to the entire AS that uses it (which the current head now does.)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170192#4170192
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170192