-
15. Re: Unifying metadata
wolfc Sep 19, 2007 5:36 AM (in response to starksm64)As far as I can see in server MethodMetaData is instantiated either in ApplicationMetaData or in the EjbJarObjectFactory. In the new project ApplicationMetaData is only a delegator, which instantiates (indirectly) subclasses of org.jboss.metadata.MethodMetaData as delegators, so the EjbJarFactory needs to use the new model and create the ApplicationMetaData delegator instead. It should work, but shouldn't we ditch all the old stuff?
-
16. Re: Unifying metadata
aloubyansky Sep 19, 2007 6:23 AM (in response to starksm64)Yes, as Carlo wrote there are three subclasses of the MethodMetaData. In which sense it's not a complete replacement? It seems to have all the public methods of the old one. Except for addParam and importEjbJarXml that are used during parsing.
-
17. Re: Unifying metadata
adrian.brock Sep 19, 2007 8:15 AM (in response to starksm64)"scott.stark@jboss.org" wrote:
The org.jboss.metadata from the metadata project, for example:
https://svn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java/org/jboss/metadata/MethodMetaData.java
is not usable as a replacement for the server project version, because its abstract. Its also not a complete replacement for the existing version. How was this generated, and why is the MethodMetaData abstract?
It isn't possible to provide a complete mapping of some of the metadata without
going through a long winded and unnecessary mapping/combining process of the different
parts of the model. The method metadata is stored in multiple places.
If we'd had interfaces in the correct places in the original model then we could
do a lot more.
In practice it isn't necessary. The MethodMetaData is never accessed for everything
all at once. So we just provide delegates for the aspect where it is used.
e.g. There is a getTransactionMethods() in the old BeanMetaData
so we create a delegate that only gives access to the transaction attributes of the method.
Or similarly for permissions.
https://svn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java/org/jboss/metadata/BeanMetaData.java -
18. Re: Unifying metadata
adrian.brock Sep 19, 2007 8:17 AM (in response to starksm64)"wolfc" wrote:
but shouldn't we ditch all the old stuff?
No. Unless we are going to ditch the whole EJB2 container and replace it with
EJB3 equivalents (including a CMP1.1 and CMP2 impl for backwards compatibility).
The old BeanMetaData is part of the api for the old EJB2 container that people
used to write their interceptors. -
19. Re: Unifying metadata
adrian.brock Sep 19, 2007 8:19 AM (in response to starksm64)"alex.loubyansky@jboss.com" wrote:
Except for addParam and importEjbJarXml that are used during parsing.
All the parsing has been dropped.
Any mutation that wasn't part of the parsing should be covered by methods
that throw UnsupportedOperationExceptions (unless you can figure out how
to support the mutation operation via the bridge :-) -
20. Re: Unifying metadata
starksm64 Sep 19, 2007 11:12 AM (in response to starksm64)I wasn't sure how much of the old metadata should be usable as a drop in replacement. So it seems that the code that will have to change is the parsing related uses. There are also classes missing like org.jboss.metadata.ClientMetaData, but this and the ClientDeployer should be replaced by the ejb3 parsing deployer versions. Getting the metadata out of the server project is what I'm looking at first.
-
21. Re: Unifying metadata
adrian.brock Sep 19, 2007 12:12 PM (in response to starksm64)"scott.stark@jboss.org" wrote:
I wasn't sure how much of the old metadata should be usable as a drop in replacement. So it seems that the code that will have to change is the parsing related uses.
Any parsing related uses will need to be updated to the new parsing anyway.
There are also classes missing like org.jboss.metadata.ClientMetaData, but this and the ClientDeployer should be replaced by the ejb3 parsing deployer versions. Getting the metadata out of the server project is what I'm looking at first.
I only got as far as parsing the root j2ee/avaee and ejb2/3 xml (and even then
I didn't do the webservices stuff).
The others like client, web and connector stuff probably needs to be brought into line
if it is relevant. i.e. it is necessary to share the same model with/across EJB2/3
for some reason. -
22. Re: Unifying metadata
wolfc Sep 20, 2007 3:00 AM (in response to starksm64)I'll start on client meta data today, including the delegator for the old.
-
23. Re: Unifying metadata
starksm64 Sep 20, 2007 7:56 AM (in response to starksm64)I don't think the ClientDeployer/ClientMetaData will exist once the metadata project is in use.
-
24. Re: Unifying metadata
wolfc Sep 20, 2007 8:25 AM (in response to starksm64)I'm thinking the same thing. So I can skip the delegator.
I spotted a missing method though in ApplicationMetaData: getDisplayName. There might be others as well. -
25. Re: Unifying metadata
starksm64 Sep 20, 2007 8:36 AM (in response to starksm64)In going through the initial extraction of metadata out of jbossas, its seems that what needs to be done is:
1. The existing ObjectModelFactoryDeployer based deployers producing legacy metadata need to be converted to SchemaResolverDeployer type deployers that produce the new metadata, and then create the legacy wrapper using the new metadata as the delegate. The JBossXBBuilder would be used to create the SchemaBinding for the new metadata.
One little issue here is that the SchemaResolverDeployer does not have a SchemaBindingResolver getResolver() method to allow subclasses to easily extend the default resolver.
2. Fix up misc uses of the legacy metadata. Missing methods, creation without the wrapper, etc. -
26. Re: Unifying metadata
adrian.brock Sep 20, 2007 8:43 AM (in response to starksm64)"wolfc" wrote:
I'm thinking the same thing. So I can skip the delegator.
The client stuff in EJB2 never had a container/interceptors that users could plug into,
so the client metadata isn't really part of the public api.
i.e. nobody uses it but us, so there's no need for a bridge -
27. Re: Unifying metadata
starksm64 Sep 20, 2007 8:48 AM (in response to starksm64)"wolfc" wrote:
I'll start on client meta data today, including the delegator for the old.
We do need a unified SchemaBinding for the application-client.xml (1.4/5.0) and jboss-client.xml though. -
28. Re: Unifying metadata
adrian.brock Sep 20, 2007 8:49 AM (in response to starksm64)"scott.stark@jboss.org" wrote:
1. The existing ObjectModelFactoryDeployer based deployers producing legacy metadata need to be converted to SchemaResolverDeployer type deployers that produce the new metadata, and then create the legacy wrapper using the new metadata as the delegate. The JBossXBBuilder would be used to create the SchemaBinding for the new metadata.
One little issue here is that the SchemaResolverDeployer does not have a SchemaBindingResolver getResolver() method to allow subclasses to easily extend the default resolver.
This was something I asked Alex to look at.
I'm not sure how much he has done?
Currently there is a POJO/MBean that lets you specify
schema -> SchemaBindingInitializer
(there are factory settings)
What's required for the JBossXBBuilder is instead
schema -> annotated class name (the root class)
and build the schemabinding from that.
In fact, since the annotated class name contains the schema name
as an annotation, all that's really required is being able to add classes
(unless we also want to specify aliases as well).
Also, JBossXB needs updating so we can do
dtd -> annotated class name
or
dtd -> schema
so we can parse xmls with legacy dtds using the schema binding.
This requires a change to JBossXB's SAXParser to trap the dtd event
and store it somewhere for when the schema handling tries to resolve
schema. i.e. resolve using the dtd public/system id instead of the non-existant
xmlns declaration. -
29. Re: Unifying metadata
starksm64 Sep 20, 2007 9:14 AM (in response to starksm64)"adrian@jboss.org" wrote:
Currently there is a POJO/MBean that lets you specify
schema -> SchemaBindingInitializer
(there are factory settings)
What's required for the JBossXBBuilder is instead
schema -> annotated class name (the root class)
and build the schemabinding from that.
In fact, since the annotated class name contains the schema name
as an annotation, all that's really required is being able to add classes
(unless we also want to specify aliases as well).
Also, JBossXB needs updating so we can do
dtd -> annotated class name
or
dtd -> schema
so we can parse xmls with legacy dtds using the schema binding.
This requires a change to JBossXB's SAXParser to trap the dtd event
and store it somewhere for when the schema handling tries to resolve
schema. i.e. resolve using the dtd public/system id instead of the non-existant
xmlns declaration.
So it seems the jbossxb and jbossxb-builder projects need to be merged, and the DefaultSchemaResolver/SchemaResolverConfig updated to support these mappings. With this there would be no need to sublcass the SchemaResolverDeployer resolver. I can work on that today if we agree to merge these since both projects are dependencies of the metadata project.