RE: [OS-webwork] Programmatic configuration
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED] Why is an interface needed here? I thought this was just a singleton thingy which the app can query. Are there several implementation possibilities, and if so, why? Probably not needed. I just created them to keep me sane. 2 Some configuration bundle containing settings that have been loaded. This mostly just have get/set methods. This is ProgrammableConfiguration. It also has a reload() method to tell it to get the new configuration from 3, below, and buildRuntimeConfiguration(), which can be thought of as a save method which tells it to generate the runtime configuration from the hierarchical configuration structures which can be programmatically tweaked. IMHO that's backwards. This thing should be a stupid data holder, nothing more. It's 3) that determines when the data should be reloaded. But you want to give the API users one thing to interact with, that being the ConfigurationManager. It's already got to know how to build the runtime configuration from the programmatic configuration. This is ConfigurationFactory, which can have one object implementing Configuration registered with it (by default this is DefaultConfiguration). That's backwards. It should be possible to have N implementations, one for each kind of configuration, simultaneously. Remember, an application may be created by merging several subapps, and each subapp may have its own way to read configuration. The total app must be able to handle this. With only One way to read configuration that is not possible. That's a good point. We'll take it up with Patrick... I'll plead his starting that. :-) When ConfigurationManager.reload() is called, it calls ConfigurationFactory.getConfiguration().init(this) to tell the Configuration to load its configuration and register the configuration params with the ProgrammableConfiguration it's passed (ConfigurationManager). DefaultConfiguration starts at init() and loads the xwork.xml file, parsing through it building up data structures and registering them with the ProgrammableConfiguration it is passed. This is backwards, because how would you know when to call reload()? The only entity which can know this are the individual ConfigurationFactories. Okay. We can look at how this should be implemented. I still think the user needs to be able to trigger this programmatically, though, like a refresh my config. It then becomes possible to configure the app at runtime without using 3 at all, since 2 can be created programmatically. Instances of 2 can also be serialized and sent around in a system without much trouble. Hadn't thought of sending serialized configuration objects around. Why would you want to do this? Why not? :-) Example: using JMX to configure. Using a Java client to configure. Storing serialized configuration in a database. Etc. etc. Right now what happens is that ConfigurationManager has a static instance which is initialized at class initialization and calls reload to get the Configuration from the ConfigurationFactory. See above. That's the wrong approach. Do you see why? I see your points, but I still think there are some details to be worked out. Check out the code and let me know how you think it should change. Jason --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote: Why is an interface needed here? I thought this was just a singleton thingy which the app can query. Are there several implementation possibilities, and if so, why? Probably not needed. I just created them to keep me sane. Ok. Then I'd propose that it's removed. :-) Let's keep simple things simple. Sometimes you want flexibility and strategy possibilities, and sometimes you want rigidity and stability. This is a case of the latter I think. IMHO that's backwards. This thing should be a stupid data holder, nothing more. It's 3) that determines when the data should be reloaded. But you want to give the API users one thing to interact with, that being the ConfigurationManager. It's already got to know how to build the runtime configuration from the programmatic configuration. Can't this be done when a configuration bundle is registered with the ConfigurationManager? Or, lazily upon access? Should work just fine as far as I can tell. That's backwards. It should be possible to have N implementations, one for each kind of configuration, simultaneously. Remember, an application may be created by merging several subapps, and each subapp may have its own way to read configuration. The total app must be able to handle this. With only One way to read configuration that is not possible. That's a good point. We'll take it up with Patrick... I'll plead his starting that. :-) In general, this app created from subapps is something that needs to be considered in all aspects. WebWork was monolithic in this sense, and it'd be good if we can move away from that. As I've already noted a couple of times, I think in the future it will be more common to build webapps from smaller webapps, e.g. through portlets. This is backwards, because how would you know when to call reload()? The only entity which can know this are the individual ConfigurationFactories. Okay. We can look at how this should be implemented. I still think the user needs to be able to trigger this programmatically, though, like a refresh my config. Ok, how about this then: have the configuration loaders be able to register with the configuration API, and on refresh simply give them a callback. That way the bundles (which should be *stupid*) does not contain logic that understand refreshing. Then, any loaders that can reload can remove the previous configuration and add a new one. I see your points, but I still think there are some details to be worked out. Check out the code and let me know how you think it should change. There's always details to work out :-) I'll check it out. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] ETA of WW 2.0
On Wed, Feb 26, 2003 at 07:27:37AM -0800, Jason Carreira wrote: Unless you're intimately familiar with the inner workings of Xwork (i.e. you're Patrick or myself :-)), then I would suggest going with 1.3 for now. If you don't need to start coding for a month or two, then it's probably worth using WW2, though. We've just started coding some new features using WW here, and we're using WW 1.3 because it's more stable, tested, and documented. We'll be starting coding in a month or so - so I guess it's 1.3 for now :) How much work would it be to port a 1.3 WW application to WW 2.0 when 2.0 is stable? Hard question, I know - but have you thought about providing some kind of 'migration guidelines'? //Anders -Original Message- From: Scott Farquhar [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 8:27 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] ETA of WW 2.0 Mate - I'd go for 1.3 at the moment. Or even CVS HEAD. I'm don't have any real say in when 2.0 is released, but I would say that 1.3 is a safer bet. It is already tested in a lot of different servlet containers - JIRA runs on Tomcat, Resin, Jetty, Orion, Weblogic. Cheers, Scott Anders Engström wrote: I've been surfing the Wiki looking for information, but didn't find anything. So - is there an ETA for WebWork 2.0? We would like to use WW 2.0 in our product - but depending on the release date we might have to use 1.3 instead. //Anders -- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support --- Need a simple, powerful way to track and manage issues? Try JIRA - http://www.atlassian.com/software/jira --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork -- |===| |Anders Engström| |[EMAIL PROTECTED]| |http://www.gnejs.net | |===| |Your mind is like an umbrella. | |It doesn't work unless you open it.| | /Frank Zappa | |===| pgp0.pgp Description: PGP signature
Re: [OS-webwork] ETA of WW 2.0
We'll be starting coding in a month or so - so I guess it's 1.3 for now ww2 is cool, check it out, give it a whirl, when you see things that aren't there, add them ;) Meeting minutes are in the Wiki and give a pretty good idea of the direction to move in. --Erik --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Commands implemented
Keep up the good work guys. This kind of email explaining a new feature should go almost as is in the doc. Just an idea about the interface to stay or to be removed. Could the interface be changed to contain no method. It becomes just a tagging interface much like java.io.Serializable. Cheers. ___ Francois Beauregard, b.ing. Vice-president Recherche et developpement Pyxis Technologies www.pyxis-tech.com T : (450) 681-9094, poste 102 F : (450) 681-5758 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Carreira Sent: February 27, 2003 2:51 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Commands implemented I've just checked in the command code to xwork. It allows you to do this: action name=commandTest class=com.opensymphony.xwork.SimpleAction param name=foo123/param result name=error type=chain param name=actionNamebar/param /result interceptor-ref name=static-params/ command name=myCommand method=commandMethod param name=bar456/param result name=success type=chain param name=actionNamefoo/param /result interceptor-ref name=logger/ /command /action The command here creates a new alias in the runtime configuration and inherits properties from the enclosing action. It will also call the supplied method. Actions are not required to supply a method, although they can as well. If no method is supplied for an Action, it defaults to calling action.execute(). For now Actions must still implement this interface, although this can easily be removed and the object can be cast to Action before calling execute(). This should be the last major change to configuration. The only other thing I want to do, and I just thought of this while I was writing this, is to make name optional on the Action and have it not create a runtime ActionConfig for the action itself if there is no name, although you could have several commands underneath the action which would be configured. I also refactored the names of the config classes. Configuration - ConfigurationProvider ConfigurationFactory - ConfigurationProviderFactory DefaultConfiguration - DefaultConfigurationProvider SimpleConfiguration - SimpleConfigurationProvider I've also created 2 new classes in the ActionConfig class hierarchy to support commands: ActionCommand ^ | ActionConfig ^ | HierarchicalActionConfig ActionCommand has: methodName Interceptors Parameters Results resultParameters ActionConfig adds: Class clazz TypeConverter HierarchicalActionConfig adds: Commands ActionConfig is the runtime datastructure, the other 2 are used on the programmatic side. Ok, so go ahead and start making fun of my class naming, but you'd better have some better ideas :-) Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Programmatic configuration
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 27, 2003 3:31 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote:
Why is an interface needed here? I thought this was just a
singleton
thingy which the app can query. Are there several implementation
possibilities, and if so, why?
Probably not needed. I just created them to keep me sane.
Ok. Then I'd propose that it's removed. :-) Let's keep
simple things simple. Sometimes you want flexibility and
strategy possibilities, and
sometimes you want rigidity and stability. This is a case of
the latter
I think.
Here's what I'm thinking:
1) Remove the ManageableConfiguration Interface (was ProgrammableConfiguration) - this
is just ConfigurationManager
2) Make RuntimeConfiguration into a class and move that part of ConfigurationManager
over to it
There will always be only one RuntimeConfiguration which is created by
ConfigurationManager from the configuration structures it holds which are initialized
by the ConfigurationProviders
But you want to give the API users one thing to interact with, that
being the ConfigurationManager. It's already got to know
how to build
the runtime configuration from the programmatic configuration.
Can't this be done when a configuration bundle is registered with the
ConfigurationManager? Or, lazily upon access? Should work
just fine as
far as I can tell.
The problem here is the case of programmatic configuration. If someone writes code to
call into the ConfigurationManager to change the configs, then they need to be able to
generate the runtime configuration from it.
That's backwards. It should be possible to have N implementations,
one for each kind of configuration, simultaneously. Remember, an
application may be created by merging several subapps, and each
subapp may have its own way to read configuration. The
total app must
be able to handle this. With only One way to read
configuration that
is not possible.
That's a good point. We'll take it up with Patrick... I'll
plead his
starting that. :-)
In general, this app created from subapps is something that
needs to
be considered in all aspects. WebWork was monolithic in this
sense, and
it'd be good if we can move away from that. As I've already noted a
couple of times, I think in the future it will be more common
to build
webapps from smaller webapps, e.g. through portlets.
I agree. How would the sub-apps configuration get loaded? How are they packaged?
This is backwards, because how would you know when to call
reload()? The only entity which can know this are the individual
ConfigurationFactories.
Okay. We can look at how this should be implemented. I
still think the
user needs to be able to trigger this programmatically,
though, like a
refresh my config.
Ok, how about this then: have the configuration loaders be able to
register with the configuration API, and on refresh simply
give them a
callback. That way the bundles (which should be *stupid*) does not
contain logic that understand refreshing. Then, any loaders
that can
reload can remove the previous configuration and add a new one.
This is what it does now. Here's the reload() method on ConfigurationManager:
public synchronized void reload() throws ConfigurationException {
packageContexts.clear();
ConfigurationProvider config = ConfigurationProviderFactory.getConfig();
config.init(this);
buildRuntimeConfiguration();
}
This, in order, clears the current data structure, gets the ConfigurationProvider
(which could be changed to a List of ConfigurationProviders) and tells it (them) to
init, passing it this so that they can call back to the ConfigurationManager to
register configurations, then it builds the runtime configuration from the registered
configurations.
I see your points, but I still think there are some details to be
worked out. Check out the code and let me know how you
think it should
change.
There's always details to work out :-) I'll check it out.
/Rickard
Jason
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote:
Here's what I'm thinking:
1) Remove the ManageableConfiguration Interface (was
ProgrammableConfiguration) - this is just ConfigurationManager 2)
Make RuntimeConfiguration into a class and move that part of
ConfigurationManager over to it
There will always be only one RuntimeConfiguration which is created
by ConfigurationManager from the configuration structures it holds
which are initialized by the ConfigurationProviders
I'm having a little trouble seeing exactly what it would lead to, so
hard to comment on. Just do it, and I'll look at the end result.
Can't this be done when a configuration bundle is registered with
the ConfigurationManager? Or, lazily upon access? Should work just
fine as far as I can tell.
The problem here is the case of programmatic configuration. If
someone writes code to call into the ConfigurationManager to change
the configs, then they need to be able to generate the runtime
configuration from it.
If someone adds/removes configuration - clear cache. When a value is
needed - either rebuild the entire cache or just the cache for that value.
In general, this app created from subapps is something that needs
to be considered in all aspects. WebWork was monolithic in this
sense, and it'd be good if we can move away from that. As I've
already noted a couple of times, I think in the future it will be
more common to build webapps from smaller webapps, e.g. through
portlets.
I agree. How would the sub-apps configuration get loaded? How are
they packaged?
That's a good question. Are there any other frameworks we can look at
for inspiration here?
Ok, how about this then: have the configuration loaders be able to
register with the configuration API, and on refresh simply give
them a callback. That way the bundles (which should be *stupid*)
does not contain logic that understand refreshing. Then, any
loaders that can reload can remove the previous configuration and
add a new one.
This is what it does now. Here's the reload() method on
ConfigurationManager:
public synchronized void reload() throws ConfigurationException {
packageContexts.clear(); ConfigurationProvider config =
ConfigurationProviderFactory.getConfig(); config.init(this);
buildRuntimeConfiguration(); }
This, in order, clears the current data structure, gets the
ConfigurationProvider (which could be changed to a List of
ConfigurationProviders) and tells it (them) to init, passing it this
so that they can call back to the ConfigurationManager to register
configurations, then it builds the runtime configuration from the
registered configurations.
Ok. I'll have to look at the code to see all the implications of this I
think.
/Rickard
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Programmatic configuration
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 10:33 AM The problem here is the case of programmatic configuration. If someone writes code to call into the ConfigurationManager to change the configs, then they need to be able to generate the runtime configuration from it. If someone adds/removes configuration - clear cache. When a value is needed - either rebuild the entire cache or just the cache for that value. I was thinking it would be good to let them be able to do a series of modifications to the programmatic configuration side then commit them all at once. The runtime configuration is not really a cache, it's another set of data structures that is built from the first set. I agree. How would the sub-apps configuration get loaded? How are they packaged? That's a good question. Are there any other frameworks we can look at for inspiration here? Don't know. I was hoping your experience with Portals and Portlets would enlighten us :-) Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote: Why is an interface needed here? I thought this was just a singleton thingy which the app can query. Are there several implementation possibilities, and if so, why? Probably not needed. I just created them to keep me sane. Ok. Then I'd propose that it's removed. :-) Let's keep simple things simple. Sometimes you want flexibility and strategy possibilities, and sometimes you want rigidity and stability. This is a case of the latter I think. Interfaces are nice to make mock objects of. Let's keep it around, helps with unit testing I believe :) -Pat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Programmatic configuration
Ok. Then I'd propose that it's removed. :-) Let's keep simple things simple. Sometimes you want flexibility and strategy possibilities, and sometimes you want rigidity and stability. This is a case of the latter I think. Interfaces are nice to make mock objects of. Let's keep it around, helps with unit testing I believe :) -Pat ConfigurationManager is just a simple object. There's no overhead in just using it directly. Check out SimpleConfigurationProvider, which does just this. Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Programmatic configuration
In general, this app created from subapps is something that needs to be considered in all aspects. WebWork was monolithic in this sense, and it'd be good if we can move away from that. As I've already noted a couple of times, I think in the future it will be more common to build webapps from smaller webapps, e.g. through portlets. I agree. How would the sub-apps configuration get loaded? How are they packaged? That's a good question. Are there any other frameworks we can look at for inspiration here? The struts model for doing this is to: 1. create a separate struts-config.xml file for each subapp. For example, struts-config.xml, struts-config-admin.xml, struts-config-user.xml. 2. register each subapp via web.xml init-param param-nameconfig/param-name param-value/WEB-INF/struts-config.xml/param-value /init-param init-param param-nameconfig/admin/param-name param-value/WEB-INF/struts-config-admin.xml/param-value /init-param init-param param-nameconfig/voice/param-name param-value/WEB-INF/struts-config-voice.xml/param-value /init-param The main challenge I saw to this model was having a shared JSP space. The sub-application developers need to coordinate with one another to ensure that there aren't any conflicts in JSP path selection. For example, if one project wants to place its views in /WEB-INF/jsp/, then none of the other subprojects should place their views there. The same is true of resources such as images and js files, etc. Using velocity views was a lot cleaner as you could just dump a jar file into the /WEB-INF/lib/ directory and be done with it. However, velocity is a second class citizen in the struts world. Here's a suggested solution: * Each application should have its own xwork.xml file that is placed at the root level of the project. For example, com/indigoegg/myproject/xwork.xml for a project with a root of com.indigoegg.myproject * Allow xwork.xml to include other xml files via the follow (or similar) construct: package namespace=subapp subapp name=com.indigoegg.myproject/ /package * These included configuration files should be able to to, in turn call other configuration files to allow creation of applications by composition. * The subapp need only be aware of its defined namespace. For example, if an Action from the subapp calls ActionInvocation invocation = new ActionInvocation(/, login) ; They should get a reference to /subapp/login essentially. * In addition to the subapp tag, there should also be an include tag, peered with package, to allow developers to break up large xwork.xml files. -- Matt Ho Principal Indigo Egg, Inc. http://www.indigoegg.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] DynamicActions
Title: Message I want to use Webwork for a project and I'm having trouble finding some similar capability to Struts DynamicActionForms. I would like to have an Action object be able to access all fields from a form submission, not only the ones that have specific beanmethods. Is there a way to accomplish this? Some way of accessing the form used? Thanks, - John Benediktsson Software Engineer Agari Mediaware, Inc. 3340 Ocean Park Blvd. Suite 3070 Santa Monica, CA 90405 310-396-0810 x107 www.agari.com
RE: [OS-webwork] DynamicActions
Title: Message Check out the ParameterAware Interface in WW 1.3. This does what you're looking for. -Original Message-From: John Benediktsson [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 2:44 PMTo: [EMAIL PROTECTED]Subject: [OS-webwork] DynamicActions I want to use Webwork for a project and I'm having trouble finding some similar capability to Struts DynamicActionForms. I would like to have an Action object be able to access all fields from a form submission, not only the ones that have specific beanmethods. Is there a way to accomplish this? Some way of accessing the form used? Thanks, - John Benediktsson Software Engineer Agari Mediaware, Inc. 3340 Ocean Park Blvd. Suite 3070 Santa Monica, CA 90405 310-396-0810 x107 www.agari.com
