JBossDeveloper

"alesj" wrote:

Is install callbacks even legit for beanfactory?

"adrian@jboss.org" wrote:
I've been speaking with Alexey and we'll probably add support for
some kind of @JBossXMLMap annotation.

I already started one.

It solves a more general problem which is to dump an xsd schema from a
JBossXB SchemaBinding, although its not complete:

http://viewvc.jboss.org/cgi-bin/viewvc.cgi/common/jbossxb/trunk/src/test/java/org/jboss/test/xb/builder/SchemaPrinter.java?revision=2555&view=markup

This thread has brought up the issue that the new JBoss MC xml parsing
is not declaring all its root element and types properly with the correct annotations.

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132601#4132601

Also we need to find out from Alex what we need to get the maps to work.

You obviously missed my point about the generated SchemaBInding not matching the xsd. I've fixed all this.

I've also made it so there are top level schemas for javabean 1.0, 2.0 and the MC 1.0 and 2.0
the 2.0 and 1.0 respectively were completely missing. For the javabean 1.0 i've disabled
the constructor element as per schema. It would be too much effort to
retrofit the MC classes such that we can generate a proper 1.0 schema that matches the xsd
(although I did do it for the top level deploymen element).
For 3.0 we need to properly control how these metadata classes evolve.

Anyway, I re-opened the issue.
This work isn't complete until we use it (rather than just testing :-).

Work still to do:
0) Do the same thing to the PolicyMetaData/parsing
1) Get a jbossxb release that includes these schemas in the factory settings
(see the singleton schema resolver bootstrap code)
2) Remove the old SchemaBindingInitializer
3) Co-ordinate with Kabir for the aop parsing and update the Spring parsing.

I also moved the GenericBeanFactoryMetaData2 into the spi and
called it GenericBeanFactoryMetaData.
Kabir wants to reuse it for AOP.

We need to double check with Kabir that he isn't forced to ues the classes
from metadata.plugins directly. This may require adding new features to
the BeanMetaDataBuilder.

I also spoke to Alex about getting two new features related to schema config.

1) Lazy initialization of schema bindings.

Currently when you configure a class in the bootstrap, it has to exist
at startup to be included. e.g. the aop and spring schemas aren't included in JBossAS
because they aren't in the bootstrap classes.
So you have to configure them manually.

It would be better if this was done "on-demand".

2) Allow specification of config in the top level element (similar to the way
schema locations are handled) which doesn't require the "2 phase"
configuration that is currently done.

<deployment xmlns:jbxb="urn:jbossxb:2.0" jbxb:schemabinding="urn:jbossjms:5.0 org.jboss.jms.Whatever"/>

"alesj" wrote:

"adrian@jboss.org" wrote:

3) ... update the Spring parsing.

Do we really want to also re-write Spring schema into JBossXB Builder annotated metadata, hence removing the .xsd file?

I don't really want to modify/remove anything that exists in Spring.
But on the other hand, we're already doing that by shipping slightly modified schema file (due to that fix with infinity * infinity).

Doing that also defeats the purpose of having single metadata to handle both schemas, MC and Spring's.
Since the functionality is almost the same, it's the attribute and element names that differ.