8:45 a.m.
I've added the parsing to the ClientLauncher which revealed a number of
other issues, "fixing" these now makes the ejb3 appclient tests pass.
* HARDWIRING
I had to hack the resolver to hardwire the schemalocation -> annotated class
There must be a better way to do this?
Perhaps we can include a META-INF/schema-binding.xml in the jar
and jbossxb can look for this config at bootstrap/hotdeployment?
ClientLauncher.java - YUCK! :-)
| /** The schema resolver */
| private static DefaultSchemaResolver resolver = (DefaultSchemaResolver)
SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver();
|
| static
| {
| // FIXME hardwiring
| resolver.addClassBindingForLocation("application-client",
ApplicationClient14DTDMetaData.class);
| resolver.addClassBindingForLocation("application-client_1_2.dtd",
ApplicationClient14DTDMetaData.class);
| resolver.addClassBindingForLocation("application-client_1_3.dtd",
ApplicationClient14DTDMetaData.class);
| resolver.addClassBindingForLocation("application-client_1_4.xsd",
ApplicationClient14MetaData.class);
| resolver.addClassBindingForLocation("application-client_5.xsd",
ApplicationClient5MetaData.class);
| resolver.addClassBindingForLocation("jboss-client",
JBossClient5DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss-client_3_0.dtd",
JBossClient5DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss-client_3_2.dtd",
JBossClient5DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss-client_4_0.dtd",
JBossClient5DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss-client_4_2.dtd",
JBossClient5DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss-client_5_0.dtd",
JBossClient5DTDMetaData.class);
| resolver.addClassBindingForLocation("jboss-client_5_0.xsd",
JBossClient5MetaData.class);
| }
|
* PROFILE SERVICE
Really we shouldn't be parsing the jar anyway.
The profile service may override the configuration so we should have an option
to retrieve the merged (and overridden) JBossClientMetaData from the server
and bootstrap from there (including downloading the classes/jar?).
Something like:
| ./jboss-client.ch server=hostname:1099 client=my.ear/some.car
|
* MAIN
I added the code to main() for the parsing, but the ejb3 testsuite doesn't test this?
* PersistenceContextHandler
I found the same problem that Scott had with Environment vs RemoteEnvironment
"Fixed" it with a similar hack to the jndi binding described on the other
thread.
I guess there is some missing implementation here?
| +++ src/main/org/jboss/injection/PersistenceContextHandler.java (working copy)
| @@ -23,6 +23,7 @@
|
| import org.jboss.metadata.javaee.spec.Environment;
| import org.jboss.metadata.javaee.spec.PersistenceContextReferenceMetaData;
| +import org.jboss.metadata.javaee.spec.RemoteEnvironment;
| import org.jboss.logging.Logger;
| import org.jboss.annotation.IgnoreDependency;
|
| @@ -42,7 +43,7 @@
| * @version $Revision$
| * @Inject and create Injectors
| */
| -public class PersistenceContextHandler<X extends Environment> implements
InjectionHandler<X>
| +public class PersistenceContextHandler<X extends RemoteEnvironment> implements
InjectionHandler<X>
| {
| @SuppressWarnings("unused")
| private static final Logger log = Logger
| @@ -51,8 +52,10 @@
| public void loadXml(X xml, InjectionContainer container)
| {
| if (xml == null) return;
| - if (xml.getPersistenceContextRefs() == null) return;
| - for (PersistenceContextReferenceMetaData ref :
xml.getPersistenceContextRefs())
| + if (xml instanceof Environment == false) return;
| + Environment env = (Environment) xml;
| + if (env.getPersistenceContextRefs() == null) return;
| + for (PersistenceContextReferenceMetaData ref :
env.getPersistenceContextRefs())
| {
| String encName = "env/" + ref.getPersistenceContextRefName();
| // we add injection target no matter what. enc injection might be
overridden but
|
* TEST CLASSPATH
Why is it necessary to add jars other than jbossall-client.jar to the classpath
to run the client? See my comment in ejb3/build-test.xml
I added jboss-metdata.jar which should be included (at least in part)
in jbossall-client.jar?
| <path id="client.classpath">
| <pathelement path="${jboss.dist}/client/jbossall-client.jar"/>
|
| <!-- FIXME - shouldn't these be in jbossall-client.jar???? -->
| <path refid="apache.codec.classpath"/>
| <path refid="apache.log4j.classpath"/>
| <path refid="apache.logging.classpath"/>
| <path refid="jboss.test.classpath"/>
| <path refid="sun.servlet.classpath"/>
| <pathelement
path="${jboss.dist}/client/jboss-ejb3-client.jar"/>
| <pathelement path="${jboss.dist}/lib/jboss-vfs.jar"/>
| <path refid="jboss.microcontainer.classpath"/>
| <path refid="jboss.metadata.classpath"/>
| </path>
|
I'll leave Carlo to decide which of these issues needs further attention
in the EJB3 project.
We should probably raise a main appserver JIRA for the jbossall-client.jar issue?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104144#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...