You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Mark Brouwer (JIRA)" <ji...@apache.org> on 2007/05/07 13:32:17 UTC
[jira] Created: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
PreferredListGen can create illegal PREFERRED.LIST
--------------------------------------------------
Key: RIVER-24
URL: https://issues.apache.org/jira/browse/RIVER-24
Project: River
Issue Type: Bug
Reporter: Mark Brouwer
Assigned To: Mark Brouwer
Priority: Minor
{{com.sun.jini.tool.PreferredListGen}} can generate an illegal {{PREFERRED.LIST}} when no preferred default entry is specified and there are no individual preferred entries listed. In this case the utility should add an preferred default entry of {{false}} itself.
One can also argue whether the semantics for {{net.jini.loader.pref.PreferredClassLoader}} {quote}A preferred list must contain either a default preferred entry or at least one named preferred entry{quote} are not a bit too strict given the fact that no preferred default entry means that all non-matching classes in the list are by default non-preferred, but I guess fixing {{PreferredListGen}} is easier than going for a specification change which might be logical anyway although not clear to me at this point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on RIVER-24 started by Mark Brouwer.
> PreferredListGen can create illegal PREFERRED.LIST
> --------------------------------------------------
>
> Key: RIVER-24
> URL: https://issues.apache.org/jira/browse/RIVER-24
> Project: River
> Issue Type: Bug
> Reporter: Mark Brouwer
> Assigned To: Mark Brouwer
> Priority: Minor
>
> {{com.sun.jini.tool.PreferredListGen}} can generate an illegal {{PREFERRED.LIST}} when no preferred default entry is specified and there are no individual preferred entries listed. In this case the utility should add an preferred default entry of {{false}} itself.
> One can also argue whether the semantics for {{net.jini.loader.pref.PreferredClassLoader}} {quote}A preferred list must contain either a default preferred entry or at least one named preferred entry{quote} are not a bit too strict given the fact that no preferred default entry means that all non-matching classes in the list are by default non-preferred, but I guess fixing {{PreferredListGen}} is easier than going for a specification change which might be logical anyway although not clear to me at this point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone closed RIVER-24.
--------------------------------
> PreferredListGen can create illegal PREFERRED.LIST
> --------------------------------------------------
>
> Key: RIVER-24
> URL: https://issues.apache.org/jira/browse/RIVER-24
> Project: River
> Issue Type: Bug
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Priority: Minor
> Fix For: AR2
>
> Attachments: RIVER-24.patch
>
>
> {{com.sun.jini.tool.PreferredListGen}} can generate an illegal {{PREFERRED.LIST}} when no preferred default entry is specified and there are no individual preferred entries listed. In this case the utility should add an preferred default entry of {{false}} itself.
> One can also argue whether the semantics for {{net.jini.loader.pref.PreferredClassLoader}} {quote}A preferred list must contain either a default preferred entry or at least one named preferred entry{quote} are not a bit too strict given the fact that no preferred default entry means that all non-matching classes in the list are by default non-preferred, but I guess fixing {{PreferredListGen}} is easier than going for a specification change which might be logical anyway although not clear to me at this point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer resolved RIVER-24.
-------------------------------
Resolution: Fixed
In case there are no preferred entries and the default has not been specified a default preferred value of '{{false}}' will be written.
> PreferredListGen can create illegal PREFERRED.LIST
> --------------------------------------------------
>
> Key: RIVER-24
> URL: https://issues.apache.org/jira/browse/RIVER-24
> Project: River
> Issue Type: Bug
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Priority: Minor
> Fix For: AR2
>
> Attachments: RIVER-24.patch
>
>
> {{com.sun.jini.tool.PreferredListGen}} can generate an illegal {{PREFERRED.LIST}} when no preferred default entry is specified and there are no individual preferred entries listed. In this case the utility should add an preferred default entry of {{false}} itself.
> One can also argue whether the semantics for {{net.jini.loader.pref.PreferredClassLoader}} {quote}A preferred list must contain either a default preferred entry or at least one named preferred entry{quote} are not a bit too strict given the fact that no preferred default entry means that all non-matching classes in the list are by default non-preferred, but I guess fixing {{PreferredListGen}} is easier than going for a specification change which might be logical anyway although not clear to me at this point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-24:
------------------------------
Attachment: RIVER-24.patch
> PreferredListGen can create illegal PREFERRED.LIST
> --------------------------------------------------
>
> Key: RIVER-24
> URL: https://issues.apache.org/jira/browse/RIVER-24
> Project: River
> Issue Type: Bug
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Priority: Minor
> Fix For: AR2
>
> Attachments: RIVER-24.patch
>
>
> {{com.sun.jini.tool.PreferredListGen}} can generate an illegal {{PREFERRED.LIST}} when no preferred default entry is specified and there are no individual preferred entries listed. In this case the utility should add an preferred default entry of {{false}} itself.
> One can also argue whether the semantics for {{net.jini.loader.pref.PreferredClassLoader}} {quote}A preferred list must contain either a default preferred entry or at least one named preferred entry{quote} are not a bit too strict given the fact that no preferred default entry means that all non-matching classes in the list are by default non-preferred, but I guess fixing {{PreferredListGen}} is easier than going for a specification change which might be logical anyway although not clear to me at this point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Gregg,
Gregg Wonderly wrote:
> Mark Brouwer wrote:
>> It seems you want to prevent from downloading JAR files that is driven
>> by the codebase annotation (the codebase annotation contains the encoded
>> PREFERRED.LIST [1]). I believe you want to prevent from downloading JAR
>> files due to limited bandwidth you have over WAN connections.
>
> I want to have 100 services visible to a client, and discovery to not
> cause any codebase references and thus force downloading because of
> PREFERRED.LIST inquiries.
I understand the requirement of minimizing JAR file downloading,
although I take the following measurements to accomplish that:
1) partitioning of download JAR files, the codebase annotation points
to a dl.jar that is created by Seven while installing services and
thas uses JarWrapper and that only contains an INDEX.LIST,
MANIFEST.MF and PREFERRED.LIST. The size is around 1 KBytes and
refers to a lot of small download JAR files that can efficiently be
downloaded through the usage of INDEX.LIST. ServiceUI attributes
have their own download JAR files so these are not downloaded when
no ServiceUI needs to be instantiated;
2) Seven (upcoming) utilizes a persistent JAR file cache (through a
custom jar: protocol handler) that will check through an
if-modified-since whether download JAR files have been updated.
If not modified or no connection can be established once downloaded
JAR files are accessible by the class loaders. This is also extremely
important if you have data that relies on the availability of
codebases.
The above gave a dramatic reduction in download JAR traffic and a huge
saving in boot times for services that have been seen once by the JVM. I
realize that this requires a lot of plumbing, but I just want to
demonstrate that a lot of what you try to prevent can also be prevented
without any changes to codebases as is.
> You have to consider that I also have my reef project changes to Reggie
> active too. Thus, I can select when the service or any Entry values are
> deserialized.
>
> My service registrations include Entry values such as service names,
> icons, javax.help files (referenced by URLs) etc. I want to be able to
> display to the user, icons for all visible services without
> unmarshalling anything except the bare minimum which is needed to show
> the user icons and names.
I believe with a proper partitioning of your download JAR files you can
get very far. I'm not saying that this is an easy task though. There is
no way to prevent your service proxy to be unmarshalled and these can be
rather large. There are tricks possible there (lazy instantiation of
working parts through reflection) but this can get ugly.
>> To me it looks like you want the client to be the discriminator whether
>> classes (and thus the download JAR file) should be downloaded and not
>> the server through the PREFERRED.LIST it provides in the codebase
>> annotation, why do you want to turn that around?
>
> I have a known platform that my services adhere to. That platform is
> expressed in the PREFERRED.LIST explicitly, but is also expressed in the
I think I don't understand what you mean with the platform being
expressed in the preferred list as there is no notion of platform in the
semantics for preferred list.
I realize that some services assume a certain platfom to be available to
be able to work (their minimum platform) and that might differ from e.g.
the JTSK Platform. That is fine, but I always though of using an Entry
for that purposes, an entry that would be part of the minimum Jini
Platform on top of which another Platform could be defined, so the Entry
could be recognized by each and every Platform.
I haven't given it much though but it seems codebase or preferred list
feels the wrong place for specifying a platform. Codebase indicates
where the class definition(s) for some marshalled object can be obtained
and preferred list how class delegation should take place. A Platform
means to me the assumptions made by the service for it to be usable by a
client. When it doesn't meet the minimum platform it will likely fail
for some of its operations.
> jar content and the classloader behavior implicitly. I want the
> platform that the service is asserting to be conveyed to the client as
> part of the service registration, not as part of the services codebase
You really try to prevent from any form of downloading :-) and I'm
afraid that if we are going to allow meta-data in the codebase we get on
a slippery slope (I still see problems with the increase of data due to
all those 'larger' annotations).
> content. This would allow the client to decide whether or not it could
> be compatible with that platform, early on.
I think a Platform Entry together with proper partitioning of download
JAR files can get you very far, but I realize that unmarshalling the
service proxy is still problamatic. If a combination of proper
partitioning and maybe some enhancements to ServiceRegistrar we might
get even further.
>> [1] I guess the codebase annotation is getting rather large that way
>> (although RFC 2616 doesn't seem to place any a priori limit on the
>> length of a URI you might run into problems in reality due to this) and
>> I think the various marshalled streams don't optimize on recurring URIs
>> (no URI table I can detect for classes with the same annotation) so you
>> will be consuming additional bandwidth (a lot?).
>
> What I would say is that it's not part of the URL, but rather part of
> the structure of the annotation string, which would break compatiblity
> with arbitrary RMI applications when using the JRMP exporter. I.e. you
I think we should stick with URL/URI for codebase annotation, but I
think that still leaves some room for encoding meta-data if we come up
with useful meta-data.
> This, is just my initial thought of a trivial to implement solution for
> getting the information into the codebase string. It might be more
> compatible to use
>
> return codebase+" pref:/"+URLCoder.encode( new String(data) );
>
> to make the additional information be recognizable for what it is.
>
> The PreferredClassLoader would be changed to look at the annotation for
> the defined separator ('\n' or " pref:/" or whatever) and use that
> PREFERRED.LIST content instead of downloading one or more jars and
> extracting it.
What if we come up with a scheme that allows for encoding of meta-data
that when not understood can be ignored and works as normal (downloading
of JAR file(s) to obtain meta-data) but can be utilized by those who
want to do that for whatever purpose.
Also what I don't understand at this moment is why a platform identifier
is not sufficient, why do you want to communicate the whole preferred
list. If you know the platform there are hooks to customize your
delegation model (in Seven I do the same thing, there is a platform
definition that controls the exact delegation model, so service can't
hike upon some implementation details). In such a case if a class is not
part of the platform it needs to be downloaded at which point you can
trigger the initial download of the JAR file that contains the
PREFERRED.LIST.
Just some thought because I really can't oversee all the implications.
--
Mark
Re: [jira] Updated: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by Gregg Wonderly <gr...@wonderly.org>.
Mark Brouwer wrote:
> It seems you want to prevent from downloading JAR files that is driven
> by the codebase annotation (the codebase annotation contains the encoded
> PREFERRED.LIST [1]). I believe you want to prevent from downloading JAR
> files due to limited bandwidth you have over WAN connections.
I want to have 100 services visible to a client, and discovery to not cause any
codebase references and thus force downloading because of PREFERRED.LIST inquiries.
You have to consider that I also have my reef project changes to Reggie active
too. Thus, I can select when the service or any Entry values are deserialized.
My service registrations include Entry values such as service names, icons,
javax.help files (referenced by URLs) etc. I want to be able to display to the
user, icons for all visible services without unmarshalling anything except the
bare minimum which is needed to show the user icons and names.
> To me it looks like you want the client to be the discriminator whether
> classes (and thus the download JAR file) should be downloaded and not
> the server through the PREFERRED.LIST it provides in the codebase
> annotation, why do you want to turn that around?
I have a known platform that my services adhere to. That platform is expressed
in the PREFERRED.LIST explicitly, but is also expressed in the jar content and
the classloader behavior implicitly. I want the platform that the service is
asserting to be conveyed to the client as part of the service registration, not
as part of the services codebase content. This would allow the client to decide
whether or not it could be compatible with that platform, early on.
> [1] I guess the codebase annotation is getting rather large that way
> (although RFC 2616 doesn't seem to place any a priori limit on the
> length of a URI you might run into problems in reality due to this) and
> I think the various marshalled streams don't optimize on recurring URIs
> (no URI table I can detect for classes with the same annotation) so you
> will be consuming additional bandwidth (a lot?).
What I would say is that it's not part of the URL, but rather part of the
structure of the annotation string, which would break compatiblity with
arbitrary RMI applications when using the JRMP exporter. I.e. you might imagine
the following (incomplete) code used to compose the annotation.
public String getAnnotation() {
String[]urls = codebase.split(" ");
URL u = new URL( urls[0] );
URLClassLoader ld = new URLClassLoader( new URL[]{ u } );
URL ru = ld.getResource( "META-INF/PREFERRED.LIST" );
URLConnection uc = ru.openConnection();
DataInputStream ds = new DataInputStream( uc.openConnection() );
try {
byte[]data = new byte[uc.getContentLength()];
ds.readFully( data );
return codebase+"\n"+new String(data);
} finally {
ds.close();
}
}
The PREFERRED.LIST content would thus create a multi-line string of the form
http://some.code.base/file1.jar http://some.code.base/file2.jar
PreferredResources-Version: 1.0
Preferred: false
This, is just my initial thought of a trivial to implement solution for getting
the information into the codebase string. It might be more compatible to use
return codebase+" pref:/"+URLCoder.encode( new String(data) );
to make the additional information be recognizable for what it is.
The PreferredClassLoader would be changed to look at the annotation for the
defined separator ('\n' or " pref:/" or whatever) and use that PREFERRED.LIST
content instead of downloading one or more jars and extracting it.
Gregg Wonderly
Re: [jira] Updated: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by Mark Brouwer <ma...@cheiron.org>.
Gregg Wonderly wrote:
> Another enhancement I have been wanting to do is to make the
> RMIClassLoaderSPI string include the PREFERRED.LIST content. The
> encoding would be a bit tricky, depending on how much compatibility you
> want to maintain. I currently have a static method (with a permission
> check) in ClassLoading, called neverPrefer(String) which I use to set
> the "platform" that I am want to assert for my application. Anything
> that is "never preferred" will never force downloading of the codebase.
> It works, but is really a back door into the logic which could be driven
> with real data from the services preferences.
Hi Gregg,
I think I need a bit of help to understand the above completely and
therefore my remarks below might be completely irrelevant, nevertheless.
It seems you want to prevent from downloading JAR files that is driven
by the codebase annotation (the codebase annotation contains the encoded
PREFERRED.LIST [1]). I believe you want to prevent from downloading JAR
files due to limited bandwidth you have over WAN connections.
To me it looks like you want the client to be the discriminator whether
classes (and thus the download JAR file) should be downloaded and not
the server through the PREFERRED.LIST it provides in the codebase
annotation, why do you want to turn that around?
Without knowing whether I did understand you I'll stop for now.
[1] I guess the codebase annotation is getting rather large that way
(although RFC 2616 doesn't seem to place any a priori limit on the
length of a URI you might run into problems in reality due to this) and
I think the various marshalled streams don't optimize on recurring URIs
(no URI table I can detect for classes with the same annotation) so you
will be consuming additional bandwidth (a lot?).
--
Mark
Re: [jira] Updated: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by Gregg Wonderly <ge...@cox.net>.
Another enhancement I have been wanting to do is to make the RMIClassLoaderSPI
string include the PREFERRED.LIST content. The encoding would be a bit tricky,
depending on how much compatibility you want to maintain. I currently have a
static method (with a permission check) in ClassLoading, called
neverPrefer(String) which I use to set the "platform" that I am want to assert
for my application. Anything that is "never preferred" will never force
downloading of the codebase. It works, but is really a back door into the logic
which could be driven with real data from the services preferences.
Gregg Wonderly
Re: [jira] Updated: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by Gregg Wonderly <ge...@cox.net>.
Another enhancement I have been wanting to do is to make the RMIClassLoaderSPI
string include the PREFERRED.LIST content. The encoding would be a bit tricky,
depending on how much compatibility you want to maintain. I currently have a
static method (with a permission check) in ClassLoading, called
neverPrefer(String) which I use to set the "platform" that I am want to assert
for my application. Anything that is "never preferred" will never force
downloading of the codebase. It works, but is really a back door into the logic
which could be driven with real data from the services preferences.
Gregg Wonderly
[jira] Updated: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-24:
------------------------------
Component/s: com_sun_jini_tool
Affects Version/s: jtsk_2.1
> PreferredListGen can create illegal PREFERRED.LIST
> --------------------------------------------------
>
> Key: RIVER-24
> URL: https://issues.apache.org/jira/browse/RIVER-24
> Project: River
> Issue Type: Bug
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Priority: Minor
>
> {{com.sun.jini.tool.PreferredListGen}} can generate an illegal {{PREFERRED.LIST}} when no preferred default entry is specified and there are no individual preferred entries listed. In this case the utility should add an preferred default entry of {{false}} itself.
> One can also argue whether the semantics for {{net.jini.loader.pref.PreferredClassLoader}} {quote}A preferred list must contain either a default preferred entry or at least one named preferred entry{quote} are not a bit too strict given the fact that no preferred default entry means that all non-matching classes in the list are by default non-preferred, but I guess fixing {{PreferredListGen}} is easier than going for a specification change which might be logical anyway although not clear to me at this point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-24) PreferredListGen can create illegal
PREFERRED.LIST
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-24:
------------------------------
Fix Version/s: AR2
> PreferredListGen can create illegal PREFERRED.LIST
> --------------------------------------------------
>
> Key: RIVER-24
> URL: https://issues.apache.org/jira/browse/RIVER-24
> Project: River
> Issue Type: Bug
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Priority: Minor
> Fix For: AR2
>
>
> {{com.sun.jini.tool.PreferredListGen}} can generate an illegal {{PREFERRED.LIST}} when no preferred default entry is specified and there are no individual preferred entries listed. In this case the utility should add an preferred default entry of {{false}} itself.
> One can also argue whether the semantics for {{net.jini.loader.pref.PreferredClassLoader}} {quote}A preferred list must contain either a default preferred entry or at least one named preferred entry{quote} are not a bit too strict given the fact that no preferred default entry means that all non-matching classes in the list are by default non-preferred, but I guess fixing {{PreferredListGen}} is easier than going for a specification change which might be logical anyway although not clear to me at this point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.