Re: Looking for simple servlet-to-javaspace example

Gregg Wonderly wrote:
> Logan, Patrick wrote:
>> Thanks. That may come in handy sometime.
>>
>> At this point I specifically need to use a servlet running in Tomcat
>> installed in Jboss.
>
> Okay, as has been said here several different times, various J2EE
> appservers are
> less than friendly about how they manage codebases and permissions,
> because they
> are not tailored to allow "random" configurations to be deployed inside
> of them.
>
> So, there are specific things that you will need to address.  Using
> AllPermission to allow further investigation is probably okay.  But
> you'll need
> to understand what the limits are and how you can work within those, if
> security
> will be important to your deployment.
>
>> Ignoring Jboss for now, if I found some information on Jini for Tomcat
>> and/or the servlet specification generally, I should be able to
>> translate that into Jboss terms if necessary.
>
> One of the key businesses of Jini is the fact that the security manager
> must be
> enabled.  If you have this turned on in the JVM, and you can't control the
> permission settings assigned to Jini classes/instances, you will be
> plagued with
> errors that will frustrate you to no end.
>
>> Along the lines of what permissions are needed for a specific servlet to
>> basically lookup a javaspace and do writes and takes?
>
> The exact permissions are "none" to do writes and takes unless you've
> configured
> Outrigger's exporter's invocation layer factory with a permission.  If
> you did
> specify a permission for inbound calls, then a permission grant for each
> method
> that you want to allow access to, is required.  There are, of course other
> permissions required to use Jini's remote invocation infrastructure.  This
> includes endpoint related "socket" permissions, property access
> permissions, and
> other associated bits and pieces.  Last week, on the list, there was
> discussion
> about two different tools which allow you to "discover" what permissions
> are
> being required in a running system for the legs of code executed.
>
>> So this is somewhat of a step toward a "production" setup... Not wide
>> open, still as simple as possible, and focused on the servlet itself
>> rather than the entire tomcat installation.
>
> The other problematic situation is the annotations on exported objects.
> What
> I've found to work the best for me in these kinds of situations is to
> create a
> PreferredClassLoader that points at the URLs your service can be loaded
> from,
> and the annotation to return for that service.
>
> In your servlets initialization, you would create the
> PreferredClassLoader, and
> then create an instance of your service from that classLoader with
>
> PreferredClassLoader pcl = new PreferredClassLoader( urls,
>         getClass().getClassLoader(), annos, needDlPerm );
> Class cls = Class.forName( svcClassName, true, pcl );
> svc = cls.newInstance(...);
>

Just a note of clarification:

Basically, if you wish to ship some object out of the Servlet into
"Jini-land" and specifically to some part of Jini-land which will need
to download code for the object you shipped then you need to ensure the
object has a "codebase annotation".

A codebase annotation being a URL which can be used by the receiver to
obtain the code for the object you shipped.

Most (servlet) containers don't handle the configuration of a codebase
annotatio for a collection of classes particularly well.

What Gregg is describing above is one means by which to ensure things
get correctly annotated.

jiniservlet is another mechanism for doing the same sort of thing.
Specifically it uses a wrapper servlet which does the classloader magic
and, from there on delegates to the enclosed servlet.

There are two remaining twists:

(1) "Jini things" tend to make use of net.jini.config.* typically
wanting access to a configuration file for information about lookup
setup etc.  jiniservlet assumes you will put appropriate entries in
web.xml to point to that .config and provide an indication of which bit
of config should be passed to the enclosed servlet which should
implement JiniServlet so's it can be passed the config information at
init time.

(2) To make security work, we need our wrapped servlet to be logged in
as a particular Subject via LoginContext.  The login information to use
for this is also in the Jini .config file.  Note that setting this to
null, will have the servlet running with no LoginContext which in the
insecure case will be fine.

IMHO, jiniservlet is a pretty good way of solving the problem but it
assumes you know quite a lot - hopefully the above overview will help some.

Best,

Dan.

--------------------------------------------------------------------------
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]