February 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBossXB] - Re: How to force strict validation?

by alex.loubyansky＠jboss.com

W/o changing APIs you could do something like this: final String xsd = | "<xsd:schema" + | " xmlns:jbxb='http://www.jboss.org/xml/ns/jbxb'" + | " xmlns:xsd='http://www.w3.org/2001/XMLSchema'>" + | " <xsd:element name='root' type='root-type'/>" + | " <xsd:complexType name='root-type'>" + | " <xsd:annotation>" + | " <xsd:appinfo>" + | " <jbxb:class impl='" + E.class.getName() + "'/>" + | " </xsd:appinfo>" + | " </xsd:annotation>" + | " <xsd:attribute name='unqualified' type='xsd:string' use='required'/>" + | " </xsd:complexType>" + | "</xsd:schema>"; | | String xml = "<root xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation='testns'/>"; | | org.xml.sax.EntityResolver resolver = new org.xml.sax.EntityResolver() | { | public InputSource resolveEntity(String publicId, String systemId) throws SAXException, IOException | { | if(systemId != null && systemId.endsWith("testns")) | return new org.xml.sax.InputSource(new StringReader(xsd)); | return null; | } | }; | | /* | Validator.assertValidXml(xml, new org.xml.sax.EntityResolver() | { | public InputSource resolveEntity(String publicId, String systemId) throws SAXException, IOException | { | if(systemId != null && systemId.endsWith("testns")) | return new org.xml.sax.InputSource(new StringReader(xsd)); | return null; | } | }); | */ | | SchemaBinding schema = XsdBinder.bind(new StringReader(xsd), null); | Unmarshaller unmarshaller = UnmarshallerFactory.newInstance().newUnmarshaller(); | unmarshaller.setEntityResolver(resolver); | unmarshaller.setSchemaValidation(true); | | Object o = unmarshaller.unmarshal(new StringReader(xml), schema); | assertTrue(o instanceof E); This will throw the exception you expect. The difference is that I had to add noNamespaceSchemaLocation into the xml instead of setting it on the parser. It might still be useful to expose setProperty() or the parser itself though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133243#4133243 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133243

16 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Transaction rollback in action pipeline

by Kevin.Conner＠jboss.com

Hiya Daniel. That would certainly work as a minimum but it would be better if it detected the use of any of our explicit activation properties and threw a ConfigurationException. Kev View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133237#4133237 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133237

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: BeanMetaDataBuilder

by kabir.khan＠jboss.com

If you do | builder.addPropertyMetaData("name", val1); | builder.addPropertyMetaData("name", val2); | You end up with two AbstractPropertyMetaData entries with the same name. For my use case I need to replace it. Should I create new replacePropertyMetaData() methods, or update the existing addPropertyMetaData() methods? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133235#4133235 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133235

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Domain resolve algorithm

by alesj

What's the status of this: - http://jira.jboss.com/jira/browse/JBMICROCONT-182 | protected Object resolve(Controller controller, Module module, Requirement requirement) | { | // TODO JBMICROCONT-182 include parent domains in requirements | // TODO JBMICROCONT-182 check consistency of re-exports | // TODO JBMICROCONT-182 check for self-dependency | // TODO JBMICROCONT-182 test circularity | I'm just asking, since after reading this - http://www.osgi.org/blog/2008/02/research-challenges-for-osgi.html I started thinking about the challenge - http://post-office.corp.redhat.com/mailman/private/jboss-osgi-dev-list/20... in more mathematical fashion, providing some concrete proof for the actual algorithm used, time usage wise. It boils down to graph theory, and finding some known problem to 'map' this usage to it. A quick thought. How does re-wiring stand against the actual ClassLoader usage. e.g. we already have wired bundles, and we want to add a new one. But with the current wiring that is not possible (possibly some 'uses' constraints in the way), but if we re-wire things, we might be able to wire the new bundle as well. I guess that means uninstalling current deployments, and installing them back on after we 'discovered' that there is a wire configuration that makes everyone happy. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133233#4133233 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133233

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Update the relevant .classpath files

by alesj

OK, I definitely don't want to see you loosing too much time doing this stuff :-), but I fail to see how this is relevant. e.g. you get your updated .classpath from svn or you get updated pom from svn, close Eclispe (so you're not pulling the rug), run the maven-ide generator, open Eclipse View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133230#4133230 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133230

16 years, 3 months

1
0
0 / 0

[Design of JBoss Tools (dev)] - Bug in the HTML editor using RIchfaces

by welser

Hi, im developing portlets based Richfaces using JBossTools. ->facing follwoing problem: <a4j:portlet... which must wrap a xxx.xhtml file to get corrently rendered is not displayed in the JBossTools HTML editor...looks like thats a bug In which version will it get fixed? thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133229#4133229 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133229

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: InstallType vs. CallbackType

by adrian＠jboss.org

"alesj" wrote : "alesj" wrote : Why the change/difference in handling installType vs. callbackType? | To be consistent with JAXB? | Since we have separate metadata classes for install callback and uninstall callback, where there is only single install metadata class for the installs/uninstall? No its called "forward compatibility". In the future, we might want to add something that is only for one of them. Why did you create an InstallCallbackMetaData with no additional properties if not for this reason? :-) The JAXB changes just brought the issue into focus. The same is probably true of the install and lifecycle types? I guess I was a bit lazy in just cloning it, there should really be an abstractCallbackType to ease maintenance. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133228#4133228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133228

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Update the relevant .classpath files

by adrian＠jboss.org

"alesj" wrote : | I'm always in favor of not keeping things around that can be generated. | And we're doing that with javacc, so why the change-of-heart here? ;-) Because eclipse is a real pain when you have to regenerate things and (pull the rug out from underneath it). It's incremental compiler gets well confused and trying to make it do a full rebuild doesn't always fix it (it caches stuff it shouldn't - even across reboots). A couple of weeks ago, I ended up doing a full recreate of my MC project because eclipse decided it couldn't find java.lang.Object and I couldn't find a way to fix it. ;-) This issue isn't so bad with the small MC codebase, but with the JBossAS code tree, I can loose literally hours when it decides it isn't going to play nice with an svn update. :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133225#4133225 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133225

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Bold Transitions in Workflow-Designer

by magro1202

Hi Ronald thank you for the quick answer. Yes i want to set the whole line to bold or another color or something. I have very big workflows and every state has three leaving transitions OK, FAIL, WARN that depends on conditions. In case no condition catches the workflow will follow the default transition. and i want to display this default transition in a special way. Your hint changes the label of the transition. i think that would not work because the transition names as stated above must not be changed. Do you have an idea to change the format of the transition line? regards Matthias View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133224#4133224 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133224

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: New Reflection Project

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Moving mc up to a peer of jbossas would require creating a new svn repository, with a need for migration from the jbossas repository. No, I'm just going to move them to jbossas/projects for now. It probably all wants moving to top level projects within labs eventually? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133221#4133221 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133221

16 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2008