You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Christopher Kohlhaas <ko...@bonn.edu> on 2002/09/06 17:09:29 UTC
Fortress in a sandbox
I have successfully run fortress in a webstart and applet sandbox.
I'm developing an OS resource-management and scheduling application
(primary for schools and universities) and the server and also the
swing client are based on a fortress-container. The client should also
run in sandboxed environments.
To solve this I had to workaround the following problems
1. A Bug in ContextManager. I posted this issue in a Thread called
"Problem with asynchronous disposing" one month ago: The components
will not be disposed on containerManager.dispose() and this prevents
the VM from closing (if a service is using non daemon threads). I
could resolve this with the patch from Leo Sutic. Any reasons why this
patch hasn't been applied yet?
2. org.apache.excalibur.util.SystemUtil throws a SecurityException on
intitialization. Cause: The Sandbox prevents access to the
System.properties and to /proc/cpu-info (under linux). I resolved
this with to short modifications to TPCThreadManager and
ContextManager. In TPCThreadManager the m_processors variable is
initialized lazily so a call to SystemUtil is not necessary if the
processesors parameter is set. In the ContextManager the processors
value is passed to the TPCThreadManger if found on context. Patches
are appended.
3. org.apache.excalibur.source.impl.SourceResolverImpl throws
a SecurityExcetpion on contextualization. Cause:
( (File)m_context.get( "context-root" ) ).toURL()
The toURL method accesses System-variables (and the local file-system)
when trying to convert the file to an URL. The SourceResolverImpl
class is needed internally by the ContextManger to resolve the
locations of the configuration-filse. But with applets or webstart
clients these configurations are normally located on the server and
"context-root" should be something like
"http://myserver.mydomain:myport/mycontext" instead of File-Object.
I could only solve this by overriding initializeOwnComponentManager()
of ContextManager with an empty method and setting the configurations
manually with:
contextBuilder.setLoggerManagerConfiguration
contextBuilder.setContainerConfiguration
I would be pleased if you could apply the two minor patches + the one
from Leo, so that I could be in sync with the latest fortress versions.
On the other hand I could try to write a short documentation on using
fortress with clients (Issues with multithreading and swing,
sandboxing, ..) if your interested. Sandboxing should also be a
subject with restricted servlet containers.
Regards Christopher
[VOTE] RE: Fortress in a sandbox
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Christopher Kohlhaas [mailto:kohlhaas@bonn.edu]
>
> Leo Sutic [leo.sutic@inspireinfrastructure.com] wrote:
> >
> >
> > > From: Christopher Kohlhaas [mailto:kohlhaas@bonn.edu]
> > >
> > > 3. org.apache.excalibur.source.impl.SourceResolverImpl throws a
> > > SecurityExcetpion on contextualization. Cause:
> > >
> > > ( (File)m_context.get( "context-root" ) ).toURL()
> > >
> > > The toURL method accesses System-variables (and the local
> > > file-system) when trying to convert the file to an URL. The
> > > SourceResolverImpl class is needed internally by the
> > > ContextManger to resolve the locations of the
> > > configuration-filse. But with applets or webstart clients
> > > these configurations are normally located on the server and
> > > "context-root" should be something like
> > > "http://myserver.mydomain:myport/mycontext" instead of
> File-Object.
> >
> > Just guessing here but would changing the above to:
> >
> > if( m_context.get( "context-root" ) instanceof URL )
> > {
> > m_baseURL = (URL)m_context.get( "context-root" );
> > }
> > else
> > {
> > m_baseURL = ( (File)m_context.get( "context-root" )
> > ).toURL();
> > }
> >
> > work? We allow the context-root entry to be a URL as well.
>
> That should solve the problem but I don't know if there is a
> requirement that the context-root must be a File object. Are
> there any other components in avalon that use "context-root"?
Many, I think.
But as long as you stay away from them you should be fine. If you are
running
in a sandboxed environment they won't work anyway.
Right now we're only adding (reasonable) functionality to the Resolver.
Other
components have other context requirements, and are not tied to the
source
resolver's implementation.
With the new metadata/metainfo structures, the context key will be
scoped
to the component level, so you could give one component a File and
another
a URL.
Calling for vote on this change, outlined above. It is backwards
compatible.
I'm +1.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress in a sandbox
Posted by Christopher Kohlhaas <ko...@bonn.edu>.
Leo Sutic [leo.sutic@inspireinfrastructure.com] wrote:
>
>
> > From: Christopher Kohlhaas [mailto:kohlhaas@bonn.edu]
> >
> > 3. org.apache.excalibur.source.impl.SourceResolverImpl throws
> > a SecurityExcetpion on contextualization. Cause:
> >
> > ( (File)m_context.get( "context-root" ) ).toURL()
> >
> > The toURL method accesses System-variables (and the local
> > file-system) when trying to convert the file to an URL. The
> > SourceResolverImpl class is needed internally by the
> > ContextManger to resolve the locations of the
> > configuration-filse. But with applets or webstart clients
> > these configurations are normally located on the server and
> > "context-root" should be something like
> > "http://myserver.mydomain:myport/mycontext" instead of File-Object.
>
> Just guessing here but would changing the above to:
>
> if( m_context.get( "context-root" ) instanceof URL )
> {
> m_baseURL = (URL)m_context.get( "context-root" );
> }
> else
> {
> m_baseURL = ( (File)m_context.get( "context-root" )
> ).toURL();
> }
>
> work? We allow the context-root entry to be a URL as well.
That should solve the problem but I don't know if there is a
requirement that the context-root must be a File object. Are there any
other components in avalon that use "context-root"?
Christopher
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fortress in a sandbox
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Christopher Kohlhaas [mailto:kohlhaas@bonn.edu]
>
> Leo,
>
> the patch form you still uses the QueueElement which Berin
> removed from the event-package:
>
> replace
> QueueElement[] remainingElements =
> getCommandQueue().dequeueAll(); with
> Object[] remainingElements = getCommandQueue().dequeueAll();
Argh!
Fixed.
> Thanks for your help
You're welcome. Apologies for taking so long.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fortress in a sandbox
Posted by Christopher Kohlhaas <ko...@bonn.edu>.
Leo,
the patch form you still uses the QueueElement which Berin removed
from the event-package:
replace
QueueElement[] remainingElements = getCommandQueue().dequeueAll();
with
Object[] remainingElements = getCommandQueue().dequeueAll();
The other patches are O.K.
Thanks for your help
Christopher
Leo Sutic [leo.sutic@inspireinfrastructure.com] wrote:
> Christopher,
>
> I'm still having problems getting everything to build properly.
> Probably caused by my system setup. I have applied all patches.
> Could you please grab the files from CVS and verify that the
> patches have been applied correctly?
>
> /LS
>
> > From: Christopher Kohlhaas [mailto:kohlhaas@bonn.edu]
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fortress in a sandbox
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Christopher Kohlhaas [mailto:kohlhaas@bonn.edu]
>
> I would be pleased if you could apply the two minor patches +
> the one from Leo, so that I could be in sync with the latest
> fortress versions. On the other hand I could try to write a
> short documentation on using fortress with clients (Issues
> with multithreading and swing, sandboxing, ..) if your
> interested. Sandboxing should also be a subject with
> restricted servlet containers.
This sounds like my responsibility...
The reason I did not apply the Fortress patch was that I could
not get Fortress to build, because I could not get Instrument to
build, because ...
So I just plain gave up on it.
But it seems like I am the one who should get this fixed.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fortress in a sandbox
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Christopher Kohlhaas [mailto:kohlhaas@bonn.edu]
>
> 3. org.apache.excalibur.source.impl.SourceResolverImpl throws
> a SecurityExcetpion on contextualization. Cause:
>
> ( (File)m_context.get( "context-root" ) ).toURL()
>
> The toURL method accesses System-variables (and the local
> file-system) when trying to convert the file to an URL. The
> SourceResolverImpl class is needed internally by the
> ContextManger to resolve the locations of the
> configuration-filse. But with applets or webstart clients
> these configurations are normally located on the server and
> "context-root" should be something like
> "http://myserver.mydomain:myport/mycontext" instead of File-Object.
Just guessing here but would changing the above to:
if( m_context.get( "context-root" ) instanceof URL )
{
m_baseURL = (URL)m_context.get( "context-root" );
}
else
{
m_baseURL = ( (File)m_context.get( "context-root" )
).toURL();
}
work? We allow the context-root entry to be a URL as well.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fortress in a sandbox
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Christopher,
I'm still having problems getting everything to build properly.
Probably caused by my system setup. I have applied all patches.
Could you please grab the files from CVS and verify that the
patches have been applied correctly?
/LS
> From: Christopher Kohlhaas [mailto:kohlhaas@bonn.edu]
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>