You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by "Stefano Bagnara (JIRA)" <mi...@james.apache.org> on 2009/12/27 20:37:29 UTC
[jira] Created: (MIME4J-147) Move "default parsing" logic from
AbstractField to DefaultFieldParser
Move "default parsing" logic from AbstractField to DefaultFieldParser
---------------------------------------------------------------------
Key: MIME4J-147
URL: https://issues.apache.org/jira/browse/MIME4J-147
Project: JAMES Mime4j
Issue Type: Improvement
Affects Versions: 0.6
Reporter: Stefano Bagnara
Assignee: Stefano Bagnara
Priority: Critical
Fix For: 0.7
As suggested in the ml we should move the default "delegation based" parsing logic from AbstractField to DefaultFieldParser.
This way we remove a lot of cycles in the code and the "default parsing" is exposed vua DefaultFieldParser instead of AbstractField (i never liked exposing a public feature via a static method of an abstract class).
here the ml message:
--
AbstractField is the abstract class extended by each specific field
implementation.
AbstractField, at the same time, provide "static" access to a
DefaultFieldParser and provides static methods to get a
DefaultFieldParser and to parse a string into a field using that
default field parser.
So every field extend abstractField but AbstractField have a link to
every of its implementations via DefaultFieldParser =>
DelegatingFieldParser.
This smells like a very bad idea. Is it me?
So, if you agree this should be improved here are 2 alternative solutions:
1) the easy fix would be to move all of the static stuff from
AbstractField to DefaultFieldParser. As the methods are public static
methods this would introduce a backward compatibility issue.
--
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MIME4J-147) Move "default parsing" logic from
AbstractField to DefaultFieldParser
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara resolved MIME4J-147.
------------------------------------
Resolution: Fixed
Change applied.
> Move "default parsing" logic from AbstractField to DefaultFieldParser
> ---------------------------------------------------------------------
>
> Key: MIME4J-147
> URL: https://issues.apache.org/jira/browse/MIME4J-147
> Project: JAMES Mime4j
> Issue Type: Improvement
> Affects Versions: 0.6
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Priority: Critical
> Fix For: 0.7
>
>
> As suggested in the ml we should move the default "delegation based" parsing logic from AbstractField to DefaultFieldParser.
> This way we remove a lot of cycles in the code and the "default parsing" is exposed vua DefaultFieldParser instead of AbstractField (i never liked exposing a public feature via a static method of an abstract class).
> here the ml message:
> --
> AbstractField is the abstract class extended by each specific field
> implementation.
> AbstractField, at the same time, provide "static" access to a
> DefaultFieldParser and provides static methods to get a
> DefaultFieldParser and to parse a string into a field using that
> default field parser.
> So every field extend abstractField but AbstractField have a link to
> every of its implementations via DefaultFieldParser =>
> DelegatingFieldParser.
> This smells like a very bad idea. Is it me?
> So, if you agree this should be improved here are 2 alternative solutions:
> 1) the easy fix would be to move all of the static stuff from
> AbstractField to DefaultFieldParser. As the methods are public static
> methods this would introduce a backward compatibility issue.
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.