You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Markus Wiederkehr (JIRA)" <se...@james.apache.org> on 2008/10/27 15:40:44 UTC
[jira] Created: (MIME4J-83) Add a more generic machanism for
storing message bodies
Add a more generic machanism for storing message bodies
-------------------------------------------------------
Key: MIME4J-83
URL: https://issues.apache.org/jira/browse/MIME4J-83
Project: JAMES Mime4j
Issue Type: New Feature
Affects Versions: 0.5
Reporter: Markus Wiederkehr
Currently Mime4j uses TempStorage, TempPath and TempFile to store the contents of a text or binary body of a message. While this design allows for TempStorage to be replaced with a custom implementation it does not seem to be generic enough.
A TempStorage implementation may choose to keep the data in memory but it still has to deal with things like file name prefixes/suffixes or creating subdirectories. The entire interface TempPath and many methods in TempFile seem to be unnecessary.
Also while an application can configure what TempStorage instance it wants to use (by means of a system property and a static setInstance method) there is no way to inject a TempStorage instance into a MessageBuilder.
An alternative storage mechanism should be simpler and more generic. It should be possible to provide implementations that store the data in memory or on disk in the system's temp folder for example. Other implementations could keep the data in memory as long as a certain threshold size does not get exceeded or use a specific folder on disk to store the files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-83) Add a more generic machanism for
storing message bodies
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr updated MIME4J-83:
------------------------------------
Attachment: mime4j-storageprovider.patch
Proposed solution (mime4j-storageprovider.patch):
The current storage mechanism gets replaced by two very small and simple interfaces: Storage and StorageProvider.
DefaultStorageProvider allows for a default instance to be configured on an application level.
MemoryStorageProvider and TempFileStorageProvider are implementations that store the data in memory or on disk respectively.
ThresholdStorageProvider uses another StorageProvider as back-end but only writes to this back-end if a certain threshold size gets exceeded. CipherStorageProvider can be used to encrpt/decrypt the contents of a back-end.
A StorageProvider can be injected into MessageBuilder and Message (constructor-based injection).
I can add more JavaDoc and unit tests if you decide to include this patch..
> Add a more generic machanism for storing message bodies
> -------------------------------------------------------
>
> Key: MIME4J-83
> URL: https://issues.apache.org/jira/browse/MIME4J-83
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Attachments: mime4j-storageprovider.patch
>
>
> Currently Mime4j uses TempStorage, TempPath and TempFile to store the contents of a text or binary body of a message. While this design allows for TempStorage to be replaced with a custom implementation it does not seem to be generic enough.
> A TempStorage implementation may choose to keep the data in memory but it still has to deal with things like file name prefixes/suffixes or creating subdirectories. The entire interface TempPath and many methods in TempFile seem to be unnecessary.
> Also while an application can configure what TempStorage instance it wants to use (by means of a system property and a static setInstance method) there is no way to inject a TempStorage instance into a MessageBuilder.
> An alternative storage mechanism should be simpler and more generic. It should be possible to provide implementations that store the data in memory or on disk in the system's temp folder for example. Other implementations could keep the data in memory as long as a certain threshold size does not get exceeded or use a specific folder on disk to store the files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-83) Add a more generic machanism for
storing message bodies
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr updated MIME4J-83:
------------------------------------
Attachment: (was: mime4j-storageprovider.patch)
> Add a more generic machanism for storing message bodies
> -------------------------------------------------------
>
> Key: MIME4J-83
> URL: https://issues.apache.org/jira/browse/MIME4J-83
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
>
> Currently Mime4j uses TempStorage, TempPath and TempFile to store the contents of a text or binary body of a message. While this design allows for TempStorage to be replaced with a custom implementation it does not seem to be generic enough.
> A TempStorage implementation may choose to keep the data in memory but it still has to deal with things like file name prefixes/suffixes or creating subdirectories. The entire interface TempPath and many methods in TempFile seem to be unnecessary.
> Also while an application can configure what TempStorage instance it wants to use (by means of a system property and a static setInstance method) there is no way to inject a TempStorage instance into a MessageBuilder.
> An alternative storage mechanism should be simpler and more generic. It should be possible to provide implementations that store the data in memory or on disk in the system's temp folder for example. Other implementations could keep the data in memory as long as a certain threshold size does not get exceeded or use a specific folder on disk to store the files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (MIME4J-83) Add a more generic machanism for
storing message bodies
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved MIME4J-83.
-------------------------------------
Resolution: Fixed
Fix Version/s: 0.6
Patch checked in. Many thanks, Markus
Oleg
> Add a more generic machanism for storing message bodies
> -------------------------------------------------------
>
> Key: MIME4J-83
> URL: https://issues.apache.org/jira/browse/MIME4J-83
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Fix For: 0.6
>
> Attachments: mime4j-storageprovider.patch
>
>
> Currently Mime4j uses TempStorage, TempPath and TempFile to store the contents of a text or binary body of a message. While this design allows for TempStorage to be replaced with a custom implementation it does not seem to be generic enough.
> A TempStorage implementation may choose to keep the data in memory but it still has to deal with things like file name prefixes/suffixes or creating subdirectories. The entire interface TempPath and many methods in TempFile seem to be unnecessary.
> Also while an application can configure what TempStorage instance it wants to use (by means of a system property and a static setInstance method) there is no way to inject a TempStorage instance into a MessageBuilder.
> An alternative storage mechanism should be simpler and more generic. It should be possible to provide implementations that store the data in memory or on disk in the system's temp folder for example. Other implementations could keep the data in memory as long as a certain threshold size does not get exceeded or use a specific folder on disk to store the files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-83) Add a more generic machanism for
storing message bodies
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr updated MIME4J-83:
------------------------------------
Attachment: (was: mime4j-storageprovider.patch)
> Add a more generic machanism for storing message bodies
> -------------------------------------------------------
>
> Key: MIME4J-83
> URL: https://issues.apache.org/jira/browse/MIME4J-83
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Attachments: mime4j-storageprovider.patch
>
>
> Currently Mime4j uses TempStorage, TempPath and TempFile to store the contents of a text or binary body of a message. While this design allows for TempStorage to be replaced with a custom implementation it does not seem to be generic enough.
> A TempStorage implementation may choose to keep the data in memory but it still has to deal with things like file name prefixes/suffixes or creating subdirectories. The entire interface TempPath and many methods in TempFile seem to be unnecessary.
> Also while an application can configure what TempStorage instance it wants to use (by means of a system property and a static setInstance method) there is no way to inject a TempStorage instance into a MessageBuilder.
> An alternative storage mechanism should be simpler and more generic. It should be possible to provide implementations that store the data in memory or on disk in the system's temp folder for example. Other implementations could keep the data in memory as long as a certain threshold size does not get exceeded or use a specific folder on disk to store the files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-83) Add a more generic machanism for
storing message bodies
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648711#action_12648711 ]
Oleg Kalnichevski commented on MIME4J-83:
-----------------------------------------
If I hear no objections I'll commit the patch in two days.
Oleg
> Add a more generic machanism for storing message bodies
> -------------------------------------------------------
>
> Key: MIME4J-83
> URL: https://issues.apache.org/jira/browse/MIME4J-83
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Attachments: mime4j-storageprovider.patch
>
>
> Currently Mime4j uses TempStorage, TempPath and TempFile to store the contents of a text or binary body of a message. While this design allows for TempStorage to be replaced with a custom implementation it does not seem to be generic enough.
> A TempStorage implementation may choose to keep the data in memory but it still has to deal with things like file name prefixes/suffixes or creating subdirectories. The entire interface TempPath and many methods in TempFile seem to be unnecessary.
> Also while an application can configure what TempStorage instance it wants to use (by means of a system property and a static setInstance method) there is no way to inject a TempStorage instance into a MessageBuilder.
> An alternative storage mechanism should be simpler and more generic. It should be possible to provide implementations that store the data in memory or on disk in the system's temp folder for example. Other implementations could keep the data in memory as long as a certain threshold size does not get exceeded or use a specific folder on disk to store the files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-83) Add a more generic machanism for
storing message bodies
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr updated MIME4J-83:
------------------------------------
Attachment: mime4j-storageprovider.patch
Added more Javadoc and unit tests. Minor optimizations.
> Add a more generic machanism for storing message bodies
> -------------------------------------------------------
>
> Key: MIME4J-83
> URL: https://issues.apache.org/jira/browse/MIME4J-83
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Attachments: mime4j-storageprovider.patch
>
>
> Currently Mime4j uses TempStorage, TempPath and TempFile to store the contents of a text or binary body of a message. While this design allows for TempStorage to be replaced with a custom implementation it does not seem to be generic enough.
> A TempStorage implementation may choose to keep the data in memory but it still has to deal with things like file name prefixes/suffixes or creating subdirectories. The entire interface TempPath and many methods in TempFile seem to be unnecessary.
> Also while an application can configure what TempStorage instance it wants to use (by means of a system property and a static setInstance method) there is no way to inject a TempStorage instance into a MessageBuilder.
> An alternative storage mechanism should be simpler and more generic. It should be possible to provide implementations that store the data in memory or on disk in the system's temp folder for example. Other implementations could keep the data in memory as long as a certain threshold size does not get exceeded or use a specific folder on disk to store the files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-83) Add a more generic machanism for
storing message bodies
Posted by "Markus Wiederkehr (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Markus Wiederkehr updated MIME4J-83:
------------------------------------
Attachment: mime4j-storageprovider.patch
Updated patch for current trunk.
> Add a more generic machanism for storing message bodies
> -------------------------------------------------------
>
> Key: MIME4J-83
> URL: https://issues.apache.org/jira/browse/MIME4J-83
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Attachments: mime4j-storageprovider.patch
>
>
> Currently Mime4j uses TempStorage, TempPath and TempFile to store the contents of a text or binary body of a message. While this design allows for TempStorage to be replaced with a custom implementation it does not seem to be generic enough.
> A TempStorage implementation may choose to keep the data in memory but it still has to deal with things like file name prefixes/suffixes or creating subdirectories. The entire interface TempPath and many methods in TempFile seem to be unnecessary.
> Also while an application can configure what TempStorage instance it wants to use (by means of a system property and a static setInstance method) there is no way to inject a TempStorage instance into a MessageBuilder.
> An alternative storage mechanism should be simpler and more generic. It should be possible to provide implementations that store the data in memory or on disk in the system's temp folder for example. Other implementations could keep the data in memory as long as a certain threshold size does not get exceeded or use a specific folder on disk to store the files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-83) Add a more generic machanism for
storing message bodies
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648011#action_12648011 ]
Oleg Kalnichevski commented on MIME4J-83:
-----------------------------------------
Patch looks good to me. +1 to commit
Oleg
> Add a more generic machanism for storing message bodies
> -------------------------------------------------------
>
> Key: MIME4J-83
> URL: https://issues.apache.org/jira/browse/MIME4J-83
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Attachments: mime4j-storageprovider.patch
>
>
> Currently Mime4j uses TempStorage, TempPath and TempFile to store the contents of a text or binary body of a message. While this design allows for TempStorage to be replaced with a custom implementation it does not seem to be generic enough.
> A TempStorage implementation may choose to keep the data in memory but it still has to deal with things like file name prefixes/suffixes or creating subdirectories. The entire interface TempPath and many methods in TempFile seem to be unnecessary.
> Also while an application can configure what TempStorage instance it wants to use (by means of a system property and a static setInstance method) there is no way to inject a TempStorage instance into a MessageBuilder.
> An alternative storage mechanism should be simpler and more generic. It should be possible to provide implementations that store the data in memory or on disk in the system's temp folder for example. Other implementations could keep the data in memory as long as a certain threshold size does not get exceeded or use a specific folder on disk to store the files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org