Re: Class Server requests

Dave Brosius wrote:
> ----- Original Message -----
> From: "Gregg Wonderly" <[email protected]>
>
>> One the practices that I try and stress is to just use JARs.
>
>
> In production that's probably a reasonable idea. But it's a pain in the
> neck in the compile run debug loop.

I use Netbeans and thus ANT to drive my builds, and it's very quick to build a
jar file that way.

One of the more interesting things with the PerferredClassLoader and the
PREFERRED.LIST file is that you get more control over versioning which can help
eleminate some rebuilds.  I have several swing related classes that I continuous
refine and extend with varied capabilities during development.  If I create a
JAR with the preferred list including the associated packages, then my desktop
client application can use these classes, and my downloaded serviceUI component
that is embedded into the desktop application via downloaded code, can use a
different version because the preferred classloader will segregate the two
codesources automatically.

> My class server is part of the service installer itself. It works correctly
> whether the classes are in the file system or a jar, because it's based on
> getResourceAsStream.

Again, this issue is about how URLClassLoader formulates resource URIs given the
URL(s) that it has view of.  As Dan pointed out, there are, in fact standards
that control these behaviors.  The web servers actually do the work of adding
the '/' to an invalid URI and return it with a redirect for the browser to then
use.  This is behavior that has been around forever, and because it's a hidden
'hack' in the server implementations, people are not (and probably shouldn't be
as users) aware of the issue.  As a developer, it, unfortuately is an issue you
have to be aware of.

 > It would be nice if Jini worked the same way with
> regards to the url. The thing at first blush i dislike about about jini,  and
> admittedly i'm a neebie - and no one likes a cranky newbie :), is jini's
> proclivity for having so many moving parts (which is probably rmi's
> fault as well).

All the moving parts are the complicating factors.  They provide opportunity for
choice and variation that is important to many applications though.  The web
page that Mark pointed at list several solutions that create more focused
solutions for particular domains, or at least assert specific implementations
which hide or remove some moving parts which do not need to vary.

The platform, having those moving parts, is perhaps the thing that makes many
people frustrated.  So many other SOA focused solutions come with far fewer
choices of parts to attach.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]