[jira] Commented: (LOGGING-124) Commons logging does not work in an osgi environment
[ https://issues.apache.org/jira/browse/LOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623172#action_12623172 ] Christian Schneider commented on LOGGING-124: - I have read some more about the different logging engines. As it seems people agree that commons-logging has many class loading issues. What is the opinion of the people here on the project? Should people switch to slf4j and use the commons-logging compatibility or is it better to solve the classloading issues in commons-logging? > Commons logging does not work in an osgi environment > > > Key: LOGGING-124 > URL: https://issues.apache.org/jira/browse/LOGGING-124 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Christian Schneider >Priority: Critical > > Commons logging should provide Manifest information for using it as an OSGI > bundle. Eventually detection of logging engines and loading of configs should > also be changed to make commons-logging osgi ready. > I have given this problem the critical priority as currently many people are > working on osgi projects and as many open source libs use commons-logging > this is an important thing to solve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOGGING-124) Commons logging does not work in an osgi environment
[ https://issues.apache.org/jira/browse/LOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623171#action_12623171 ] Christian Schneider commented on LOGGING-124: - Ok .. I read the thread on the mailing list. But this will not really help. The last mail says : Please don´t support OSGI as it won´t work with commons-logging anyway. Personally I think this is quite counter productive. We have an urgent problem here. Many Open Source libraries use commons-logging and when they move to osgi the users of these libraries have problems. I do not think the answer can be: let all people switch to pax-logging (or yet another logging framework). I think either commons-logging should make the move to osgi or be discontinued. If things stay as they are people will only move away from commons-logging over time and the problems will continue to exist over a long time. The minimal thing would be to explain in the commons-logging documentation what people have to do to make their apps work. The better thing would be to provide a commons-logging jar that simply works in osgi. I am sure the bootstrapping and detection of frameworks can be changed in a way that is not as problematic as today. > Commons logging does not work in an osgi environment > > > Key: LOGGING-124 > URL: https://issues.apache.org/jira/browse/LOGGING-124 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Christian Schneider >Priority: Critical > > Commons logging should provide Manifest information for using it as an OSGI > bundle. Eventually detection of logging engines and loading of configs should > also be changed to make commons-logging osgi ready. > I have given this problem the critical priority as currently many people are > working on osgi projects and as many open source libs use commons-logging > this is an important thing to solve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOGGING-124) Commons logging does not work in an osgi environment
[ https://issues.apache.org/jira/browse/LOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623160#action_12623160 ] Niall Pemberton commented on LOGGING-124: - See the Note on the Commons OSGi wiki page re commons logging: http://wiki.apache.org/commons/CommonsOsgi > Commons logging does not work in an osgi environment > > > Key: LOGGING-124 > URL: https://issues.apache.org/jira/browse/LOGGING-124 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Christian Schneider >Priority: Critical > > Commons logging should provide Manifest information for using it as an OSGI > bundle. Eventually detection of logging engines and loading of configs should > also be changed to make commons-logging osgi ready. > I have given this problem the critical priority as currently many people are > working on osgi projects and as many open source libs use commons-logging > this is an important thing to solve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LOGGING-124) Commons logging does not work in an osgi environment
Commons logging does not work in an osgi environment Key: LOGGING-124 URL: https://issues.apache.org/jira/browse/LOGGING-124 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.1 Reporter: Christian Schneider Priority: Critical Commons logging should provide Manifest information for using it as an OSGI bundle. Eventually detection of logging engines and loading of configs should also be changed to make commons-logging osgi ready. I have given this problem the critical priority as currently many people are working on osgi projects and as many open source libs use commons-logging this is an important thing to solve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-455) New TimeoutProcessBuilder class
[ https://issues.apache.org/jira/browse/LANG-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623141#action_12623141 ] Jeff Rodriguez commented on LANG-455: - Actually, commons-exec might do exactly what this does. I'll have to check it out. > New TimeoutProcessBuilder class > --- > > Key: LANG-455 > URL: https://issues.apache.org/jira/browse/LANG-455 > Project: Commons Lang > Issue Type: New Feature >Reporter: Jeff Rodriguez >Priority: Minor > Attachments: TimeoutProcessBuilder.java > > Original Estimate: 2h > Remaining Estimate: 2h > > I've a new class I would like to contribute to Commons Lang. It's purpose is > to safely waitFor() processes created with a ProcessBuilder to exit. By > safely I mean a timeout is instituted. > It will need to be updated to use Commons Lang code style and package name > space, as well as have a test case written for it. I'm not sure how that > should work given it's platform specific nature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-178) BOMExclusionInputStream - an InputStream for UTF-8 data that ignores an initial Byte Order mark
[ https://issues.apache.org/jira/browse/IO-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith D Gregory updated IO-178: --- Attachment: BOMExclusionInputStream.patch I guess in retrospect this should have been obvious: add the files before doing a diff. > BOMExclusionInputStream - an InputStream for UTF-8 data that ignores an > initial Byte Order mark > --- > > Key: IO-178 > URL: https://issues.apache.org/jira/browse/IO-178 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Affects Versions: 1.4 >Reporter: Keith D Gregory >Priority: Minor > Attachments: BOMExclusionInputStream.java, > BOMExclusionInputStream.patch, TestBOMExclusionInputStream.java > > > Microsoft tools have the unpleasant habit of writing a byte order mark (the > three-byte sequence 0xEF 0xBB 0xBF) at the start of a UTF-8 encoded file. > The CharsetDecoder supplied with the JDK does not simply discard these bytes, > but instead returns the BOM character (0xFEFF); see > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378911 for discussion on > this. > This makes life unpleasant for anyone who is processing text data, as the > program must look for this character and ignore it. > The BOMExclusionInputStream class is a work-around: it recognizes the BOM at > the start of the stream, and skips over it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-178) BOMExclusionInputStream - an InputStream for UTF-8 data that ignores an initial Byte Order mark
[ https://issues.apache.org/jira/browse/IO-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith D Gregory updated IO-178: --- Attachment: TestBOMExclusionInputStream.java BOMExclusionInputStream.java I apologize for attaching actual files, but I didn't find any way to get Subversion diff to recognize new files (unlike CVS diff, which takes a "N" argument). > BOMExclusionInputStream - an InputStream for UTF-8 data that ignores an > initial Byte Order mark > --- > > Key: IO-178 > URL: https://issues.apache.org/jira/browse/IO-178 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Affects Versions: 1.4 >Reporter: Keith D Gregory >Priority: Minor > Attachments: BOMExclusionInputStream.java, > TestBOMExclusionInputStream.java > > > Microsoft tools have the unpleasant habit of writing a byte order mark (the > three-byte sequence 0xEF 0xBB 0xBF) at the start of a UTF-8 encoded file. > The CharsetDecoder supplied with the JDK does not simply discard these bytes, > but instead returns the BOM character (0xFEFF); see > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378911 for discussion on > this. > This makes life unpleasant for anyone who is processing text data, as the > program must look for this character and ignore it. > The BOMExclusionInputStream class is a work-around: it recognizes the BOM at > the start of the stream, and skips over it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-178) BOMExclusionInputStream - an InputStream for UTF-8 data that ignores an initial Byte Order mark
BOMExclusionInputStream - an InputStream for UTF-8 data that ignores an initial Byte Order mark --- Key: IO-178 URL: https://issues.apache.org/jira/browse/IO-178 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Affects Versions: 1.4 Reporter: Keith D Gregory Priority: Minor Microsoft tools have the unpleasant habit of writing a byte order mark (the three-byte sequence 0xEF 0xBB 0xBF) at the start of a UTF-8 encoded file. The CharsetDecoder supplied with the JDK does not simply discard these bytes, but instead returns the BOM character (0xFEFF); see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378911 for discussion on this. This makes life unpleasant for anyone who is processing text data, as the program must look for this character and ignore it. The BOMExclusionInputStream class is a work-around: it recognizes the BOM at the start of the stream, and skips over it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-455) New TimeoutProcessBuilder class
[ https://issues.apache.org/jira/browse/LANG-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623115#action_12623115 ] James Carman commented on LANG-455: --- Would this be better suited for the commons-exec project? > New TimeoutProcessBuilder class > --- > > Key: LANG-455 > URL: https://issues.apache.org/jira/browse/LANG-455 > Project: Commons Lang > Issue Type: New Feature >Reporter: Jeff Rodriguez >Priority: Minor > Attachments: TimeoutProcessBuilder.java > > Original Estimate: 2h > Remaining Estimate: 2h > > I've a new class I would like to contribute to Commons Lang. It's purpose is > to safely waitFor() processes created with a ProcessBuilder to exit. By > safely I mean a timeout is instituted. > It will need to be updated to use Commons Lang code style and package name > space, as well as have a test case written for it. I'm not sure how that > should work given it's platform specific nature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
