You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Ron Mann (JIRA)" <ji...@apache.org> on 2007/07/27 20:41:53 UTC
[jira] Created: (RIVER-116) Multiple jar files with conflicting
lists need facilities to map the chosen preferred value
Multiple jar files with conflicting lists need facilities to map the chosen preferred value
-------------------------------------------------------------------------------------------
Key: RIVER-116
URL: https://issues.apache.org/jira/browse/RIVER-116
Project: River
Issue Type: Improvement
Components: com_sun_jini_tool
Affects Versions: jtsk_2.1
Reporter: Ron Mann
Bugtraq Id [6353590|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6353590]
Submitted by Mark Brouwer:
"In case you wrap 2 or more JAR files and the preferred list for these
files result in a preferences conflict an IOException is thrown. I would
like to have a facility to provide a map of classes (namespaces?) with
their associated preferred value that will be *the* authority to decide
what the desired value for a class must be and that wrapping will continue.
The use case is that Seven adds code to the service proxy and the
download JAR files for the container added code contains a preferred
list that might conflict with that of the JSC Service download JAR file.
It is possible that from the perspective of the JSC Service proxy a
class is an implementation detail but from the perspective of the
container is API. Currently this results in a preferences conflict when
JAR wrapping.
I don't want a JSC Service developer to have knowledge of the
implementation details of a JSC compliant container and to take that
knowledge into account when they create their download JAR files."
*** (#1 of 1): 2005-11-21 07:19:03 EST ron.mann@sun.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (RIVER-116) Multiple jar files with conflicting
lists need facilities to map the chosen preferred value
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer reassigned RIVER-116:
----------------------------------
Assignee: Mark Brouwer
> Multiple jar files with conflicting lists need facilities to map the chosen preferred value
> -------------------------------------------------------------------------------------------
>
> Key: RIVER-116
> URL: https://issues.apache.org/jira/browse/RIVER-116
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Ron Mann
> Assignee: Mark Brouwer
>
> Bugtraq Id [6353590|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6353590]
> Submitted by Mark Brouwer:
> "In case you wrap 2 or more JAR files and the preferred list for these
> files result in a preferences conflict an IOException is thrown. I would
> like to have a facility to provide a map of classes (namespaces?) with
> their associated preferred value that will be *the* authority to decide
> what the desired value for a class must be and that wrapping will continue.
> The use case is that Seven adds code to the service proxy and the
> download JAR files for the container added code contains a preferred
> list that might conflict with that of the JSC Service download JAR file.
> It is possible that from the perspective of the JSC Service proxy a
> class is an implementation detail but from the perspective of the
> container is API. Currently this results in a preferences conflict when
> JAR wrapping.
> I don't want a JSC Service developer to have knowledge of the
> implementation details of a JSC compliant container and to take that
> knowledge into account when they create their download JAR files."
> *** (#1 of 1): 2005-11-21 07:19:03 EST ron.mann@sun.com
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-116) Multiple jar files with conflicting
lists need facilities to map the chosen preferred value
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-116:
-------------------------------
Description:
Bugtraq Id [6353590|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6353590]
Submitted by Mark Brouwer:
"In case you wrap 2 or more JAR files and the preferred list for these files result in a preferences conflict an {{IOException}} is thrown. I would
like to have a facility to provide a map of classes (namespaces?) with their associated preferred value that will be *the* authority to decide
what the desired value for a class must be and that wrapping will continue.
The use case is that Seven adds code to the service proxy and the download JAR files for the container added code contains a preferred
list that might conflict with that of the JSC Service download JAR file. It is possible that from the perspective of the JSC Service proxy a
class is an implementation detail but from the perspective of the container is API. Currently this results in a preferences conflict when
JAR wrapping.
I don't want a JSC Service developer to have knowledge of the implementation details of a JSC compliant container and to take that
knowledge into account when they create their download JAR files."
was:
Bugtraq Id [6353590|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6353590]
Submitted by Mark Brouwer:
"In case you wrap 2 or more JAR files and the preferred list for these
files result in a preferences conflict an IOException is thrown. I would
like to have a facility to provide a map of classes (namespaces?) with
their associated preferred value that will be *the* authority to decide
what the desired value for a class must be and that wrapping will continue.
The use case is that Seven adds code to the service proxy and the
download JAR files for the container added code contains a preferred
list that might conflict with that of the JSC Service download JAR file.
It is possible that from the perspective of the JSC Service proxy a
class is an implementation detail but from the perspective of the
container is API. Currently this results in a preferences conflict when
JAR wrapping.
I don't want a JSC Service developer to have knowledge of the
implementation details of a JSC compliant container and to take that
knowledge into account when they create their download JAR files."
*** (#1 of 1): 2005-11-21 07:19:03 EST ron.mann@sun.com
Fix Version/s: AR2
> Multiple jar files with conflicting lists need facilities to map the chosen preferred value
> -------------------------------------------------------------------------------------------
>
> Key: RIVER-116
> URL: https://issues.apache.org/jira/browse/RIVER-116
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Ron Mann
> Assignee: Mark Brouwer
> Fix For: AR2
>
>
> Bugtraq Id [6353590|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6353590]
> Submitted by Mark Brouwer:
> "In case you wrap 2 or more JAR files and the preferred list for these files result in a preferences conflict an {{IOException}} is thrown. I would
> like to have a facility to provide a map of classes (namespaces?) with their associated preferred value that will be *the* authority to decide
> what the desired value for a class must be and that wrapping will continue.
> The use case is that Seven adds code to the service proxy and the download JAR files for the container added code contains a preferred
> list that might conflict with that of the JSC Service download JAR file. It is possible that from the perspective of the JSC Service proxy a
> class is an implementation detail but from the perspective of the container is API. Currently this results in a preferences conflict when
> JAR wrapping.
> I don't want a JSC Service developer to have knowledge of the implementation details of a JSC compliant container and to take that
> knowledge into account when they create their download JAR files."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (RIVER-116) Multiple jar files with conflicting
lists need facilities to map the chosen preferred value
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone closed RIVER-116.
---------------------------------
> Multiple jar files with conflicting lists need facilities to map the chosen preferred value
> -------------------------------------------------------------------------------------------
>
> Key: RIVER-116
> URL: https://issues.apache.org/jira/browse/RIVER-116
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Ron Mann
> Assignee: Mark Brouwer
> Fix For: AR2
>
>
> Bugtraq Id [6353590|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6353590]
> Submitted by Mark Brouwer:
> "In case you wrap 2 or more JAR files and the preferred list for these files result in a preferences conflict an {{IOException}} is thrown. I would
> like to have a facility to provide a map of classes (namespaces?) with their associated preferred value that will be *the* authority to decide
> what the desired value for a class must be and that wrapping will continue.
> The use case is that Seven adds code to the service proxy and the download JAR files for the container added code contains a preferred
> list that might conflict with that of the JSC Service download JAR file. It is possible that from the perspective of the JSC Service proxy a
> class is an implementation detail but from the perspective of the container is API. Currently this results in a preferences conflict when
> JAR wrapping.
> I don't want a JSC Service developer to have knowledge of the implementation details of a JSC compliant container and to take that
> knowledge into account when they create their download JAR files."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (RIVER-116) Multiple jar files with conflicting
lists need facilities to map the chosen preferred value
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer resolved RIVER-116.
--------------------------------
Resolution: Fixed
Fixed as part of RIVER-115.
> Multiple jar files with conflicting lists need facilities to map the chosen preferred value
> -------------------------------------------------------------------------------------------
>
> Key: RIVER-116
> URL: https://issues.apache.org/jira/browse/RIVER-116
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Ron Mann
> Assignee: Mark Brouwer
> Fix For: AR2
>
>
> Bugtraq Id [6353590|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6353590]
> Submitted by Mark Brouwer:
> "In case you wrap 2 or more JAR files and the preferred list for these files result in a preferences conflict an {{IOException}} is thrown. I would
> like to have a facility to provide a map of classes (namespaces?) with their associated preferred value that will be *the* authority to decide
> what the desired value for a class must be and that wrapping will continue.
> The use case is that Seven adds code to the service proxy and the download JAR files for the container added code contains a preferred
> list that might conflict with that of the JSC Service download JAR file. It is possible that from the perspective of the JSC Service proxy a
> class is an implementation detail but from the perspective of the container is API. Currently this results in a preferences conflict when
> JAR wrapping.
> I don't want a JSC Service developer to have knowledge of the implementation details of a JSC compliant container and to take that
> knowledge into account when they create their download JAR files."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.