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

[Design of JBoss Web Services] - Re: Signatures and CRs

by richard.opalka＠jboss.com

"alessio.soldano(a)jboss.com" wrote : | Sorry, may be I'm missing something, why this should have nothing to do with our issue? The spec says: "To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character." We have a #xD not followed by #xA that is converted to #xA... I was wrong, you are true View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131941#4131941 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131941

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Signatures and CRs

by alessio.soldano＠jboss.com

"richard.opalka(a)jboss.com" wrote : "alessio.soldano(a)jboss.com" wrote : | | Fortunately this issue only happens when the message is not encrypted. Signature+encryption prevents this since the xml parser works with the encrypted element data. | If we're not able to fix the problem we could suggest our users to use base64 encoding of such strings before putting them to the message payload (the workaround) Yep, this is a workaround too, you're right. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131937#4131937 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131937

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Signatures and CRs

by alessio.soldano＠jboss.com

"richard.opalka(a)jboss.com" wrote : "alessio.soldano(a)jboss.com" wrote : As you can read here http://www.w3.org/TR/REC-xml/#sec-line-ends CRs must be converted in line feeds when parsing. Xerces does this of course, thus the message bytes change and signature (which is obtained using the message containing the CR) is not valid anymore when processing the request message at server side. | | | | From my understanding this have nothing to do with our problem. The above specification says what to do with new-lines only. Our use-case is different. We have element containing | sequence of characters enclosing 0xD character: | Sorry, may be I'm missing something, why this should have nothing to do with our issue? The spec says: "To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character." We have a #xD not followed by #xA that is converted to #xA... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131935#4131935 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131935

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Signatures and CRs

by alessio.soldano＠jboss.com

"richard.opalka(a)jboss.com" wrote : I'm not 100 % sure but IMHO such enclosed 0xD character won't be converted to new line by the parser. Try this: | public void testParser() throws Exception | { | String s = "<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Body><a>He\rllo</a></env:Body></env:Envelope>"; | Logger.getLogger(this.getClass()).info("before: "+s); | ByteArrayInputStream bis = new ByteArrayInputStream(s.getBytes()); | Element el = DOMUtils.parse(bis); | Element body = DOMUtils.getChildElements(el).next(); | Element a = DOMUtils.getChildElements(body).next(); | Logger.getLogger(this.getClass()).info(a.getTextContent()); | Logger.getLogger(this.getClass()).info(a.getChildNodes().item(0)); | String res = DOMWriter.printNode(el, false); | Logger.getLogger(this.getClass()).info("after: "+res); | assertEquals(s, res); | } | The \r is converted into in a new line (and the logs show the text node already contains the new line, thus it's created while parsing). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131934#4131934 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131934

18 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: Facade Questions

by johnbailey

I was looking at that as well. That seems a cleaner fit knowing the mappings you posted. I will use this moving forward. On another note, if we are going to support using the facade for any deployment even ones not originating in a OSGI Bundle, we can not assume the OSGIMetaData will be attached to the DeploymentContext. In this case, we will need to create the headers given the other MetaData available, correct? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131928#4131928 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131928

18 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: Facade Questions

by alesj

When mapping Controller states to bundle states, you should consider DeploymentStages, since those are probably the one's we're after. Those mentioned before are POJO centric. I would do something like this: ERROR --> UNINSTALLED NOT_INSTALLED --> INSTALLED (this one looks funny, but it's technically ok :-) CLASSLOADING --> RESOLVED REAL --> STARTING / STOPPING INSTALLED --> ACTIVE View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131924#4131924 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131924

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: JBoss MC usage in various modules

by thomas.heute＠jboss.com

An easy workaround is to define the version to use in the JBoss-Portal-Parent pom So that it is used by common-mc and the others. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131922#4131922 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131922

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: JBoss MC usage in various modules

by chris.laprun＠jboss.com

It would be great if we could do that (and other common dependencies) so that we don't have to redefine them everywhere :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131920#4131920 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131920

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Timeboxed development schedule

by jeffdelong

I would like to get the updates for the rule service into this next release. I have implemented most of what is required in my workspace, but will need to merge it into the latest version at the appropriate time. Also need to target the appropriate release of Drools. I think this should be 4.0.5 (I don't think 5.0 will be ready), but would need to check on anticipated release dates for this version. Would also be nice if it Drools 4.0.5 got independently QA'd before incorporation into the platform. Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131913#4131913 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131913

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Signatures and CRs

by richard.opalka＠jboss.com

"alessio.soldano(a)jboss.com" wrote : | Fortunately this issue only happens when the message is not encrypted. Signature+encryption prevents this since the xml parser works with the encrypted element data. If we're not able to fix the problem we could suggest our users to use base64 encoding of such strings before putting them to the message payload (the workaround) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131910#4131910 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131910

18 years, 1 month

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 February 2008