[jira] [Issue Comment Deleted] (SCXML-196) Redefine SCXMLSemantics to align with the Algorithm for SCXML Interpretation as described in the SCXML specification
[ https://issues.apache.org/jira/browse/SCXML-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma updated SCXML-196: Comment: was deleted (was: Ugh, above initial plan already starts breaking down :( Keeping the existing implementation (SCXMLExecutor and SCXMSemanticsImpl) working while starting refactoring the initialScript (to be renamed to globalScript) handling is already too much complicated and invasive for the existing implementation to be reasonable to retain both implementations side-by-side. So, I will drop this plan as well as the new SCXMLExecutor2 and SCXMLSemanticsImpl2 classes, and instead start hacking directly on the existing implementation. This means it will be impossible, within the same codebase, to check and compare the old against the new semantics, but so be it. The milestone 0 tag at least is available to code compare against, and the current, and for sure needed additional, unit tests to validate against. This also means the current trunk will undergo a lot more immediately changes as of now! ) > Redefine SCXMLSemantics to align with the Algorithm for SCXML Interpretation > as described in the SCXML specification > > > Key: SCXML-196 > URL: https://issues.apache.org/jira/browse/SCXML-196 > Project: Commons SCXML > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Ate Douma >Assignee: Ate Douma > Fix For: 2.0 > > > One of the targets for the Commons SCXM 2.0 roadmap milestone 1 is to > redefine SCXMLSemantics to align with the SCXML Algorithm for SCXML > Interpretation, see: > http://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation > The current SCXMLSemantics interface and its implementation is so much > different from the algorithm in the specification that 'molding' it into what > the algorithm now expects is too cumbersome. > The high-level plan I have is to: > - fork SCXMLSemanticsImpl to SCXMLSemanticsImpl2, without implementing > SCXMLSemantics > - fork SCXMLExecutor to SCXMLExecutor2, extending SCXMLExecutor > - switch to use SCXMLSemanticsImpl2 explicitly in SCXMLExecutor2 > - start with simply implementing the SCXML Algorithm from 'scratch' in > SCXMLSemanticsImpl2 using (top level) methods matching those described in the > algorithm and refactor SCXMLExecutor2 to leverage this > With the above initial steps, the existing implementation will stay in place > and remains available to compare and test the new implementation against. > There probably will be need to make accommodating changes in other areas, > which I will try to keep compatible with the existing implementation or at > least not to break it. > The reason to fork and extend SCXMLExecutor is that it is referenced and used > in many other places (that is: currently), like in SCInstance. By extending > it, the SCXMLExecutor2 can still play that role without directly breaking > everything. > The algorithm described in the specification leaves plenty of room for > optimization and choice of techniques. > For a first cut implementation though I intend to simply follow the described > algorithm as close as possible, also to make sure not to deviate from the > specification already too early :) > After the new implementation has been tested and validated to be comforming > the expected behavior, or even later than that, the implementation surely can > be refined and optimized further. > That also will be time to decide to drop and replace the existing > SCXMLExecutor and SCXMLSemantics (both interface and implementation) with the > new versions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (NET-531) IMAPClient.getReplyCode() : Matcher.matches() returns false for lines with EOL chars
[ https://issues.apache.org/jira/browse/NET-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark closed NET-531. Resolution: Invalid > IMAPClient.getReplyCode() : Matcher.matches() returns false for lines with > EOL chars > > > Key: NET-531 > URL: https://issues.apache.org/jira/browse/NET-531 > Project: Commons Net > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Mark >Priority: Minor > > IMAPClient.getReplyCode(client.getReplyString()) always fails with invalid > reply message. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NET-531) IMAPClient.getReplyCode() : Matcher.matches() returns false for lines with EOL chars
Mark created NET-531: Summary: IMAPClient.getReplyCode() : Matcher.matches() returns false for lines with EOL chars Key: NET-531 URL: https://issues.apache.org/jira/browse/NET-531 Project: Commons Net Issue Type: Bug Affects Versions: 3.3 Reporter: Mark Priority: Minor IMAPClient.getReplyCode(client.getReplyString()) always fails with invalid reply message. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (NET-530) input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) is not used
[ https://issues.apache.org/jira/browse/NET-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-530. -- Resolution: Fixed Thanks for the report. Fixed: URL: http://svn.apache.org/r1584204 Log: NET-530 input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) is not used Modified: commons/proper/net/trunk/src/changes/changes.xml commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTP.java > input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) is not > used > - > > Key: NET-530 > URL: https://issues.apache.org/jira/browse/NET-530 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.3 > Environment: windows or linux >Reporter: fish ship >Priority: Minor > Labels: test > Fix For: 3.4 > > Original Estimate: 1h > Remaining Estimate: 1h > > i noticed the the input parameter 'boolean reportReply' in method > org.apache.commons.net.ftp.FTP.__getReply(boolean) is never be used. so it > seemde there is no difference between > org.apache.commons.net.ftp.FTP.__getReplyNoReport() and > org.apache.commons.net.ftp.FTP.__getReply(). > who could tell me why? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (NET-530) input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) is not used
[ https://issues.apache.org/jira/browse/NET-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-530: - Summary: input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) is not used (was: input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) nevere be used) > input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) is not > used > - > > Key: NET-530 > URL: https://issues.apache.org/jira/browse/NET-530 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.3 > Environment: windows or linux >Reporter: fish ship >Priority: Minor > Labels: test > Fix For: 3.4 > > Original Estimate: 1h > Remaining Estimate: 1h > > i noticed the the input parameter 'boolean reportReply' in method > org.apache.commons.net.ftp.FTP.__getReply(boolean) is never be used. so it > seemde there is no difference between > org.apache.commons.net.ftp.FTP.__getReplyNoReport() and > org.apache.commons.net.ftp.FTP.__getReply(). > who could tell me why? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (NET-530) input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) nevere be used
[ https://issues.apache.org/jira/browse/NET-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13958243#comment-13958243 ] Sebb commented on NET-530: -- It's a bug; the parameter is suppose to be used to control whether the reply is sent to the listeners. > input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) nevere > be used > > > Key: NET-530 > URL: https://issues.apache.org/jira/browse/NET-530 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.3 > Environment: windows or linux >Reporter: fish ship >Priority: Minor > Labels: test > Fix For: 3.4 > > Original Estimate: 1h > Remaining Estimate: 1h > > i noticed the the input parameter 'boolean reportReply' in method > org.apache.commons.net.ftp.FTP.__getReply(boolean) is never be used. so it > seemde there is no difference between > org.apache.commons.net.ftp.FTP.__getReplyNoReport() and > org.apache.commons.net.ftp.FTP.__getReply(). > who could tell me why? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (NET-530) input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) nevere be used
[ https://issues.apache.org/jira/browse/NET-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-530: - Affects Version/s: (was: 3.0) 3.3 > input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) nevere > be used > > > Key: NET-530 > URL: https://issues.apache.org/jira/browse/NET-530 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.3 > Environment: windows or linux >Reporter: fish ship >Priority: Minor > Labels: test > Fix For: 3.4 > > Original Estimate: 1h > Remaining Estimate: 1h > > i noticed the the input parameter 'boolean reportReply' in method > org.apache.commons.net.ftp.FTP.__getReply(boolean) is never be used. so it > seemde there is no difference between > org.apache.commons.net.ftp.FTP.__getReplyNoReport() and > org.apache.commons.net.ftp.FTP.__getReply(). > who could tell me why? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CONFIGURATION-572) Possible memory leak when using CombinedConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13957920#comment-13957920 ] Oliver Heger commented on CONFIGURATION-572: Thank you very much for this report. Currently, there is a major refactoring ongoing which will eventually lead to version 2.0. In this progress, your proposed change can be applied. > Possible memory leak when using CombinedConfiguration > - > > Key: CONFIGURATION-572 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-572 > Project: Commons Configuration > Issue Type: Bug >Reporter: Rob Walker >Priority: Minor > Attachments: 2960.patch > > > We altered our code to use CombinedConfiguration in a more dynamic way and > immediately started to see large memory usage. Looking for a potential leak, > we realised we were missing a clear() when the config objects were done with. > Even with this call in, the leak persisted. It seems that whilst the clear() > method cleans up the object, it doesn't clear the listener list as well. This > leaves around stale references which then never become GC. > Will attach the patch we found worked at curing this -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (NET-530) input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) nevere be used
fish ship created NET-530: - Summary: input parameter of org.apache.commons.net.ftp.FTP.__getReply(boolean) nevere be used Key: NET-530 URL: https://issues.apache.org/jira/browse/NET-530 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0 Environment: windows or linux Reporter: fish ship Priority: Minor Fix For: 3.4 i noticed the the input parameter 'boolean reportReply' in method org.apache.commons.net.ftp.FTP.__getReply(boolean) is never be used. so it seemde there is no difference between org.apache.commons.net.ftp.FTP.__getReplyNoReport() and org.apache.commons.net.ftp.FTP.__getReply(). who could tell me why? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IMAGING-129) XMP metadata processing not well documented
[ https://issues.apache.org/jira/browse/IMAGING-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] christophe blin updated IMAGING-129: Summary: XMP metadata processing not well documented (was: XMP metadata not processed) > XMP metadata processing not well documented > --- > > Key: IMAGING-129 > URL: https://issues.apache.org/jira/browse/IMAGING-129 > Project: Commons Imaging > Issue Type: Bug > Components: Documentation >Affects Versions: 1.x >Reporter: christophe blin > > Using commons-imaging-1.0-20140325.172317-8.jar > Using the image : > http://www.controlledvocabulary.com/images/drp2091169-sfw-q60-all-wicc.jpg > From the webpage : > http://www.controlledvocabulary.com/blog/top-metadata-myths.html > Code used : System.out.println(Imaging.getMetadata(new > File(filepath)).toString()); > Problem : the file embeds EXIF and XMP metadata, it seems that only EXIF is > processed. > Expected metadata to be found : > http://www.controlledvocabulary.com/blog/meta-overhead/drp2091169-sfw-q60-all-wicc.txt -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (IMAGING-129) XMP metadata not processed
[ https://issues.apache.org/jira/browse/IMAGING-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13957794#comment-13957794 ] christophe blin commented on IMAGING-129: - Ok this is my mistake : you must use the getXmpXml if you want to extract the XMP. This is quite confusing and should maybe have a notice inside the documentation > XMP metadata not processed > -- > > Key: IMAGING-129 > URL: https://issues.apache.org/jira/browse/IMAGING-129 > Project: Commons Imaging > Issue Type: Bug > Components: Documentation >Affects Versions: 1.x >Reporter: christophe blin > > Using commons-imaging-1.0-20140325.172317-8.jar > Using the image : > http://www.controlledvocabulary.com/images/drp2091169-sfw-q60-all-wicc.jpg > From the webpage : > http://www.controlledvocabulary.com/blog/top-metadata-myths.html > Code used : System.out.println(Imaging.getMetadata(new > File(filepath)).toString()); > Problem : the file embeds EXIF and XMP metadata, it seems that only EXIF is > processed. > Expected metadata to be found : > http://www.controlledvocabulary.com/blog/meta-overhead/drp2091169-sfw-q60-all-wicc.txt -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IMAGING-129) XMP metadata not processed
[ https://issues.apache.org/jira/browse/IMAGING-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] christophe blin updated IMAGING-129: Component/s: (was: Format: JPEG) Documentation > XMP metadata not processed > -- > > Key: IMAGING-129 > URL: https://issues.apache.org/jira/browse/IMAGING-129 > Project: Commons Imaging > Issue Type: Bug > Components: Documentation >Affects Versions: 1.x >Reporter: christophe blin > > Using commons-imaging-1.0-20140325.172317-8.jar > Using the image : > http://www.controlledvocabulary.com/images/drp2091169-sfw-q60-all-wicc.jpg > From the webpage : > http://www.controlledvocabulary.com/blog/top-metadata-myths.html > Code used : System.out.println(Imaging.getMetadata(new > File(filepath)).toString()); > Problem : the file embeds EXIF and XMP metadata, it seems that only EXIF is > processed. > Expected metadata to be found : > http://www.controlledvocabulary.com/blog/meta-overhead/drp2091169-sfw-q60-all-wicc.txt -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IMAGING-129) XMP metadata processing not well documented
[ https://issues.apache.org/jira/browse/IMAGING-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] christophe blin updated IMAGING-129: Priority: Minor (was: Major) > XMP metadata processing not well documented > --- > > Key: IMAGING-129 > URL: https://issues.apache.org/jira/browse/IMAGING-129 > Project: Commons Imaging > Issue Type: Bug > Components: Documentation >Affects Versions: 1.x >Reporter: christophe blin >Priority: Minor > > Using commons-imaging-1.0-20140325.172317-8.jar > Using the image : > http://www.controlledvocabulary.com/images/drp2091169-sfw-q60-all-wicc.jpg > From the webpage : > http://www.controlledvocabulary.com/blog/top-metadata-myths.html > Code used : System.out.println(Imaging.getMetadata(new > File(filepath)).toString()); > Problem : the file embeds EXIF and XMP metadata, it seems that only EXIF is > processed. > Expected metadata to be found : > http://www.controlledvocabulary.com/blog/meta-overhead/drp2091169-sfw-q60-all-wicc.txt -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (IMAGING-129) XMP metadata not processed
christophe blin created IMAGING-129: --- Summary: XMP metadata not processed Key: IMAGING-129 URL: https://issues.apache.org/jira/browse/IMAGING-129 Project: Commons Imaging Issue Type: Bug Components: Format: JPEG Affects Versions: 1.x Reporter: christophe blin Using commons-imaging-1.0-20140325.172317-8.jar Using the image : http://www.controlledvocabulary.com/images/drp2091169-sfw-q60-all-wicc.jpg >From the webpage : >http://www.controlledvocabulary.com/blog/top-metadata-myths.html Code used : System.out.println(Imaging.getMetadata(new File(filepath)).toString()); Problem : the file embeds EXIF and XMP metadata, it seems that only EXIF is processed. Expected metadata to be found : http://www.controlledvocabulary.com/blog/meta-overhead/drp2091169-sfw-q60-all-wicc.txt -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CONFIGURATION-572) Possible memory leak when using CombinedConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CONFIGURATION-572: --- Summary: Possible memory leak when using CombinedConfiguration (was: Possibe memory leak when using CombinedConfiguration) > Possible memory leak when using CombinedConfiguration > - > > Key: CONFIGURATION-572 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-572 > Project: Commons Configuration > Issue Type: Bug >Reporter: Rob Walker >Priority: Minor > Attachments: 2960.patch > > > We altered our code to use CombinedConfiguration in a more dynamic way and > immediately started to see large memory usage. Looking for a potential leak, > we realised we were missing a clear() when the config objects were done with. > Even with this call in, the leak persisted. It seems that whilst the clear() > method cleans up the object, it doesn't clear the listener list as well. This > leaves around stale references which then never become GC. > Will attach the patch we found worked at curing this -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CONFIGURATION-572) Possibe memory leak when using CombinedConfiguration
Rob Walker created CONFIGURATION-572: Summary: Possibe memory leak when using CombinedConfiguration Key: CONFIGURATION-572 URL: https://issues.apache.org/jira/browse/CONFIGURATION-572 Project: Commons Configuration Issue Type: Bug Reporter: Rob Walker Priority: Minor We altered our code to use CombinedConfiguration in a more dynamic way and immediately started to see large memory usage. Looking for a potential leak, we realised we were missing a clear() when the config objects were done with. Even with this call in, the leak persisted. It seems that whilst the clear() method cleans up the object, it doesn't clear the listener list as well. This leaves around stale references which then never become GC. Will attach the patch we found worked at curing this -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CONFIGURATION-572) Possibe memory leak when using CombinedConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Walker updated CONFIGURATION-572: - Attachment: 2960.patch > Possibe memory leak when using CombinedConfiguration > > > Key: CONFIGURATION-572 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-572 > Project: Commons Configuration > Issue Type: Bug >Reporter: Rob Walker >Priority: Minor > Attachments: 2960.patch > > > We altered our code to use CombinedConfiguration in a more dynamic way and > immediately started to see large memory usage. Looking for a potential leak, > we realised we were missing a clear() when the config objects were done with. > Even with this call in, the leak persisted. It seems that whilst the clear() > method cleans up the object, it doesn't clear the listener list as well. This > leaves around stale references which then never become GC. > Will attach the patch we found worked at curing this -- This message was sent by Atlassian JIRA (v6.2#6252)
