Re: [jira] [PROPOSAL] Coding standards
OK for me. Can anyone provide an Eclipse code formatting setup? Kind regards Juergen gnodet wrote: > > I propose the following coding standards (taken from the Geronimo web > site) > which are actually the most common in ServiceMix code base: > > http://cwiki.apache.org/SM/coding-standards.html > > Does anyone want to modify / add / change something ? > > -- > Cheers, > Guillaume Nodet > > Architect, LogicBlaze (http://www.logicblaze.com/) > Blog: http://gnodet.blogspot.com/ > > -- View this message in context: http://www.nabble.com/-PROPOSAL--Coding-standards-tf3233686s12049.html#a8987468 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [jira] Correct way to get inputstream from message content
Please opensource it! Kind regards Juergen gnodet wrote: > > You can not (and should not) assume a specific kind of Source > containing the xml. It may be based on a stream, dom, stax, > sax, string, etc ... > You can use the SourceTransformer (o.a.s.jbi.jaxp package) > which has a toStreamSource method that you could use. > > Btw, are you considering opensourcing it ? > > On 2/28/07, bradtwurst <[EMAIL PROTECTED]> wrote: >> >> Hello all, >> >> What is the correct way to get a inputStream from a normalized message >> content. >> >> I'm in the process of creating a SE that utilizes servingXml and, for >> some >> reason, I just can't connect these dots. >> >> Thanks, >> James >> -- >> View this message in context: >> http://www.nabble.com/Correct-way-to-get-inputstream-from-message-content-tf3321687s12049.html#a9234878 >> Sent from the ServiceMix - Dev mailing list archive at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > Architect, LogicBlaze (http://www.logicblaze.com/) > Blog: http://gnodet.blogspot.com/ > > -- View this message in context: http://www.nabble.com/Correct-way-to-get-inputstream-from-message-content-tf3321687s12049.html#a9245265 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [Fwd: What do people think about graduation ?]
Very good idea!!! Regards Juergen Alan D. Cabrera-2 wrote: > > > On Mar 14, 2007, at 11:51 AM, Guillaume Nodet wrote: > >> It may be time to consider it. >> The community is growing and diverse ... >> I don't see any issues left. > > Seems like a good idea to me. > > Do you guys think we should be a TLP? > > > Regards, > Alan > > > -- View this message in context: http://www.nabble.com/-Fwd%3A-What-do-people-think-about-graduationtf3404120s12049.html#a9510113 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Created: (SM-414) SourceTransformer cant transf orm to DOM with non US ASCI I characters like 'ä' or 'ü'
SourceTransformer cant transform to DOM with non US ASCII characters like 'ä'
or 'ü'
Key: SM-414
URL: https://issues.apache.org/activemq/browse/SM-414
Project: ServiceMix
Type: Bug
Components: servicemix-core
Versions: 3.0-M1, 3.0-M2, 3.0, incubation
Environment: W2K, J2SE 1.4.2, Xerces 2.7.1, default locale of OS with
character set 'windows-1252'
Reporter: Juergen Mayrbaeurl
Priority: Blocker
Fix For: 3.0, incubation
Attachments: SourceTransformer-sources.zip
The class org.apache.servicemix.jbi.jaxp.SourceTransformer, which belongs to
the core classes of ServiceMix and is used very often, has major problems
transforming Source to DOM data structures, when the source contains non
US-ASCII charactes like 'ä' or 'ü'.
The class uses DocumentBuilders (see method 'public DOMSource
toDOMSourceFromStream(StreamSource source) throws ParserConfigurationException,
IOException, SAXException') for the transformation and uses the method 'public
Document parse(InputStream is, String systemId) throws SAXException,
IOException' without explicitly telling the DocumentBuilder the character
encoding it should use. This results in fatal errors (exceptions) returned by
the DocumentBuilder (Xerces 2.7.1), because it encounters invalid character
code sequences (especially with UTF-8 and multi-byte characters like 'ä' or
'ö'). This means that you can't use non US-ASCII characters in messages, as
soon as ServiceMix uses an instance of the class SourceTransformer to do any
transformation to DOM. This is the case when tracing messages in the
DeliveryChannel or evaluating an XPath expression for e.g. Content based
routing.
The solution to this problem is straight forward: Tell the DocumentBuilder the
character encoding it has to use. Looks like:
public DOMSource toDOMSourceFromStream(StreamSource source) throws
ParserConfigurationException, IOException,
SAXException {
DocumentBuilder builder = createDocumentBuilder();
String systemId = source.getSystemId();
Document document = null;
InputStream inputStream = source.getInputStream();
if (inputStream != null) {
InputSource inputsource = new InputSource(inputStream);
inputsource.setSystemId(systemId);
inputsource.setEncoding(defaultCharEncodingName); // <-- Very
important
document = builder.parse(inputsource);
}
else {
Reader reader = source.getReader();
if (reader != null) {
document = builder.parse(new InputSource(reader));
}
else {
throw new IOException("No input stream or reader available");
}
}
return new DOMSource(document, systemId);
}
I've attached the original source file of SourceTransformer (3.0 SNAPSHOT,
2006-04-20) and the changed (Unfortunately I can't create a real patch).
Kind regards
Juergen
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (SM-414) SourceTransformer cant transf orm to DOM with non US ASCI I characters like 'ä' or 'ü'
[ https://issues.apache.org/activemq/browse/SM-414?page=all ]
Juergen Mayrbaeurl updated SM-414:
--
Attachment: SampleInMessage.xml
Sample In Message with non US-ASCII characters
> SourceTransformer cant transform to DOM with non US ASCII characters like 'ä'
> or 'ü'
>
>
> Key: SM-414
> URL: https://issues.apache.org/activemq/browse/SM-414
> Project: ServiceMix
> Type: Bug
> Components: servicemix-core
> Versions: 3.0-M1, 3.0-M2, 3.0, incubation
> Environment: W2K, J2SE 1.4.2, Xerces 2.7.1, default locale of OS with
> character set 'windows-1252'
> Reporter: Juergen Mayrbaeurl
> Priority: Blocker
> Fix For: 3.0, incubation
> Attachments: SampleInMessage.xml, SourceTransformer-sources.zip
>
>
> The class org.apache.servicemix.jbi.jaxp.SourceTransformer, which belongs to
> the core classes of ServiceMix and is used very often, has major problems
> transforming Source to DOM data structures, when the source contains non
> US-ASCII charactes like 'ä' or 'ü'.
> The class uses DocumentBuilders (see method 'public DOMSource
> toDOMSourceFromStream(StreamSource source) throws
> ParserConfigurationException, IOException, SAXException') for the
> transformation and uses the method 'public Document parse(InputStream is,
> String systemId) throws SAXException, IOException' without explicitly telling
> the DocumentBuilder the character encoding it should use. This results in
> fatal errors (exceptions) returned by the DocumentBuilder (Xerces 2.7.1),
> because it encounters invalid character code sequences (especially with UTF-8
> and multi-byte characters like 'ä' or 'ö'). This means that you can't use non
> US-ASCII characters in messages, as soon as ServiceMix uses an instance of
> the class SourceTransformer to do any transformation to DOM. This is the case
> when tracing messages in the DeliveryChannel or evaluating an XPath
> expression for e.g. Content based routing.
> The solution to this problem is straight forward: Tell the DocumentBuilder
> the character encoding it has to use. Looks like:
> public DOMSource toDOMSourceFromStream(StreamSource source) throws
> ParserConfigurationException, IOException,
> SAXException {
> DocumentBuilder builder = createDocumentBuilder();
> String systemId = source.getSystemId();
> Document document = null;
> InputStream inputStream = source.getInputStream();
> if (inputStream != null) {
> InputSource inputsource = new InputSource(inputStream);
> inputsource.setSystemId(systemId);
> inputsource.setEncoding(defaultCharEncodingName); // <-- Very
> important
>
> document = builder.parse(inputsource);
> }
> else {
> Reader reader = source.getReader();
> if (reader != null) {
> document = builder.parse(new InputSource(reader));
> }
> else {
> throw new IOException("No input stream or reader available");
> }
> }
> return new DOMSource(document, systemId);
> }
> I've attached the original source file of SourceTransformer (3.0 SNAPSHOT,
> 2006-04-20) and the changed (Unfortunately I can't create a real patch).
> Kind regards
> Juergen
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (SM-834) Provide File Marshalling for CSV/variable, fixed and heirarchial messages
[ https://issues.apache.org/activemq/browse/SM-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38525 ] Juergen Mayrbaeurl commented on SM-834: --- Hi Guillaume! I've just build ServiceMix 3.2 and will now add my contribution. BTW the build didn't work, because XFire 1.2.2 uses a non existing repository location for its parent pom (see xfire-all-1.2.2.pom: repository entry 'java.net public repo' on 'https://maven-repository.dev.java.net/nonav/repository' has no group for org.codehaus.xfire). Simply commenting out the complete block solves the problem. Maybe ServiceMix 3.2 should use XFire 1.2.3+. Do you have coding conventions for ServiceMix? Eclipse settings for code formatting? I'll provide some simple test cases. > Provide File Marshalling for CSV/variable, fixed and heirarchial messages > - > > Key: SM-834 > URL: https://issues.apache.org/activemq/browse/SM-834 > Project: ServiceMix > Issue Type: New Feature > Components: servicemix-components >Affects Versions: 3.1 >Reporter: Juergen Mayrbaeurl > Fix For: 3.2 > > Attachments: FileExtensionPropertyExpression.java, > SimpleFlatFileMarshaler.java, zpv-contrib-servicemix-file.zip > > > Provide file marshalling for file binding components similar to Parser > Service Engine from Bostech ChainBuilder ESB > (http://chainforge.net/chainbuilder/index.html) > Sources as starting point attached. They show how to get CSV or fixed-length > flat files on the bus in a generic way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-834) Provide File Marshalling for CSV/variable, fixed and heirarchial messages
[ https://issues.apache.org/activemq/browse/SM-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juergen Mayrbaeurl updated SM-834: -- Attachment: servicemix-core.diff Patch for servicemix-core artifact containing contributed sources > Provide File Marshalling for CSV/variable, fixed and heirarchial messages > - > > Key: SM-834 > URL: https://issues.apache.org/activemq/browse/SM-834 > Project: ServiceMix > Issue Type: New Feature > Components: servicemix-components >Affects Versions: 3.1 > Reporter: Juergen Mayrbaeurl > Fix For: 3.2 > > Attachments: FileExtensionPropertyExpression.java, > servicemix-core.diff, SimpleFlatFileMarshaler.java, > zpv-contrib-servicemix-file.zip > > > Provide file marshalling for file binding components similar to Parser > Service Engine from Bostech ChainBuilder ESB > (http://chainforge.net/chainbuilder/index.html) > Sources as starting point attached. They show how to get CSV or fixed-length > flat files on the bus in a generic way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-844) Using Shared Libraries from LW SUs
[ https://issues.apache.org/activemq/browse/SM-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38528 ] Juergen Mayrbaeurl commented on SM-844: --- Where in the source code is the SU class loading? > Using Shared Libraries from LW SUs > -- > > Key: SM-844 > URL: https://issues.apache.org/activemq/browse/SM-844 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-lwcontainer >Affects Versions: 3.1 > Environment: ServiceMix LW Container > Reporter: Juergen Mayrbaeurl > Fix For: 3.2 > > > With ServiceMix 3.1 it isn't possible to use shared libraries in LW service > units, because classloading (and configuration) and referencing shared > libraries isn't supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-847) Old version of xml-apis in distribution
Old version of xml-apis in distribution --- Key: SM-847 URL: https://issues.apache.org/activemq/browse/SM-847 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.2 In the ServiceMix 3.1 distribution (lib folder) a very old version (1.0b2) of xml-apis is included. Replace it with version 1.3.03 or higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-848) ServiceMix 3.x with Java 1.4.x
ServiceMix 3.x with Java 1.4.x -- Key: SM-848 URL: https://issues.apache.org/activemq/browse/SM-848 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.1 Environment: Java Runtime Environment 1.4.x Reporter: Juergen Mayrbaeurl Fix For: 3.2 Since ServiceMix 3.1 can only be used with Java 5 or higher, rework it to make it Java 1.4.x compatible -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-855) Non concurrent processing of files in LW FilePoller
Non concurrent processing of files in LW FilePoller --- Key: SM-855 URL: https://issues.apache.org/activemq/browse/SM-855 Project: ServiceMix Issue Type: Improvement Components: servicemix-components Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.1.1, 3.2 Attachments: FilePoller.diff LW FilePoller component always processes files concurrently. Sometimes it's very important that files get processed in a defined sequence, because the contents is depending on previously processed contents. I've extended the LW FilePoller class. It has a 'concurrent' property now (default is true) and properties for sorting the incoming files (Sort by name and last modification date, asc and desc) Maybe this functionality should be included in the LW FTP FilePoller and servicemix-file BC, too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-855) Non concurrent processing of files in LW FilePoller
[ https://issues.apache.org/activemq/browse/SM-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juergen Mayrbaeurl updated SM-855: -- Attachment: FilePoller.diff Forgot to grant license to ASF > Non concurrent processing of files in LW FilePoller > --- > > Key: SM-855 > URL: https://issues.apache.org/activemq/browse/SM-855 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-components >Affects Versions: 3.1 > Reporter: Juergen Mayrbaeurl > Fix For: 3.1.1, 3.2 > > Attachments: FilePoller.diff, FilePoller.diff > > > LW FilePoller component always processes files concurrently. Sometimes it's > very important that files get processed in a defined sequence, because the > contents is depending on previously processed contents. > I've extended the LW FilePoller class. It has a 'concurrent' property now > (default is true) and properties for sorting the incoming files (Sort by name > and last modification date, asc and desc) > Maybe this functionality should be included in the LW FTP FilePoller and > servicemix-file BC, too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-855) Non concurrent processing of files in LW FilePoller
[
https://issues.apache.org/activemq/browse/SM-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38618
]
Juergen Mayrbaeurl commented on SM-855:
---
Remarks:
- I thought I'm not using tabs (sorry wrong Eclipse workspace used)
- You're right. The empty loop is very cpu intensive. Proposal for better
implementation of the non concurrent mode:
if (!workingSet.isEmpty()) {
try {
workingSet.wait();
} catch (InterruptedException e) {
}
}
workingSet.add(aFile);
if (log.isDebugEnabled()) {
log.debug("Scheduling file " + aFile + " for processing");
}
getExecutor().execute(new Runnable() {
public void run() {
try {
processFileAndDelete(aFile);
} finally {
workingSet.remove(aFile);
workingSet.notify();
}
}
});
Unfortunately I don't know how to get an executor with a single thread.
Therefore I can't implement the proposed better way. But I agree that it would
be better to do it with a single thread.
> Non concurrent processing of files in LW FilePoller
> ---
>
> Key: SM-855
> URL: https://issues.apache.org/activemq/browse/SM-855
> Project: ServiceMix
> Issue Type: Improvement
> Components: servicemix-components
>Affects Versions: 3.1
>Reporter: Juergen Mayrbaeurl
> Fix For: 3.1.1, 3.2
>
> Attachments: FilePoller.diff, FilePoller.diff
>
>
> LW FilePoller component always processes files concurrently. Sometimes it's
> very important that files get processed in a defined sequence, because the
> contents is depending on previously processed contents.
> I've extended the LW FilePoller class. It has a 'concurrent' property now
> (default is true) and properties for sorting the incoming files (Sort by name
> and last modification date, asc and desc)
> Maybe this functionality should be included in the LW FTP FilePoller and
> servicemix-file BC, too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-848) ServiceMix 3.x with Java 1.4.x
[ https://issues.apache.org/activemq/browse/SM-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38777 ] Juergen Mayrbaeurl commented on SM-848: --- Haven't tried yet. Do you have a 3.1.1 distribution build? > ServiceMix 3.x with Java 1.4.x > -- > > Key: SM-848 > URL: https://issues.apache.org/activemq/browse/SM-848 > Project: ServiceMix > Issue Type: Improvement >Affects Versions: 3.1 > Environment: Java Runtime Environment 1.4.x > Reporter: Juergen Mayrbaeurl > Fix For: 3.1.1 > > > Since ServiceMix 3.1 can only be used with Java 5 or higher, rework it to > make it Java 1.4.x compatible -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-875) TrueZIP binding component
[ https://issues.apache.org/activemq/browse/SM-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38778 ] Juergen Mayrbaeurl commented on SM-875: --- Unfortunately there's no documentation for the Plexus archiver. Just the sources and some JavaDoc. I agree with Guillaume that a FileMarshaller extension should only add compress/decompress capabilities, but no archive manipulation. So let's create another JIRA for the FileMarshaller. > TrueZIP binding component > - > > Key: SM-875 > URL: https://issues.apache.org/activemq/browse/SM-875 > Project: ServiceMix > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: James Bradt > Attachments: trueZip-smx.zip > > > suggest new binding component using TrueZIP toolset - allows files to be > read/written to compressed archives -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
