I think we already have one:
http://issues.apache.org/jira/browse/MUSE-65
I will test our mini platform (2.1) this weekend to see if I can get this
functionality (startup on server startup) working. If so, we still don't
have an Axis2-based solution, but we'll have *a* solution. I think #1
should still be done as part of the capability initialization aspect of
the programming model - this code is not exposed to clients either unless
you really go out of your way to do so. #3 is handled by the fact that the
first and subsequent requests are put on hold until the router (and thus,
resource) initialization is finished.
Dan
"Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/17/2006
03:35:38 PM:
> Dan,
> Should I open up a JIRA issue so that we can track this requested
> functionality?
>
> To get around this issue, these are the steps we may have to take:
> 1) Create an "admin" resource that performs the initialization tasks in
> its capabilities. The resource will not be exposed to clients.
> 2) Create an external admin client that will automatically invoke the
> admin resource when app starts up. This will run all the initialization
> tasks before requests are made to the app. This is especially important
> if the tasks need to be run in a certain sequential order.
> 3) Customize further to block or return "system maintenance" messages to
> incoming requests until all initialization tasks are complete.
>
> Or, we may have to look into customizing either the Axis2 container or
> the web application server to force it to invoke the app upon startup,
> insteading of waiting for the first request to the Muse servlet app to
> begin initialization.
>
> Ideally, we do not want to do any of the above because it will further
> complicate deployment. Hopefully it can all be contained in the Muse app
> at some point.
> -Vinh
>
>
> -----Original Message-----
> From: Vinh Nguyen (vinguye2)
> Sent: Friday, November 17, 2006 9:23 AM
> To: [email protected]
> Subject: RE: app initialization tasks
>
> Thanks Dan,
> Yep, for the servlet initialization, I assumed that probably would be
> the case since many webservers usually don't load servlets until the
> first call to it. I was hoping the Axis2 had something different, but I
> understand that's outside of Muse's domain.
> -Vinh
>
>
> -----Original Message-----
> From: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 17, 2006 7:06 AM
> To: [email protected]
> Subject: RE: app initialization tasks
>
> > Putting these initialization tasks in a capability is risky because it
>
> > can possibly be called by a client if the capability is exposed
> > somehow.
>
> The capability methods won't be exposed unless you add them to the WSDL
> (with the exact same paramters and return type). Anyone who has authored
> a WSDL by hand knows that adding that much XML by accident is unlikely.
> ;) One could make the same argument for wherever you wish to put the
> initialization code ("what if it were exposed *somehow*?").
>
> > Also, I'm finding that when the application starts up, it doesn't
> > actually initialize any resources until the first client request is
> > sent to it...
>
> We found that even if the Axis2 servlet is initialized during server
> startup, it (Axis2) does not create its services (Muse) until the first
> request for them. We had the same problem with Axis 1.x. Thus, the first
> request takes longer, just like with JSPs.
>
> Dan
>
>
> "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/16/2006
> 09:50:07 PM:
>
> > Hi Dan,
> > The app initialization tasks may take some time, depending on what
> > needs to be done. For example, on startup:
> >
> > 1) It may check if external systems are alive, and gather some data
> > about those resources.
> > 2) It may contact other resources to let them know that this resource
> > is alive.
> > 3) It may initialize global objects that must exist before any
> > resources can access them (i.e. for collecting statistics).
> > 4) Must initialize one service group so that clients may starting
> > making requests to it.
> >
> > Putting these initialization tasks in a capability is risky because it
>
> > can possibly be called by a client if the capability is exposed
> somehow.
> >
> >
> > Also, I'm finding that when the application starts up, it doesn't
> > actually initialize any resources until the first client request is
> > sent to it. If this is the case, then the first request will always
> > take the longest. I'm not sure if this is a bug because I thought at
> > least one resource must automatically be initialized on app startup,
> > way before requests are handled.
> > -Vinh
> >
> >
> > -----Original Message-----
> > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, November 16, 2006 8:52 AM
> > To: [email protected]
> > Subject: Re: app initialization tasks
> >
> > I guess it depends on what your initialization tasks are. If you can
> > be a bit more specific about what you want to do, I can advise on
> > where to insert the code.
> >
> > Dan
> >
> >
> > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/15/2006
> > 09:19:40 PM:
> >
> > > Does Muse have a place where initialization tasks can be invoked
> > > upon app startup? So far, the samples have these tasks done in the
> > > capability classes, since the capabilities are intialized when the
> > > resources are initialized. But, I'm not sure if this is the proper
> > > place to be doing such tasks.
> > >
> > > Or, is this the responsibility of the Axis2 container to invoke the
> > > app's initialization classes, if Axis2 has such a feature?
> > > -Vinh
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
