-
1. Re: JBoss-4.0.4.GA and XB-1.0.0.CR5+
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. -
2. Re: JBoss-4.0.4.GA and XB-1.0.0.CR5+
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? -
3. Re: JBoss-4.0.4.GA and XB-1.0.0.CR5+
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.
-
4. Re: JBoss-4.0.4.GA and XB-1.0.0.CR5+
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. -
5. Re: JBoss-4.0.4.GA and XB-1.0.0.CR5+
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. -
6. Re: JBoss-4.0.4.GA and XB-1.0.0.CR5+
The API has been reinstated. http://jira.jboss.com/jira/browse/JBXB-74
-
7. Re: JBoss-4.0.4.GA and XB-1.0.0.CR5+
BUILD FAILED
java.lang.NoSuchMethodError: org.jboss.xb.binding.Unmarshaller.setSchemaValidation(Z)V.....
Rgds,
Seetesh -
8. Re: JBoss-4.0.4.GA and XB-1.0.0.CR5+
"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 -