-
15. Re: Unifying metadata
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
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
"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
"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
"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
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
"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
I'll start on client meta data today, including the delegator for the old.
-
23. Re: Unifying metadata
I don't think the ClientDeployer/ClientMetaData will exist once the metadata project is in use.
-
24. Re: Unifying metadata
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
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
"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
"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
"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
"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.