JBoss-4.0.4.GA and XB-1.0.0.CR5+

[aloubyansky]

There is a confusing compatibility issue between XB versions up to 1.0.0.CR4 and 1.0.0.CR5 that I would call as binary-but-not-Java-API incompatibility. The issue itself is described here http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossXB100CR5InJBoss404GA

The reason for removing the API that's causing the trouble is that the API is old and not actually used by anyone. So, I don't want this API to appear in the future CR's and releases (if ever) of XB.

I understand that asking clients who want to use JBossWS version that relies on XB-1.0.0.CR5 or later to recompile 4.0.4.GA with the required XB version is not going to work.

To workaround the incompatibility I could release a special binary for 4.0.4.GA every time I release a new version of XB. These binaries could be used with any JBoss version. But all JBoss versions after 4.0.4.GA should be compiled with the XB-1.0.0.CR5 or later.

Would this work for everyone? Or do you think I should reinstate the old API now and proceed with the long planned refactoring that includes SchemaBinding API and public API cleanup (probably creating new Java packages for them) on another branch? But the compatibility would still be a question to answer.

[starksm64]

The location of the ObjectModelFactorySimpleSubDeployerSupport call that is failing is:

Caused by: java.lang.NoSuchMethodError: org.jboss.xb.binding.Unmarshaller.unmars
hal(Ljava/lang/String;Lorg/jboss/xb/binding/ObjectModelFactory;Lorg/jboss/xb/bin
ding/metadata/unmarshalling/DocumentBinding;)Ljava/lang/Object;
 at org.jboss.deployment.ObjectModelFactorySimpleSubDeployerSupport.parse
MetaData(ObjectModelFactorySimpleSubDeployerSupport.java:52)
 ... 68 more

The parse of the conf/login-config.xml is also failing. The previous 1.0.0.CR4 version had the following methods:

 public abstract java.lang.Object unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, org.jboss.xb.binding.metadata.unmarshalling.DocumentBinding) throws org.jboss.xb.binding.JBossXBException;

 public abstract java.lang.Object unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, java.lang.Object) throws org.jboss.xb.binding.JBossXBException;

It would seem that a call like unmarshaller.unmarshal(url.toString(), factory, null) should not even be compiling as its ambiguous. Obviously its binding to the DocumentBinding variation as can be seen via javap -c:

[starksm@banshee9100 lib]$ javap -classpath 'jboss-jmx.jar;jboss-system.jar' -c
 org.jboss.deployment.ObjectModelFactorySimpleSubDeployerSupport
Compiled from "ObjectModelFactorySimpleSubDeployerSupport.java"
public abstract class org.jboss.deployment.ObjectModelFactorySimpleSubDeployerSupport extends org.jboss.deployment.SimpleSubDeployerSupport{
...

protected void parseMetaData(org.jboss.deployment.DeploymentInfo, java.net.URL)
 throws org.jboss.deployment.DeploymentException;
 Code:
 0: invokestatic #2; //Method org/jboss/xb/binding/UnmarshallerFactory.newInstance:()Lorg/jboss/xb/binding/UnmarshallerFactory;
 3: invokevirtual #3; //Method org/jboss/xb/binding/UnmarshallerFactory.newUnmarshaller:()Lorg/jboss/xb/binding/Unmarshaller;
 6: astore_3
 7: aload_0
 8: invokevirtual #4; //Method getObjectModelFactory:()Lorg/jboss/xb/binding/ObjectModelFactory;
 11: astore 4
 13: aload_1
 14: aload_3
 15: aload_2
 16: invokevirtual #5; //Method java/net/URL.toString:()Ljava/lang/String;
 19: aload 4
 21: aconst_null
 22: invokeinterface #6, 4; //InterfaceMethod org/jboss/xb/binding/Unmarshal
ler.unmarshal:(Ljava/lang/String;Lorg/jboss/xb/binding/ObjectModelFactory;Lorg/jboss/xb/binding/metadata/unmarshalling/DocumentBinding;)Ljava/lang/Object;
 27: putfield #7; //Field org/jboss/deployment/DeploymentInfo.metaData:Ljava/lang/Object;
 30: goto 57
 33: astore_3
 34: new #9; //class java/lang/StringBuffer
 37: dup
 38: invokespecial #10; //Method java/lang/StringBuffer."<init>":()V
 41: ldc #11; //String Error parsing meta data
 43: invokevirtual #12; //Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
 46: aload_2
 47: invokevirtual #13; //Method java/lang/StringBuffer.append:(Ljava/lang/Object;)Ljava/lang/StringBuffer;
 50: invokevirtual #14; //Method java/lang/StringBuffer.toString:()Ljava/lang/String;
 53: aload_3
 54: invokestatic #15; //Method org/jboss/deployment/DeploymentException.rethrowAsDeploymentException:(Ljava/lang/String;Ljava/lang/Throwable;)V
 57: return
 Exception table:
 from to target type
 0 30 33 Class java/lang/Throwable


}

Without going through the language spec I can't say why this should have failed to compile, but the best solution would seem to be a patch to the jboss-system.jar that made the call to the unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, java.lang.Object) variation explicit. This way either jbossxb version could be used. Until I see why the conf/login-config.xml is failing to parse I don't know if that is a sufficient path. Most likely a patch to the jbossx.jar will also be required.

[heiko.braun]

but the best solution would seem to be a patch to the jboss-system.jar that made the call to the unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, java.lang.Object) variation explicit.

I agree, it probably makes most sense to replace these calls.
But if we chose this way i'd say we reinstate the DocumentBinding for the next XB release and stick to it until the next AS will be released.

The problem on the WS side is, that we can't communicate differrent XB versions for different environments. And since we offer drop in replacements for the most current AS (different release cycles), we need XB to align to this strategy.

I understand that the refactoring needs to be done. But what difference does it make to postpone it until the next AS release?

[starksm64]

Any significant refactoring should be a 2.0 release of jbossxb so just restoring the unmarshal(java.lang.String, org.jboss.xb.binding.ObjectModelFactory, org.jboss.xb.binding.metadata.unmarshalling.DocumentBinding) would simplify the current problem. The login-config.xml parsing problem is the same NSME error so restoring this to avoid having to patch two jbossas jar files is a better solution.

[aloubyansky]

There wasn't 1.0 release yet. I was going to work on the refactoring (once again) after the next CR. So, if all significant refactoring should be in 2.0 then I am going to start releasing with 2.0 (which is ok by me). But I won't release current API and impl.

WS releases will distribute XB binaries anyway. So, they as well could use the XB binary for 4.0.4.GA that would work in any JBoss version.

[heiko.braun]

We regard JBossWS+JBossXB as one distribution package. That means we are going communicate WS1.0.2 together with XBCR6. Poeple know how to upgrade XB when a new WS version is released and they expect it to run against the most current AS release, Branch_4_0 and jboss-head.

What i am trying to avoid is having to tell them they should use different XB releases for these scenarios. A WS release may work in these environments or it may not. But it's all or nothing. And 'All' includes a particular XB release.

If the next XB release can fullfill these requirements, then it's fine. But if you stick to the branch we need to backport all relevant changes.
So, if XB 1.0 GA is not going to be released before the next AS, what's the benefit of maintaining a speparate XB codebase for the most current AS?

However, it's your decision. But if you stick to your approach, please make sure the next XB release labels the AS sources as well, so we may easiliy recreate that release in order to port fixes to it.

[aloubyansky]

The API has been reinstated. http://jira.jboss.com/jira/browse/JBXB-74

[seeteshhindlekar]

BUILD FAILED
java.lang.NoSuchMethodError: org.jboss.xb.binding.Unmarshaller.setSchemaValidation(Z)V.....

Rgds,

Seetesh

[seeteshhindlekar]

"seeteshhindlekar" wrote:
BUILD FAILED
java.lang.NoSuchMethodError: org.jboss.xb.binding.Unmarshaller.setSchemaValidation(Z)V.....

I am using JBoss 4.0.4 RC1

Rgds,

Seetesh

[heiko.braun]

What XB version is causing this error?

--
Heiko