Admin actions

[Dan Miser <dm...@wi.rr.com>]

I used the default org.apache.struts.actions.AddFormBeanAction action (and others) from 1.0b1 with success. However, it appears that this just makes the added FormBean available for the lifetime of the application. In other words, struts-config.xml is not updated to reflect the dynamic actions you can take in the actions package.

I almost have a graphical interface to the admin actions done, but in order to make it truly useful, I think automatic update of the config file needs to happen on unload (or even before). Is there a technical reason preventing this from happening, or is it just implemented this way for now? If it turns out to be an omission, I'll implement that as well to support the admin application.

One other thing: I noticed that with Tomcat it's possible to get a list of webapps defined for the engine. It appears that this is not a J2EE standard. Is that correct? If so, the admin classes and config file changes would need to happen on a per-webapp basis. I'd prefer to walk through the webapps and have a "struts-admin.war" file to do all of the administration. I just don't think that will be feasible in a portable manner. Any opinions or advice?

Thanks.
--
Dan Miser

Re: Admin actions

[Incze Lajos <in...@mail.matav.hu>]

On Sat, Mar 03, 2001 at 02:52:53PM +0100, Johan Compagner wrote:
> This would be very nice but remember that the struts-config.xml sits inside the war file
> And you don't have any control over it then. Some containers extract it (like tomcat)
> others work directly in it. And maybe other extract it to a internal database.
> 
> So what to update?
> 
> Maybe if struts build in functions that you store every setting to a database souce that is specified
> and struts wants (a) specifiek table(s) for it and that are updated when you do addForm ect ect.
> 
> johan
> 

I think the best solution would be to add some store/load interface
maybe with some defalut implementation. But the final solution would
be (at least in my opinion) to define a standard management interface
to struts (I mean to attach a JMX MBean) and in this case struts would be
open for various JMX agent implementations. This would result in the redesign
of the whole startup etc., so it is definitely an 1.X (X >= 1 ) issue,
but many other questions (datasources, chaches, resources etc.) would
gain a common framework.                                    incze

Re: Admin actions

[Johan Compagner <jc...@j-com.nl>]

This would be very nice but remember that the struts-config.xml sits inside the war file
And you don't have any control over it then. Some containers extract it (like tomcat)
others work directly in it. And maybe other extract it to a internal database.

So what to update?

Maybe if struts build in functions that you store every setting to a database souce that is specified
and struts wants (a) specifiek table(s) for it and that are updated when you do addForm ect ect.

johan

  ----- Original Message ----- 
  From: Dan Miser 
  To: struts-user@jakarta.apache.org 
  Sent: Saturday, March 03, 2001 7:42 AM
  Subject: Admin actions


  I used the default org.apache.struts.actions.AddFormBeanAction action (and others) from 1.0b1 with success. However, it appears that this just makes the added FormBean available for the lifetime of the application. In other words, struts-config.xml is not updated to reflect the dynamic actions you can take in the actions package.

  I almost have a graphical interface to the admin actions done, but in order to make it truly useful, I think automatic update of the config file needs to happen on unload (or even before). Is there a technical reason preventing this from happening, or is it just implemented this way for now? If it turns out to be an omission, I'll implement that as well to support the admin application.

  One other thing: I noticed that with Tomcat it's possible to get a list of webapps defined for the engine. It appears that this is not a J2EE standard. Is that correct? If so, the admin classes and config file changes would need to happen on a per-webapp basis. I'd prefer to walk through the webapps and have a "struts-admin.war" file to do all of the administration. I just don't think that will be feasible in a portable manner. Any opinions or advice?

  Thanks.
  --
  Dan Miser