This content has been marked as final.
Show 6 replies
-
1. Re: Why SingletonSchemaResolverFactory?
alesj Jan 17, 2007 1:06 AM (in response to starksm64)I used this 'hack' to temp add new Spring schema:
public void setUp() throws Exception { SchemaBindingResolver resolver = SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver(); DefaultSchemaResolver defaultSchemaResolver = (DefaultSchemaResolver) resolver; defaultSchemaResolver.addSchemaInitializer("urn:jboss:spring-beans:2.0", new SpringSchemaInitializer()); defaultSchemaResolver.addSchemaLocation("urn:jboss:spring-beans:2.0", "mc-spring-beans_2_0.xsd"); super.setUp(); }
But I agree with you. -
2. Re: Why SingletonSchemaResolverFactory?
adrian.brock Jan 17, 2007 10:44 AM (in response to starksm64)There is an MBean/POJO that can be deployed to add schemas at runtime.
The singleton is just a mechanism to setup "known ones" automatically.
i.e. factory settings.
There is a post about it somewhere in the JBossXB forum.
If search worked I could find it for you. :-)
e.g.<bean name="Schemas" class="org.jboss.xb.binding.sunday.unmarshalling.SchemaResolverConfig"> <!-- The initializer classes --> <property name="SchemaInitializers"> urn:somenamespace=some.class.name </property> <!-- The locations these are added to JBossEntityResolver --> <property name="SchemaLocations"> urn:somenamespace=schema/some.xsd </property> <!-- Only for performance if your schema is annotated, but only with coments --> <property name="ParseAnnotations"> urn:somenamespace=false </property> </bean>
-
3. Re: Why SingletonSchemaResolverFactory?
adrian.brock Jan 17, 2007 10:46 AM (in response to starksm64)"alesj" wrote:
I used this 'hack' to temp add new Spring schema:public void setUp() throws Exception { SchemaBindingResolver resolver = SingletonSchemaResolverFactory.getInstance().getSchemaBindingResolver(); DefaultSchemaResolver defaultSchemaResolver = (DefaultSchemaResolver) resolver; defaultSchemaResolver.addSchemaInitializer("urn:jboss:spring-beans:2.0", new SpringSchemaInitializer()); defaultSchemaResolver.addSchemaLocation("urn:jboss:spring-beans:2.0", "mc-spring-beans_2_0.xsd"); super.setUp(); }
But I agree with you.
The Spring one (and other known ones) should be added to the singleton.
If the initializer class is not in the classpath, it will ignore it. -
4. Re: Why SingletonSchemaResolverFactory?
alesj Jan 17, 2007 11:05 AM (in response to starksm64)"adrian@jboss.org" wrote:
There is an MBean/POJO that can be deployed to add schemas at runtime.<bean name="Schemas" class="org.jboss.xb.binding.sunday.unmarshalling.SchemaResolverConfig"> ...
And this beans should be installed before any other with new schema usage.
Meaning that the order matters - since those beans cannot depend on this one.
Right? -
5. Re: Why SingletonSchemaResolverFactory?
adrian.brock Jan 17, 2007 11:28 AM (in response to starksm64)Yes, obviously it can't read minds.
Also without the MC (Spring) xsd in the bootstrap/singleton, you couldn't use
MC (Spring) xml to define this POJO either. :-) -
6. Re: Why SingletonSchemaResolverFactory?
adrian.brock Jan 17, 2007 11:33 AM (in response to starksm64)"adrian@jboss.org" wrote:
Yes, obviously it can't read minds.
Also without the MC (Spring) xsd in the bootstrap/singleton, you couldn't use
MC (Spring) xml to define this POJO either. :-)
Well actually you could if you know the system location of the xsd.
But that isn't very nice.
Which is better, having to know the schema that is going to be used and its location<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd" xmlns="urn:jboss:bean-deployer">
or just specifying the namespace?<deployment xmlns="urn:jboss:bean-deployer">