@Service and @Consumer in metadata

[aloubyansky]

Issue JBMETA-20 Include JBoss extensions to EJB3

I'd like to clarify how this should be represented in the metadata. The test looks wrong to me. It expects to find MyService and MyConsumer among the beans in EjbJar30MetaData. I'd think they should be added later at merge.

[kabirkhan]

That might well be the case. I wrote the test quickly in Neuchatel as requested by Carlo, so feel free to replace it with something more appropriate. In any case @Service + @Consumer need to be represented in the metadata, but one of the EJB 3 guys will need to clarify where

[starksm64]

Issue JBMETA-20 Include JBoss extensions to EJB3

I'd like to clarify how this should be represented in the metadata. The test looks wrong to me. It expects to find MyService and MyConsumer among the beans in EjbJar30MetaData. I'd think they should be added later at merge.

They can't possibly be in the spec EjbJar30MetaData. They can only be in the JBossMetaData where the jboss specific xml and annotations would show up.

[aloubyansky]

What do you think about changing EjbJar30Creator to produce JBossMetaData instead of the EjbJar30MetaData, which would contain merged metadata obtained from the spec and jboss annotations?

It seems to me, it would be better to process the spec and JBoss annotations at one go instead of doing it in two steps and then merge.

[alrubinger]

What do you think about changing EjbJar30Creator to produce JBossMetaData instead of the EjbJar30MetaData

From a naming perspective alone, this seems misleading.

Do we have any ambitions towards using metadata to merge non-JBoss descriptors looking forward? If so, we'd need to keep the two-step process and add support for other vendors' implementations later. Food for thought before we centralize everything to gain minor some deployment-time improvements.

S,
ALR

[wolfc]

It's not a naming issue.

It might be interesting to have a deployer chain for other vendor descriptors, but that is not something we would/could support.

An alternative for @Consumer and @Service is having a JBoss5Creator and then leave it up to the merge.

[alrubinger]

"wolfc" wrote:
It might be interesting to have a deployer chain for other vendor descriptors, but that is not something we would/could support.

OT: So we leave the door open for our growing community. :)

"wolfc" wrote:
An alternative for @Consumer and @Service is having a JBoss5Creator and then leave it up to the merge.

Yes, this is what I was getting at. Change the *name* of the class to JBoss5Creator.

[aloubyansky]

Actually, I didn't think about optimization. In case of jboss.xml, every bean there can be identified by the ejb-name, other metadata components that need filling in some details can also be identified by their names. So, parsing jboss.xml alone we can get EJBs and then merge them with the spec ones.
In case of annotations, it's different in the sense that looking only at the jboss annotations we can't identify an EJB or any other metadata component. I.e. the JBoss5Creator would still need to look at the spec annotations. So, I thought why not combine the processing of both.

[aloubyansky]

Once again, are there reasons not to process spec and jboss annotations at once? The JBoss5Creator would do it anyway.

[aloubyansky]

I've trying to follow this idea and this is what I think the big picture should look like:
1) the spec and jboss deployment descriptors are parsed and merged into the JBossMetaData
2) the spec and jboss annotations are parsed and also merged into the JBossMetaData (this I still think should be done in one go since the source is the same unlike XML and to avoid duplicate parsing of the spec annotations)
3) merge the two instances of JBossMetaData obtained on the previous steps with the DDs as the override.

I already wrote JBoss50Creator which parses EJB3 annotations and produces JBossMetaData (not committed at the moment)

I am currently missing the step 3). So I am going to add another merge method for JBossXXXMetaData classes that will merge JBoss metadata.

Any other suggestions/ideas?

[emuckenhuber]

I have two questions regarding the @Service and @Consumer annotation:

1) a @Service annotated Bean inherits more or less the annotation processing as a @Stateless bean ?

2) the @Consumer annotation defines:

ActivationConfigProperty[] activationConfig()

which is not represented by the JBossConsumerBeanMetaData nor defined in the jboss_5_0.xsd.
So should this be added to the metadata and the xml schema?

[wolfc]

"emuckenhuber" wrote:
1) a @Service annotated Bean inherits more or less the annotation processing as a @Stateless bean ?

@Stateful with a single instance is a better analogy.
Where it not that in the future I want a SLSB to be able to expose a JMX view as well.

"emuckenhuber" wrote:
2) the @Consumer annotation defines:

ActivationConfigProperty[] activationConfig()

which is not represented by the JBossConsumerBeanMetaData nor defined in the jboss_5_0.xsd.
So should this be added to the metadata and the xml schema?

Yes.

[emuckenhuber]

"wolfc" wrote:

"emuckenhuber" wrote:
2) the @Consumer annotation defines:

ActivationConfigProperty[] activationConfig()

which is not represented by the JBossConsumerBeanMetaData nor defined in the jboss_5_0.xsd.
So should this be added to the metadata and the xml schema?

Yes.

So maybe JBossConsumerMetaData should extend JBossMessageDrivenBeanMetaData instead of JBossEnterpriseBeanMetaData?