river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Brouwer (JIRA)" <j...@apache.org>
Subject [jira] Updated: (RIVER-115) Multiple jar files with conflicting lists need facilities to map the chosen preferred value
Date Tue, 12 Feb 2008 20:49:07 GMT

     [ https://issues.apache.org/jira/browse/RIVER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mark Brouwer updated RIVER-115:
-------------------------------

      Description: 
Bugtraq ID [6353590|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=635590] 
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=635590] 
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."

    Fix Version/s: AR2

> Multiple jar files with conflicting lists need facilities to map the chosen preferred
value
> -------------------------------------------------------------------------------------------
>
>                 Key: RIVER-115
>                 URL: https://issues.apache.org/jira/browse/RIVER-115
>             Project: River
>          Issue Type: Improvement
>          Components: com_sun_jini_tool
>    Affects Versions: jtsk_2.1
>            Reporter: Ron Mann
>            Assignee: Mark Brouwer
>            Priority: Minor
>             Fix For: AR2
>
>
> Bugtraq ID [6353590|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=635590] 
> 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.


Mime
View raw message