Dependency on XB DefaultSchemaResolver

[aloubyansky]

I found JBossXBDeployerHelper assumes DefaultSchemaResolver

private static DefaultSchemaResolver resolver = (DefaultSchemaResolver)SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver();

This became a problem with XB 2.0.1.Beta2 where I changed the default schema resolver to MultiClassSchemaResolver (which does not extend DefaultSchemaResolver).

The difference between the two resolvers is that MultiClassSchemaResolver allows to map more than one class to a namespace (useful for our JCA metadata, for example). The reason I didn't want to implement this in DefaultSchemaResolver is that its removeClassBinding(ns) method returns a single class (in MultiClassSchemaResolver it returns an array).

Maybe, we can agree on an interface like SchemaResolverWithURIToClassMapping? Or other suggestions?

[adrian.brock]

Maybe, we can agree on an interface like SchemaResolverWithURIToClassMapping? Or other suggestions?

What about MutableSchemaResolver as a name?

Anyway, the JBossXBDeployerHelper looks like it should be maintained in JBossXB anyway?

I guess the main reason why it is not, is because its providing some "VFS integration".
Maybe this could be more simply done by having a VFSInputSource?

[aloubyansky]

What about MutableSchemaResolver as a name?

No problem.

Anyway, the JBossXBDeployerHelper looks like it should be maintained in JBossXB anyway?

I don't mind maintaining a helper class. Of course, deployer-specific bits should still be in the deployers project. If you or Ales want to refactor JBossXBDeployerHelper and extract a helper for the XB, I'll maintain it.

I guess the main reason why it is not, is because its providing some "VFS integration".
Maybe this could be more simply done by having a VFSInputSource?

That's an idea. Which project would it be in? Common? XB does not depend on VFS.

[adrian.brock]

That's an idea. Which project would it be in? Common? XB does not depend on VFS.

It would go in the VFS project. JAXP is part of the JDK so there's no problem
with VFS maintaining its own Input/OutputSource.

They'd probably just delegate to the Stream versions like the helper does.

I'm just wondering whether all the signatures are available in the Unmarshaller interface?

[aloubyansky]

Yes, Unmarshaller can take String, InputStream, Reader and InputSource.
http://anonsvn.jboss.org/repos/common/jbossxb/trunk/src/main/java/org/jboss/xb/binding/Unmarshaller.java

[alesj]

I'll move/refactor the JBossXBDeployerHelper to XB today.
And create a proper VFSInputSource in VFS.

[aloubyansky]

Ok, thanks.
There also are some helper classes/methods regarding resolvers: SchemaResolverConfig and SingletonSchemaResolverFactory.
Maybe there will be something useful for you.

I've committed MutableSchemaResolver to XB trunk. Issue https://jira.jboss.org/jira/browse/JBXB-190

In the interface for mapping methods instead of "add" prefix I used "map", since in case of one-to-many mapping (e.g. uri-to-classes) "add" seems to be more ambiguous for methods that override previous mapping instead of actually adding.

[aloubyansky]

PS: if you want to run testsuites (of your projects, not xb) with latest XB then probably you should set system property xb.builder.useUnorderedSequence to true or invoke JBossXBBuilder.setUseUnorderedSequence(true) to not enforce element ordering in sequences.
But actually, if there are xml/binding validation issues they should be resolved, there have to be a good reason to use unordered sequences. Please, post on xb forum any issues you find.

[alesj]

This is now done under JBXB-191.

Is there anything else to VFSInputSource than this:

public class VFSInputSource extends InputSource
{
 private VirtualFile file;

 public VFSInputSource(VirtualFile file)
 {
 if (file == null)
 throw new IllegalArgumentException("Null file");

 this.file = file;
 }

 @Override
 public String getSystemId()
 {
 try
 {
 return file.toURI().toString();
 }
 catch (Exception e)
 {
 throw new RuntimeException(e);
 }
 }

 @Override
 public InputStream getByteStream()
 {
 try
 {
 return file.openStream();
 }
 catch (IOException e)
 {
 throw new RuntimeException(e);
 }
 }

 @Override
 public Reader getCharacterStream()
 {
 return new InputStreamReader(getByteStream());
 }
}

[alesj]

I've also updated the Deployers,
to use this JBXB-191 and JBVFS-99.

[aloubyansky]

Thanks. I've added my 2 cents though in the form of renaming JBossXBDeployerHelper to JBossXBHelper and moving it to org.jboss.xb.util. I've rebuilt XB snapshot, uploaded it to the snapshot repositories and also updated deployers under JBDEPLOY-173.