What I'm trying to do seems to be a bit different. Our application server
has a very hard notion of control when it comes to class loaders - we have
our own security infrastructure. I could do the same thing as what the
JBoss example did, which is control our server from a component which is
using our scripts, but this is a rather poor integration from my perspective
- I would like us to be tightly integrated into the framework. The problem
is marrying the two worlds. Never an easy thing.
We have a bootstrap class which sucks in the enclosing java execution
environment and arranges it under our own class loader control. It's
essentially a glorified trampoline designed to create our own managed world
which includes all of the system boot class loaders and extensions as well -
we're pretty totalitarian about such things as one may imagine. The
bootstrap main turns around and calls the main of the actual class which is
representing the actual system. So all I had to do is get Smartfrog to call
our bootstrap main which will perform all of these machinations we require
which then calls the SFSystem.main(). Everything then proceeds "normally".
Smartfrog installs the component which controls our server lifecycle and
we're in heaven... Everyone seems happy at the moment.
I know there's interesting issues regarding class loader usage and security
managers between Smartfrog and us, but for the moment, things don't seem to
be too horrible... We'll see how far we can get with this hair brained
scheme.
What I did was the following. In the ProcessCompoundImpl, I modified
addProcessClassName to:
protected void addProcessClassName(Vector cmd, ComponentDescription cd)
throws Exception {
String pClass =
(String) cd.sfResolveHere(SmartFrogCoreKeys.SF_PROCESS_CLASS,
false);
if (pClass == null) {
pClass = (String) sfResolveHere(SmartFrogCoreKeys.SF_PROCESS_CLASS);
}
cmd.addElement(pClass);
}
This allows me to define the process class in the config. The advantage of
this method over the mechanisms you suggest is that I don't have to do this
for every process I'm spawning - I really only need to do this for the
processes which are running the application server, not every singe process.
It's compact and it's entirely in the configuration description. I don't
have to mess with .ini's, system properties which will be global, or much
else.
I dunno, I kind of like my solution as it seems to merge with the whole
existing Smartfrog metaphor for controlling processes already. It's also
fine grained in that the choice to do this or not is entirely dependent on
the configuration in question, not the way I started up the SF daemon. The
other mechanisms are incredibly complicated compared to this and seem to
require one to step outside of the bounds of the declarative configuration
scripts - something I find distasteful.
In any event, many thanks for the response. I'm looking forward to the new
release. Smartfrog rocks.
> -----Original Message-----
> From: smartfrog-developer-admin@... [mailto:smartfrog-
> developer-admin@...] On Behalf Of Guijarro, Julio
> Sent: Friday, May 27, 2005 3:45 AM
> To: Hal Hildebrand; smartfrog-developer@...
> Subject: RE: [Smartfrog-developer] correctly using sfProcessClass
>
> Hi Hal,
>
> I don't really understand what you are trying to do. Could you elaborate
> your question a bit more or give an example use case?
>
> In any case, I am going to try to give you some possible answers.
>
> A)
>
> In your example, you are trying to change the class that is used to
> start a ProcessCompound. There are several problems with your example
> code:
> - ProcessCompound implements the daemon and the subdaemons. Every
> ProcessCompound runs in its own JVM. Only the class used to start the
> new sub-daemon is read from sfProcessClass but not for the main daemon
> because this class is called using the command line. The method that
> reads the attribute and deploys a sub-daemon is: ProcessCompoundImpl.
> addNewProcessCompound().
> A new sub-daemon is created when a sfProcessName attribute is found in a
> description, but only if the named sub-daemon is not already deployed.
>
> - Because ProcessCompund is a JVM, it will read its configuration from
> the description file processcompound.sf merging it with the appropriate
> environment system properties:
> org.smartfrog.sfcore.processcompound.X
>
> So to change the process class used when deploying a SUB-process you
> will need to define
>
> org.smartfrog.sfcore.processcompound.sfProcessClass =
> oracle.foo.MyStartupWrapper;
>
> before the sub-process is created, for ex. before deploying your
> description:
> > sfConfig extends Compound {
> > // sfProcessClass "oracle.foo.MyStartupWrapper";
> > sfProcessName "bar";
> > MyTest extends Foo {
> > config-file "some/path";
> > }
> > }
>
>
> You can define that property adding it to the file default.ini
> org.smartfrog.sfcore.processcompound.sfProcessClass="com.oracle.wrapper"
>
> from java using
> System.setProperty("org.smartfrog.sfcore.processcompound.sfProcessClass"
> ,"oracle.foo.MyStartupWrapper");
>
> or to the system environment before starting your application command
> line.
>
> You cannot redefine it from inside a description.
>
> B)
> If what you are trying to do is to use SmartFrog (SF) inside another
> main class, you can start the daemon inside your own code in the
> following ways:
>
> 1. - Use the SFSystem.runConfigurationDescriptor() methods or
>
> 2.-
> // Set any required new system properties
> // to get a daemon with rmi registry
> System.setProperty("org.smartfrog.sfcore.processcompound.sfProcessName",
> "rootProcess");
> //ex.To define the iniFile that will be loaded
> System.setProperty("org.smartfrog.iniFile",iniFile);
> // ex.To define the default.sf file that will be loaded
> System.setProperty("org.smartfrog.sfcore.processcompound.sfDefault.sfDef
> ault",sfDefault);
> //Init system
> SFSystem.initSystem();
> //Deploy daemon
> ProcessCompound sfDaemon = SFProcess.deployProcessCompound(true);
> //"sfDaemon" now has a handle to the daemon.
> //You could for example now deploy a description using
> // Prim p = sfDaemon.sfCreateNewApp(name,componentDesc,null);
>
>
>
> In any case, I would not recommend you to do any tweaks with
> ProcessCompound unless you absolutely know what you are doing, the same
> applies to the classloader. Wrapping the SFClassLoader inside another
> classloader can have implications in the SF security model.
>
> I hope this answers your question. Let me know if it doesn't
>
> BTW, we just about to publish a new release in http://www.smartfrog.org
>
> Regards,
>
> Julio Guijarro
>
>
> > -----Original Message-----
> > From: smartfrog-developer-admin@...
> [mailto:smartfrog-
> > developer-admin@...] On Behalf Of Hal Hildebrand
> > Sent: 26 May 2005 15:43
> > To: smartfrog-developer@...
> > Subject: [Smartfrog-developer] correctly using sfProcessClass
> >
> > I need to wrap the Smartfrog system due to complicating class loader
> > issues.
> > I believe I can handle this simply if the new process spawned calls my
> > main() instead of the SFSystem.main(). I found the "sfProcessClass",
> but
> > I'm wondering how to override it, as it's an attribute of the
> > ProcessCompound.
> >
> > For example, in my test, I can do:
> >
> >
> > sfConfig extends Compound {
> > sfProcessClass "oracle.foo.MyStartupWrapper";
> > sfProcessName "bar";
> > MyTest extends Foo {
> > config-file "some/path";
> > }
> > }
> >
> > The sfProcessName will trigger the new process. However, the
> > sfProcessClass
> > in this scope does nothing to call the wrapper.
> >
> > I know this is a scoping issue, but I'm clueless as to how to express
> > this.
> > Sorry if this a silly question...
> >
> > Thanks in advance....
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your own
> > Applications - visit
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> > _______________________________________________
> > Smartfrog-developer mailing list
> > Smartfrog-developer@...
> > https://lists.sourceforge.net/lists/listinfo/smartfrog-developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=fad-ysdn-ostg-q22005
> _______________________________________________
> Smartfrog-developer mailing list
> Smartfrog-developer@...
> https://lists.sourceforge.net/lists/listinfo/smartfrog-developer
|