I guess the majority of EJB2 applications would be ported from previous JBoss versions rather than developed from scratch for JBoss 5. In that case, it would be better to have the same EJB2 containers and configuration. That work well and, AFAIK, are in the maintenance and there haven't been plans to major refactor or add new features.
Plus, new EJB2 containers would be one more module to maintain, support, document, etc.
What would be the reasons to go for it?
EJB 3 will barf if it encounters such a DD. How will we keep the two apart?
What is EJB3 in this case? I thought only the parsing deployers will have to deal with the XML and schema versions and produce the metadata that the EJB containers will use.
We could use a different namespace or version to keep the two apart.
We use the schema defined in trunk/ejb3/src/resources/schema/jboss_5_0.xsd.
Which is also at: http://www.jboss.org/j2ee/schema/jboss_5_0.xsd
This schema is different than the one used by EJB 2, so we've a clash here.
That schema does not match the documents that can be unmarshalled into the org.jboss.metadata.ejb.jboss.JBossMetaData we are producing from the jaxb/jbossxb annotations on the unified metadata view. We will have to create a unified jboss_5_0.xsd schema that uses namespaces to isolate the legacy config elements from the unified javaee/jboss5 common config elements. Anything specific to the ejb2 containers should be under a non-default legacy namespace. We can't do this until the unified metadata is finalized.
I have a reasonable jboss/standardjboss impl that I'm going to start testing as a replacement for the jbossas trunk server org.jboss.metadata usage today.
After that the AnnotationScanningDeployer, ReferenceResolverDeployer need to be worked on to get the ejb3 layer to a unified metadata model.
There are conflicting webservice service ref metadata in use by ejb3:
org.jboss.wsf.spi.serviceref.ServiceRefMetaData - from jbossws-spi
org.jboss.ws.integration.ServiceRefMetaData - from jboss-metadata
The ejb3 layer is making use of the org.jboss.wsf.spi.serviceref.ServiceRefMetaData, while the metadata classes are using org.jboss.ws.integration.ServiceRefMetaData. Trying to compile the ejb3 module against the current jboss-metadata.jar results in conflcits:
[javac] /home/svn/JBossHead/jboss-head/ejb3/src/main/org/jboss/injection/WebServiceRefHandler.java:55: incompatible types
[javac] found : org.jboss.ws.integration.ServiceRefMetaData
[javac] required: org.jboss.wsf.spi.serviceref.ServiceRefMetaData
[javac] for (ServiceRefMetaData sref : xml.getServiceRefs())
This is with the org.jboss.ejb3.metamodel classes deleted from the ejb3 project in favor of those in the jboss-metadata project. I assume the org.jboss.wsf.spi.serviceref.ServiceRefMetaData usage needs to be replaced with org.jboss.ws.integration.ServiceRefMetaData throughout the ejb3 project?
No I believe org.jboss.wsf.spi.serviceref.ServiceRefMetaData is the new one. org.jboss.ws.integration is an old package in jboss-metadata.
Ok, I have dropped the org.jboss.ws.integration.* from the jboss-metadata project and am working on getting ejb3 to build with the overlapping jboss-metadata classes removed from the ejb3 project.
I had to move the web metadata into the jboss-metadata project in order for the references to be consistent across the containers. That is done, but its going to take another day to get the existing WebMetaData uses converted.
I got this very non-descriptive error:
org.jboss.deployers.spi.DeploymentException: The xml META-INF/jboss.xml is not well formed!
It should at least tell me why we think it's not well formed.
Also currently jboss_5_0.xsd has http://java.sun.com/xml/ns/javaee as the target namespace which I think should be changed to a JBoss one.
I've got a first draft of a new jboss_5_0.xsd in jboss-metadata. I'm not yet happy with:
<?xml version="1.0"?> <jboss version="3.0" xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss_5_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"> <enterprise-beans> <session> <javaee:ejb-name>StatefulOverrideBean</javaee:ejb-name> <jndi-name>StatefulOverride</jndi-name> </session> </enterprise-beans> </jboss>
Either I take ejb-nameType into jboss namespace or convince everybody that this is the way. After that is resolved, I'll commit.
Note that the unit tests in jboss-metadata did not pick this up. I found out in trunk that stuff was going haywire.
In the original xsd we also have ejb-name defined, so I'm now using that one. I've also updated JBossXBTestDelegate to make schema validation an option.
carlo, not sure if this is relevant. I saw that u added the schema to src/resources in the metadata project.
Just remember that maven will add the schema to the metadata jars. If that is not intended and the xsd is just for the tests, then it needs to go to test/resources or such.