JBossDeveloper

"alesj" wrote:

But I'll stick to getInstance. ;-)

"alesj" wrote:

"adrian@jboss.org" wrote:

You don't need to code this yourself. Just add @XmlEnumValues to the enum class.
JBoss/AXB already knows how to parse enums.

Does this include the old JBossXB handlers?

TypeBInding type = schemaBinding.getTypeBinding(qNameFromSchema);
type.setValueAdapter(new EnumValueAdapter(...));

"alesj" wrote:

How do you use this with attributes?

 // Don't override this
 public void attributes(Object o, QName elementName, ElementBinding element, Attributes attrs, NamespaceContext nsCtx)
 {
 if(attrsHandler != null)
 {
 attrsHandler.attributes(o, elementName, element.getType(), attrs, nsCtx);
 }
 }

 // Set an attribute handler on the constructor
 public DefaultElementHandler(AttributesHandler attrsHandler)
 {
 this.attrsHandler = attrsHandler;
 }

public class MyAttributeHandler extends AttributeHander
{
 public void attribute(QName elemName,
 QName attrName,
 AttributeBinding binding,
 Object owner,
 Object value)
 {
 AbstractInjectionValueMetaData injection = (AbstractInjectionValueMetaData) owner;

 String localName = attrName.getLocalPart();
 ...
 else if ("type".equals(localName))
 injection.setInjectionType((AutowireType) value)
 }
}

Why have you created a package called "enums"?

That's just stupid. Packages should be based on what they provide
not what their contents are.
Would you create a package called "classes"? :-)

e.g. The metatype project has
org.jboss.metatype.api
- annotations
- types
- values

I think a package called "annotations" is stupid as well, but it seems to be a convention. :-)

Either put the enums in the annotations package or create a package called
model or something. This package would also contain callback interfaces referenced
(like the ScopeFactory in the metadata repository) so calling it "enums" is plain wrong.

A couple of related issues now that I look at the annotations:

1) Why do you have class names as strings in the annotations?
To be able to read the annotations at all the classloader must exist
so there's no problem with letting the users specify classes.

2) How can the Factory(Method) annotations work?

These are used at object construction. You don't know the type until
the object is constructed so how can read the annotations? :-)

I could understand it if this was somehow used to annotation a package
with what beans need constructing and how to do it.
e.g.

@Beans
({
 @Bean(name="blah", class=MyBean.class),
 @Bean(name="blah2", factory=MyFactory.class, method="create")
})
package com.acme;

"adrian@jboss.org" wrote:

2) How can the Factory(Method) annotations work?

These are used at object construction. You don't know the type until
the object is constructed so how can read the annotations? :-)

"anil.saldhana@jboss.com" wrote:
Adrian, are you currently at Hyde Park in London (or the particular park) where you can complain/bitch about things without worrying about being arrested?

"alesj" wrote:

"adrian@jboss.org" wrote:
Why have you created a package called "enums"?

Now you complain. :-)
I proposed the name in the first few posts.
Just following the silence rule. ;-)

@Factory does what our constructor xml factory does as well.
It just happens to be on the class rather than on the constructor.
If the factoryClass is not specified, the class on which it is defined is used.

@FactoryMethod is probably an extension, but functionally similar to @Factory with class and method specified.
You scan the static methods which are annotated to be factory methods.

/**
 * Mark static method as factory method.
 *
 * @author <a href="mailto:ales.justin@jboss.com">Ales Justin</a>
 */
public @interface FactoryMethod