October 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Allowing multiple AbstractParsingDeployer to work with t

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | Actually, this is not OK, because it breaks the idea | that somebody can pass in an override WebMetaData | in the predetermined objects and the deployers won't parse | the web.xml from the deployment. The current AbstractParsingDeployer does not make the distinction as to whether the current deployment type attachment is a predetermined object, so I don't know whether this situation exists. This can be added to prevent uneeded parsing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976297#3976297 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976297

19 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Allowing multiple AbstractParsingDeployer to work with t

by adrian＠jboss.org

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92129 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976291#3976291 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976291

19 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - Re: GpListener reload config - new instance of listeners?

by jokum

What I meant is when the bus is started. The fact of reconfiguring a running bus is a different story. I think when reconfiguring the listeners we should check if the config for a certain listener has changed. If so stop the old and start a new listener instance...? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976290#3976290 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976290

19 years, 3 months

1
0
0 / 0

[Design of JBossXB] - Changes to the unmarshaller interface.

by adrian＠jboss.org

I want to make some changes to the unmarshaller interface. 1) There should be methods based on InputSource. This actually makes most of the other methods redundant. This is needed because I want to attach a system id for error reporting. I can't use the real url because in some cases (e.g. jars that get unpacked) this will be meaningless to users. 2) Need to be able pass in a root object for the schema parsing. Like you can with the ObjectModelFactory methods. This is needed so you can augment/merge the model when it comes from mutliple files/schemas, e.g. ejb-jar.xml and jboss.xml View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976289#3976289 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976289

19 years, 3 months

1
0
0 / 0

[Design of JBossXB] - Sundry JBossXB changes

by adrian＠jboss.org

I've made a couple of fixes/changes to JBossXB. 1) The SchemaBinding now exposes the namespaces in the document 2) I've improved some error messages. This needs a review. JBossXB is eating lots errors making the real meaning of the problem unknown. e.g. | try | { | return getter.get(owner); | } | catch(Exception e) | { | throw new JBossXBRuntimeException( | "Failed to get value of the property '" + name + "' defined in " + owner + " from instance " + owner | ); | } | That's not very interesting, I want to know why it failed. | throw new JBossXBRuntimeException( | "Failed to get value of the property '" + name + "' defined in " + owner + " from instance " + owner, e) | ); | 3) I made the content handler throw an Exception if it can't find the schema binding. Previously it pushing null onto stack which caused an NPE during endElement. I also added checks to the Stack to trap early when null is pushed onto the stack. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976288#3976288 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976288

19 years, 3 months

1
0
0 / 0

[Design of JBossXB] - Using annotations to define schema mappings

by adrian＠jboss.org

Since: 1) obviously we can't define schema annotations on the javaee schemas 2) writing handlers (objectmodelfactory, schemabindinginitialzer) by hand is laborious and error prone 3) none of this information on the mapping is exposed to tools I've created an alternate way of mapping schemas to object models. This involves the use of annotations. In fact, it goes a bit beyond that. In many cases, the annotations are not required since it will make a "good guess" at the mapping using conventions and looking at the object model's class tree. Here's an example showing what I've got working so far which caters for about 80-90% of use cases: | /* | * JBoss, Home of Professional Open Source | * Copyright 2006, JBoss Inc., and individual contributors as indicated | * by the @authors tag. See the copyright.txt in the distribution for a | * full listing of individual contributors. | * | * This is free software; you can redistribute it and/or modify it | * under the terms of the GNU Lesser General Public License as | * published by the Free Software Foundation; either version 2.1 of | * the License, or (at your option) any later version. | * | * This software is distributed in the hope that it will be useful, | * but WITHOUT ANY WARRANTY; without even the implied warranty of | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | * Lesser General Public License for more details. | * | * You should have received a copy of the GNU Lesser General Public | * License along with this software; if not, write to the Free | * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA | * 02110-1301 USA, or see the FSF site: http://www.fsf.org. | */ | package org.jboss.test.xml.builder.support; | | import java.util.Collection; | | import org.jboss.xb.binding.annotations.Schema; | import org.jboss.xb.binding.annotations.SchemaAttribute; | import org.jboss.xb.binding.annotations.SchemaProperty; | import org.jboss.xb.binding.annotations.SchemaType; | import org.jboss.xb.binding.annotations.SchemaValue; | | /** | * Example. | | Example of using annotations to map the schema | JBossXBBuilder.build(schemaBinding, Example.class); | | This will look at Example.class and the classes | it references, e.g. AnotherExample.class | | It will also look at parameterized classes, | e.g. if there was a property of type | Collection<AnotherExample> | it will also look at AnotherExample. | | * @author <a href="adrian(a)jboss.com">Adrian Brock</a> | * @version $Revision: 1.1 $ | */ | | // This is only processed on the root type | // passed to the builder | @Schema(ignoreUnresolvedFieldOrClass=true) | | // The xsd name | // <xsd:complex-type name="theTypeNameInTheXSD"/> | @SchemaType(name="theTypeNameInTheXSD") | | // Alternatively an element and can take an namespace | // No namespace means it will search for the name | // in any namespace in the schema | // @SchemaElement(name="foo", namespace="urn:jboss.com:bar") | | // The type/example is optional | // currently it will search for an element or type | // with name "example". (lowercase first letter) | public class Example | { | private String someAttribute; | | private Collection<String> someCollection; | | private AnotherExample someProperty; | | private String someValue; | | public String getSomeAttribute() | { | return someAttribute; | } | | // maps the xml attribute name <x id="blah"/> | @SchemaAttribute(name="id") | public void setSomeAttribute(String someAttribute) | { | this.someAttribute = someAttribute; | } | | public Collection<String> getSomeCollection() | { | return someCollection; | } | | // maps the xml child name for a collection | // <parent> | // <child/> | // <child/> | // </parent> | @SchemaProperty(name="child") | public void setSomeCollection(Collection<String> someCollection) | { | this.someCollection = someCollection; | } | | public AnotherExample getSomeProperty() | { | return someProperty; | } | | // maps the xml child name for a non-collection | // <parent> | // <child/> | // </parent> | @SchemaProperty(name="child") | public void setSomeProperty(AnotherExample someProperty) | { | this.someProperty = someProperty; | } | | public String getSomeValue() | { | return someValue; | } | | // A tag to say this takes the character data | // <x>this</x> | @SchemaValue | public void setSomeValue(String someValue) | { | this.someValue = someValue; | } | } | This work is currently uncommitted to SVN. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976284#3976284 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976284

19 years, 3 months

1
0
0 / 0

[Design of JBossXB] - Re: DefaultSchemaResolver logic is wrong

by adrian＠jboss.org

NOTE: The way the EJB3 tests work around this issue looks broken to me? Certainly the solution used there, will lead to ejb-jar.xmls that are unlikely to work in other servers, i.e. it is non-portable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976282#3976282 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976282

19 years, 3 months

1
0
0 / 0

[Design of JBossXB] - DefaultSchemaResolver logic is wrong

by adrian＠jboss.org

As per the previous thread earlier this year, it is not possible to compose schemas using imports with JBossXB. I've fixed this, with the new implemetation, I can now get an XSModel for the JavaEE schemas (which previously failed due to confusion of imports). The new implementation looks like this: | | private InputSource getInputSource(String nsURI, String baseURI, String schemaLocation) | { | boolean trace = log.isTraceEnabled(); | InputSource is = null; | | if( trace ) | log.trace("getInputSource, nsURI="+nsURI+", baseURI="+baseURI+", schemaLocation="+schemaLocation); | | // First try what is requested | try | { | is = resolver.resolveEntity(nsURI, schemaLocation); | if (trace) | log.trace("Resolved schema using namespace as publicId and schemaLocation as systemId"); | } | catch (Exception e) | { | if (trace) | log.trace("Failed to use nsUri/schemaLocation", e); | } | | // Next, try to use the baseURI to resolve the schema location | if (is == null && baseURI != null && schemaLocation != null) | { | try | { | URL url = new URL(baseURI); | url = new URL(url, schemaLocation); | String resolvedSchemaLocation = url.toString(); | // No point if the schema location was already absolute | if (schemaLocation.equals(resolvedSchemaLocation) == false) | { | is = resolver.resolveEntity(null, url.toString()); | if( trace && is != null ) | log.trace("Resolved schema location using baseURI"); | } | } | catch (Exception e) | { | if (trace) | log.trace("Failed to use schema location with baseURI", e); | } | } | | // Finally, just try the namespace as the system id | if (is == null && nsURI != null) | { | try | { | is = resolver.resolveEntity(null, nsURI); | if( trace && is != null ) | log.trace("Resolved namespace as system id"); | } | catch (Exception e) | { | if (trace) | log.trace("Failed to use namespace as system id", e); | } | } | if( trace ) | { | log.trace("getInputSource, nsURI="+nsURI+", baseURI=" | +baseURI+", schemaLocation="+schemaLocation+", is="+is); | } | return is; | } | Previously, the last step was first, making it impossible to compose a namespaces from different schema files. Also, it didn't use the schemaLocation properly so it always failed for simple imports like: | <xsd:include schemaLocation="javaee_web_services_client_1_2.xsd"/> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976281#3976281 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976281

19 years, 3 months

1
0
0 / 0

[Design of JBossXB] - JBossEntityResolver and predefined locations

by adrian＠jboss.org

The JBossEntityResolver only looks in the classpath for predetermined filenames. I've added some code that treats the file as a system id, i.e. a URI when it is not found in the classpath. | InputStream ins = loadClasspathResource(filename, trace); | if( ins != null ) | { | inputSource = new InputSource(ins); | inputSource.setPublicId(publicId); | } | else | { | - log.warn("Cannot load publicId from resource: " + filename); | + log.trace("Cannot load publicId from classpath resource: " + filename); | | + // Try the file name as a URI | + inputSource = resolveSystemIDasURL(filename, trace); | | + if (inputSource == null) | + log.warn("Cannot load publicId from resource: " + filename); | } | This is useful for testing where I can easily determine the URL using classloader.getResource() but it more difficult to determine the classpath location. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976280#3976280 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976280

19 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Allowing multiple AbstractParsingDeployer to work with t

by adrian＠jboss.org

Babel fish: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976276#3976276 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976277#3976277 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976277

19 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2006