james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] Created: (MIME4J-145) Improve organization of fields and fields parsers
Date Thu, 24 Dec 2009 19:58:29 GMT
Improve organization of fields and fields parsers

                 Key: MIME4J-145
                 URL: https://issues.apache.org/jira/browse/MIME4J-145
             Project: JAMES Mime4j
          Issue Type: Improvement
    Affects Versions: 0.6
            Reporter: Stefano Bagnara
            Assignee: Stefano Bagnara
            Priority: Minor
             Fix For: 0.7

I'd like to fix some issue in the organization of fields and field parsers asap, while we
are still on "low" (0.x) release numbers.

One thing is to remove DefaultFieldParser knowledge in AbstractField, another would be to
reorganize things so that parsing of headers is done in a single place. Currently we have
some parsing in Fields, some parsing in MaximalBodyDescriptor, some parser use the DefaultFieldParser,
some other code instead directly instantiate the AbstractField instance.

One more thing is parsing of raw headers: we have 2 different logic to do the same thing.
Once in RawBody where we do one thing to extract name and body, and once in DefaultFieldParser.parse(final
ByteSequence raw), where we do different things. E.g: the first simply locate the ":" and
do not remove any starting space from the body, the second instead has a regexp matching valid
header names and remove the starting space from the body.

Last one is MimeUtil.getHeaderParams, a parser that will parse header parameters. It is used
by MaximalBodyDescriptor.parseContentDisposition and by DefaultBodyDescriptor.parseContentType.
 At the same type we have ContentTypeParser and ContentDispositionParser classes also doing
parsing for that headers. Why do we have 2 implementations for the parsing of the same headers?

Is there a logic behind this or is this simply the result of years of different hands and
refactorings and we simply should fix it?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message