[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [equinox-dev] OSGi for Server-side...

I like the idea too.
I think that you wouldn't have to go as far as replacing java.net.URL.

Perhaps if you just just replaced the constructor calls with calls to a
URLFactory (see patch)
e.g. At load time URL myURL = new URL("xxx") is rewritten as URL myURL =
URLFactory.createURL("xxx").

In this way the URL remains portable between the ClassLoaders (although
the construction isn't)

--

This would have to be integrated pretty low-down. (EclipseClassLoader(?)
or deeper)
Another issue to consider is that we'd need a byte-code weaver available
at the level of the System bundle.
I'd imagine that this might impact load time and there might be some
pretty serious security repercussions but its worth a look. Very cool.

-Simon


-----Original Message-----
From: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of BJ Hargrave
Sent: Tuesday, October 25, 2005 2:23 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] OSGi for Server-side...

Sounds neat. The main issue I see is the exchange of URL objects with
something on the parent classpath (eg. URLClassLoader) which will result
in an error if each framework instance generates its own version of the
URL class for its bundles. This is a general problem with creating
private versions of base classes.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance hargrave@xxxxxxxxxx
Office: +1 407 849 9117 Mobile: +1 386 848 3788



Olivier Gruber/Watson/IBM@IBMUS
Sent by: equinox-dev-bounces@xxxxxxxxxxx
2005-10-25 10:22 AM
Please respond to
Equinox development mailing list


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc

Subject
Re: [equinox-dev] OSGi for Server-side...







Just as an idea and testing the reactions... :-) 

We can look at solving the problem... or we can look at avoiding the 
problem. 
One possible way to avoid the problem is not use the JRE URL subsystem. 
I don't have all the details worked out, but just the overall idea... 

For this to work, we would have to weave/refactor class files at 
deployment or loading time. 
We would need our own URL framework that is binary compatible with the
JRE 
one, 
or with a straight mapping (like straightforward refactoring). This
means 
that no one would be 
using the JRE URL framework, although they think they are. 

This would always allow us to have control over the 
URLStreamHandlerFactory 
It would be our own. For all code executing within the OSGi environment 
(bundles). 
This would require having some access to the other jars as well... so
that 
they can be 
woven as well. Only the JRE rt.jar and the like would be left alone. 

Any reaction? 
Do we have other similar issues that could be addressed through bytecode

weaving? 
  
Best regards, 

Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center





Thomas Watson/Austin/IBM@IBMUS 
Sent by: equinox-dev-bounces@xxxxxxxxxxx 
10/25/2005 03:46 PM 
Please respond to Equinox development mailing list 
        
        To:        Equinox development mailing list 
<equinox-dev@xxxxxxxxxxx> 
        cc:         
        Subject:        Re: [equinox-dev] OSGi for Server-side...




> On Tuesday 25 October 2005 14:28, Kaegi, Simon wrote:
> > 1) Running when someone else has set the URL and URLConnection 
singletons
> > needed by the URLHandlerService - patched but needs polishing
> 
> Big problem without co-operation from the "conflictee". However, more 
> importantly, how about when loading many Equinox instances in the same

JVM, 
> and resolving the URLHandler issue across those... Richard hall is 
sketching 
> on this problem, and I think collaboration is a good thing here.

Yes collaboration is good here.  I have spent time discussing this
problem 

and possible solutions with Richard Hall.  The current solution Richard 
is implementing in Felix is likely the best we can do for this
situation. 
Unfortunately the solutions is pretty complex and I would definitely
only 
want 
to enable it if more than one framework is running in the VM. 

There is still a problem with Richard's solution, because it still
assumes 

the Framework can set the singleton URLStreamHandlerFactory for the VM.
In 

Simon's case we want the core framework to still function 
when setting the URLStreamHandlerFactory fails and therefore the 
URLHandlerService is unavailable. 

> > 2) Using the Conditional Permission Admin Service when someone else 
has set
> > the SecurityManager. - avoided this so far but it's an important
> > consideration in some server-side environments - without control of 
the
> > SecurityManager we lose the capability to do postponed decisions (?)
- 
What
> > are the repercussions? Is there something we can do about it?
> 
> Two things comes to mind;
> 
>  1. User can specify the SecurityManager from commandline, and if an 
> application doesn't do the selective setting of the SM, then that is a

bug. 
> If you can convince the deployment team that the SM from Equinox does
a 
> better job than the "default" one, then mission accompilshed.
(provided 
the 
> technical difficulties to have the SM separated out bla bla bla...)

Here are the technical difficulties: 
- The SecurityManager specified at commandline must be available on the 
application classloader or its parent classloaders (i.e. ext, boot). 
When Equinox is launched the code for the framework is loaded with a 
separate 
classloader (not the app classloader) so it's security manager cannot 
be specified at commandline. 
- Moving the FrameworkSecurityManager out of the core framework.  This
has 

issues because it uses some core OSGi interfaces 
(e.g. org.osgi.service.condpermadmin.Condition).  These classes would
also 

have to be separated from the framework.  This is not good situation
IMO. 

>  2. If the deployer decides to stick with the default security, 
> shouldn't this 
> "just work" for Equinox as well?? Not sure, what to put in the
security 
> policy codebase URLs, but shouldn't be impossible. 

OSGi actually assumes complete control here.  Each bundle in OSGi has a 
single 
ProtectionDomain.  This ProtectionDomain is controlled by the Framework 
and dictates what permissions a class loaded from a bundle will have.
When 

the Framework defines a class it specifies the correct bundle 
ProtectionDomain 
depending on what bundle the class bytes came form.  The bundle 
ProtectionDomain uses a policy to assign permissions based on input from

the 
PermissionAdmin and ConditionalPermissionAdmin services defined by the 
OSGi 
specification.  No other policy is used to assign permissions to a 
bundle's 
ProtectionDomain.  Regardless of what SecurityManager is used the 
ProtectionDomain for the Class being check is what defines the
permissions 

a particular class gets granted. 

The only reason a "special" FrameworkSecurityManager is needed is to 
process 
postponed conditions correctly.  In Equinox we detect this situation and

treat all postponed conditions as non-postponed conditions if the 
SecurityManager is not our own "special" implementation.  What we have
to 
decide is if we care about postponed conditions in the scenarios we 
are trying to run in. 

> 
> Cheers
> Niclas 

Tom.
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev 
  
       This message may contain privileged and/or confidential information.  If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.  Thank you.