Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
On Mon, 29 Nov 2004 22:29:35 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
Thanks, Craig. I think there might be a misunderstanding. See within.
On Mon, 29 Nov 2004 18:32:06 -0800, Craig McClanahan [EMAIL PROTECTED]
wrote:
On Mon, 29 Nov 2004 17:36:09 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
I am not sure what you mean by transparently swap. IoC requires
fairly extensive configuration for this transparency. I don't see
what is transparent about the IoC setting of an implementation at all.
Am I missing something?
If I use create at startup, I'm going to get my instance of a
service class configured with its own dependencies. For example, if
I'm using constructor injection:
public class Foo {
public Foo(Bar bar) {
this.bar = bar;
}
... code that uses bar ...
}
So far the comparison is this: IoC creates the implementation of the
Bar class with configuration and so on at startup. There has to be a
class somewhere, of course, which is the implementation that IoC plugs
into the app. HaD just starts with this class sitting where the
implementation class is supposed to be. Your class might be called
BarTypeXImpl. My class is always called BarImpl merely.
So far, all HaD requires none of the considerable coding overhead
required by dependancy injection. (I hope I don't sound negative
about lightweight, IoC containers, because I am not. Just looking
around here.)
Now, if you want to change the implementation class to, say,
BarTypeYImpl, you have to change the configuration and restart the
application. I just drop call this new implementation by the same
name (BarImpl) and drop it in place of the old implementation.
Then, I call BarHotFactory.loadBarImpl(). The result is that the Bar
class reference and the Bar classloader class reference are changed to
the new BarImpl. There will be no straggler references to cause
garbage collection problems, I now see.
Now, in your scheme you upgrade the Bar class (of course, setting up a
new class loader to contain it).
This only happens when there is a change. The IoC has also to do something.
But what you haven't done is
notified my Foo instance that you should somehow update the private
bar variable to point at a new instance based on the new class
(possibly having to do some sort of state transfer as well) ... it
continues to use the old one -- with the side effect that the old one
will not get garbage collected either.
This is, I think, mistaken. Isn't it? The class reference content
has changed. The reference Bar has to a classloader and the reference
Bar has to a class remains the same but points to a different entity.
Right?
Only partly. The renference to the old version of Bar remains in
existence fo the lifetime of the Foo instance that contains it,
until the Foo instance is told to release the old reference.
So, when Foo no longer uses Bar, Bar will be garbage
collected. The sole result that is of significance is that Bar has
been updated but the Bar in Foo is using the old version. Right? All
new Bars created in Foo will be the new version. All new Foos will
create new Bars. Right?
Yes, but so what? It's the existing Foos that will be broken by your change.
Updating the bytecodes that your factory method returns for a
getInstance() method for a Bar class has nothing to do with any
existing object that uses a Bar object as a service, and maintains a
reference to that instance.
You could get away with what you're after if Java supported
ClassLoader.unloacClass() -- but it doesn't for valid technical
reasons.
If we want all client Foos to use the newest and greatest Bars, we can
do so by restarting the application. This is the same thing we have
to do with IoC, or we can get a solution for HaD that wil mirror any
solution for IoC. So, the sole problem is that HaD can do things that
IoC cannot do. You don't have to do that. Correct?
Restarting the application works (for this particular scenario) ...
but it makes any attempt to pretend to do hot deploy pretty
pointless - the newly restarted app will already pick up the new
version of your implementation class, without any special attention on
the part of the app itself. There is no need, if you're willing to
restart the app, to do anything like this.
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
On Mon, 29 Nov 2004 10:34:13 -0800 (PST), David Graham [EMAIL PROTECTED] wrote: --- Craig McClanahan [EMAIL PROTECTED] wrote: I agree with Don's assessment, but wanted to add an FYI note -- Shale does zero-config for #3 (because the mapping between a JSP page and the corresponding ViewController is implicit), and doesn't require #1 unless you need it for doing Commons Validator stuff. Simpler is definitely better. But is adding yet another framework to Struts simplifying anything for the user or just for us developers? If we add Spring, we would need to know the following to write a Struts webapp: 1. struts-config.xml 2. validator-rules.xml 3. spring.xml (or whatever they call the config file) 4. possibly tiles-config.xml 5. possibly jsf config files How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps. David The current Shale version of struts-mailreader requires *one* configuration file (WEB-INF/faces-config.xml), and adding client side validation and/or Tiles *might* add one for each (although that is not a given). For example, Spring config files are only needed if you want to use Spring in addition to JSF -- if you are satisfied with the setter injection support that JSF already provides, you don't need Spring for basic IoC functionality. Tell me again why it is ok for Stuts 1.x to require more configuration files than Shale does :-) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
-Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: 29 November 2004 01:55 To: Struts Developers List; Dakota Jack Subject: Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea] On Sun, 28 Nov 2004 15:36:27 -0800, Dakota Jack [EMAIL PROTECTED] wrote: [snip] With hot deploy, instead of switching the implementation and the name of the implementation class, e.g. ColonSeparatedMovieFinder for DatabaseMovieFinder, you just have an implementation called MovieFinderImplementation (or whatever you want, e.g. X) and a MovieFinderImplementationHotFactory for getting object instance implementations of the MovieFinder interfaces. Conceivably, in fact, you can give people differing implementations with the same name by simply putting them in different directories: no problem. This means that the code can be dynamic and alterable at will and that there need be no changes anywhere if you don't want there to be other than dumping the new MovieFinderImplemenation.class in some directory somewhere. Within a single JVM (such as a servlet container), the only way to have different versions of the same fully qualified class name is to use different class loaders, which loads the different versions from lots of different places. That sounds like a pretty significant code management issue that any hot deploy strategy like what you describe would need to deal with. On the other hand, you're going to need individual class loaders to solve a different aspect of hot deploy as well ... recompiling an existing implementation class to modify its behavior (instead of trying to switch to a new one). There is no ClassLoader.unloadClass() method in Java, so the only way to throw away an old class is to throw away the class loader that contained it (and hope that the rest of the application doesn't have any pointers to the old class or any instances created by it, which would cause a big memory leak). That's what a servlet container does, for instance, when you reload an app -- it throws away the old context class loader and creates a new one. It's not a perfect solution, but it's not an easy problem, either. Craig Late to this thread, but hot deployment is quite difficult to achieve inside a framework without very careful programming for very reason that Craig explained above. First, you need to solve the problem of deciding when the use of object is finished (pre garbage collect state) before you can ever remove the class. Since objects are based on classes you must know when it safe to discard the object. Second, if you need to invent a standard scheme to reload the class, if some external event (e.g a file modification time change in your native operating system) occurs. Third, decide about versioning with your (hot deployable) classes. What if I replace the current version of a class B with an ancient version A? Now if the number of classes of A is less than the number of classes of B, then you must loop right back to the first to the first problem. Hence WebLogic etc have Admin Server and Managed Server to handle application and web container requirements, but it would be harder to further divide this macro architecture into more finer architecture and also have good ease-of-development deployment. -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
I think I got a book at home in the attic that went into so-called ``Hot Deployment'' in great detail. (Been a year since I last looked at it for generic service locator idea, in the end I found myself looking at IoC / Dependency Injections pattern.) It is addison wesley from 2001-2002. Let me google for you ... Yep! Here it is http://www.amazon.co.uk/exec/obidos/ASIN/0201753065/qid=1101813082/sr=1-5/ref=sr_1_2_5/202-3643115-2068623 # Component Development for the Java Platform (DevelopMentor Series) # by Stuart Halloway # Paperback 304 pages (January 7, 2002) # Publisher: Addison Wesley # ISBN: 0201753065 This is where I got my information from that Hot Deployment is hard to achieve in Java without careful programming. I think you ask too much for developers of an application frameworks to follow strict programming rules in whatever hot deployment scheme you invent. Let's it was so simple we'd all be doing it. -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: 29 November 2004 09:00 To: Struts Developers List Cc: [EMAIL PROTECTED] Subject: Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea] Here is code, as opposed to pretty pictures -- LOL ;-) This is intended to demonstrate how simple Had is in contrast to normal Service Locator or Inversion of Control (Dependency Injection) frameworks. Remember, THIS IS ALL THE CODE. There are no NanoContainers. Not XML. No Config classes, etc. Where you want to have a single class with potential changes in implementations, you simply do not change the name of the class, e.g. provide new implementations under the same name. Where you want implementations that are different, e.g. if the Action class were an interface, you simply use different names for the different implementations and then you can hot deploy variations on the code in classes with those names. This allows you to change an existing implementation radically either by hot deploy or by name. Which you want to do depends on the situation. ActionServlet would want to be, for example, an interface that allowed differing implementations under ActionServlet without having different named implemenations, like you have with IoC and Service Locator solutions. On the other hand, you also would get hot deploy of various Action implementations under different names, e.g. LogonAction, PublishAction, etc. A working application with the App interface and client tester is available in a zip file, classes.zip, at http://131.191.32.112:8080/classes.zip This code has some additions that allow us to see whether or not a particular object has the last loaded implementation of AppImpl. The code includes: App.java AppImpl.java AppHotFactory.java TestAppClientTester.java SiteConstant.java Classpath.java.java To use a new AppImpl, all you have to do is to drop the AppImpl.class into the classes/deploy/com/crackwillow/app directory and call AppHotFactory.loadAppImpl(). To see the name command work with the client, start the client with java com.crackwillow.testing.TestAppClientTester NEW_NAME Jack -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Spring dreaming (was Second call: add generic mapped proper ty to ActionConfig)
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED] === --- Craig McClanahan [EMAIL PROTECTED] wrote: I agree with Don's assessment, but wanted to add an FYI note -- Shale does zero-config for #3 (because the mapping between a JSP page and the corresponding ViewController is implicit), and doesn't require #1 unless you need it for doing Commons Validator stuff. Simpler is definitely better. But is adding yet another framework to Struts simplifying anything for the user or just for us developers? If we add Spring, we would need to know the following to write a Struts webapp: 1. struts-config.xml 2. validator-rules.xml 3. spring.xml (or whatever they call the config file) 4. possibly tiles-config.xml 5. possibly jsf config files How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps. XML configuration cannot replace traditional programming. You can quote me on that. ==== XML configuration cannot replace programming -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] SVN / Eclipse / Subclipse error
Sorry for the OT, but I figured some folks here are doing this. I'm trying out Subclipse and getting this error: http://cvs.apache.org/~jmitchell/server-cert-invalid.jpg How are you getting around this? Command line works fine for me, but I would really like to use Eclipse. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Spring dreaming (was Second call: add generic mapped proper ty to ActionConfig)
On Tue, 30 Nov 2004 11:23:35 +, Pilgrim, Peter wrote: How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps. XML configuration cannot replace traditional programming. You can quote me on that. ==== XML configuration cannot replace programming We're not talking about programming, but configuration. OOP defines a program as a graph of objects. The XML configuration is a convenient way to define the graph of objects we are using to solve the problem. Meanwhile, IoC containers, like Spring, have become the conventional way to create the objects we need at runtime. Some factories can be configured from an XML document, others can be configured by direct calls to the Spring API. Everybody wins :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Roadmaps (was Spring dreaming ...)
On Tue, 30 Nov 2004 00:34:54 -0800, Craig McClanahan wrote: Tell me again why it is ok for Stuts 1.x to require more configuration files than Shale does :-) It's not OK, which is why the latest proposed roadmap mentions combining the configurations. All three configurations support partial and multiple files, so combining them should not be difficult. People could then use the existing files or combined then in anyway they pleased. (I forget why we didn't do this in the first place.) I'll take a minute to update the website tonight, before getting on to my other todo items. Speaking of todos, is there more to be done on the struts-faces taglib? Or is that ready for a release vote? The struts-faces taglib seems like a great way to introduce people to JSF on the frontend. Hopefully, the work on Struts 1.3.x will enable people to migrate the guts of Struts Actions to Chain Commands. In terms of providing a clear migration path, Chain is important since it could work equally well for Struts or JSF applications. Then, there will be a way for people to migrate both pages and Actions, and the JSF leap becomes a baby step. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Metadata Musings.... (was Spring etc)
quote XML configuration cannot replace traditional programming. /quote I'd rephrase that slightly as: XML configuration cannot completely replace traditional programming. The issue being here that with the right frameworks and tooling you can go a long way to eliminating all code except that which actually is unique to your business problem and is not worth describing in those common terms. Everything is an abstraction, XML metadata is just a at higher level. I personally feel that the more configuration and logic you can describe through some sort of metadata the better, under the proviso that the metadata you are dealing with is not more complex than the code you're substituting for, but that's just me. Regards Duncan Mills Pilgrim, Peter wrote: -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] === --- Craig McClanahan [EMAIL PROTECTED] wrote: I agree with Don's assessment, but wanted to add an FYI note -- Shale does zero-config for #3 (because the mapping between a JSP page and the corresponding ViewController is implicit), and doesn't require #1 unless you need it for doing Commons Validator stuff. Simpler is definitely better. But is adding yet another framework to Struts simplifying anything for the user or just for us developers? If we add Spring, we would need to know the following to write a Struts webapp: 1. struts-config.xml 2. validator-rules.xml 3. spring.xml (or whatever they call the config file) 4. possibly tiles-config.xml 5. possibly jsf config files How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps. XML configuration cannot replace traditional programming. You can quote me on that. ==== XML configuration cannot replace programming -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - 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]
RE: Spring dreaming (was Second call: add generic mapped proper ty to ActionConfig)
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] On Tue, 30 Nov 2004 11:23:35 +, Pilgrim, Peter wrote: How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps. XML configuration cannot replace traditional programming. You can quote me on that. ==== XML configuration cannot replace programming We're not talking about programming, but configuration. OOP defines a program as a graph of objects. The XML configuration is a convenient way to define the graph of objects we are using to solve the problem. Meanwhile, IoC containers, like Spring, have become the conventional way to create the objects we need at runtime. Some factories can be configured from an XML document, others can be configured by direct calls to the Spring API. Everybody wins :) This is a misunderstanding between you and I. External configuration of JavaBeans (or plain old java object) with or without XML is the idea of springing objects into existance without hard wiring of dependencies (http://bridgetown.sf.net) The IoC/Dependency Injection is the solution to the generic service locator problem, which I have been battling over for a couple of years. So you see, we're not a million miles apart. The warning is that XML configuration of POJO cannot solve all problems. There some problems that are really part of the programming domain (sequence, iteration, recursion). -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Metadata Musings.... (was Spring etc)
repost (gmane) Flex just does that, it is declerative programing language. I think it is the far future (I think SoA is up 1st). http://livedocs.macromedia.com/flex/15/asdocs_en/mxml-tags.html It even has a repeater xml .V quote XML configuration cannot replace traditional programming. /quote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] SVN / Eclipse / Subclipse error
James Mitchell wrote: Sorry for the OT, but I figured some folks here are doing this. I'm trying out Subclipse and getting this error: http://cvs.apache.org/~jmitchell/server-cert-invalid.jpg How are you getting around this? Command line works fine for me, but I would really like to use Eclipse. James - maybe this will be of some help, I have it bookmarked from when I first started using Subclipse... http://archives.real-time.com/pipermail/cocoon-devel/2004-May/033497.html (I don't remember what exactly I had to do at the command line though...) Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chain enhancement idea
-Original Message- From: BaTien Duong [mailto:[EMAIL PROTECTED] == Craig McClanahan wrote: On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska [EMAIL PROTECTED] wrote: I need to have a hook into processValidate() on validation failure. Currently that can only be done by copy-and-pasting the processValidate() method from RequestProcessor into a subclass and sticking a hook into the middle of the code. When I asked about this on the dev list long ago, it was confirmed that there was no other way to do this, but that chain would eventually provide this flexibility. If the chain isn't configured at a fine-grain level, then it's not all that much more functional than the existing RequestProcessor. The chain is configured at as fine-grained a level as you like, in XML. Hubert is talking about configuring the chain programatically as well, or at least in some way independent of the configuration of the primary processing chain. Programmatic configuration is certainly feasible ... there's no requirement in [chain] that you use the XML format at all. It's just one option. Greetings and request expert advice: Commons-chain invented by Craig proves to be very flexible and work in conjuction with other great technonologies. What i am trying to figure out is a proper and practical places for using CoR and IoC (such as Spring framework) in the construction and configuration of software objects. I put out some of my preliminary thinking and hope some experts care to add more arguments to enlighten us. 1) Both CoR and IoC (and also Jsf setter injection) enable the configuration and linking objects via XML metadata. But IoC allows the object configuration at a finer level of object attributes and take care of the objects declared as singleton. In this sense, IoC is finer grain than CoR in object creation, configuration and management. 2) CoR is very light weight and appropriate for programmatically created processes. It does not not have the complexity and the depth of plug-in features as Spring IoC. Chain of Responsibility is pattern that separates the sending of a message from the receiver of message. So it solves different problem for inverse of control. I think you are looking at this from the perspective of `callback interfaces', therefore IoC appears to have much more power and depth. 3) CoR is finer grain than IoC in the construction and rounting of services within and between software layers, while IoC is aprropriate at the application level. IoC is an application level, because it does help with configuration and look up of services, beans or other artefacts. The CoR is a messaging pattern primarily. It is not a question of either CoR or IoC, you can use both of them together. The question is how? That is question of architecture, what is the best way to build a house, I think you will find a million and one answers there. There are ways of designing software, but one needs to understand what the patterns are, what are they purporting to solve. After that it is easier to decide if a particular pattern is heavy or lightweight, better or worse, because each pattern has it original context of application. hth 4) If we want to combine Jsf as view controller, Spring IoC and commons-chain CoR, a practical infrastructure may be something like followings: a) Jsf as a view controller takes care of objects directly related to User Interface (UI) b) Spring IoC takes the responsibility of object creation, especially singletons and fine grain configurations of objects not directly related to UI. This is a proper choice of configuration if other features of Spring framework such as application level event and aop are used. An IoC container can take over construction of objects that you required a lightweight container full stop (period). If you want to take advantage of AOP light weight containers then you must register your objects with the IoC container beforehand. c) CoR is used to construct Front Controller a la pattern of Struts of each software module, the rounting of services among modules, and action commands (or chain) of specialized services in each service module. It programmatically links created components from IoC to a finer grain at each software module, which holds the module Catalog of commands. I think Struts is a FrontController. So I'd be more inclined to let Struts be Struts. There appears to be confusion about CoR and IoC and also various idioms and patterns common place in the J2EE world. In the new Struts applications I think there are three chains: front controller, action, and view. The chain of the front controller effectively ties together the CoR for the request processor. The other two chains are for Web User Interface actions and view rendering technologies. I think the latter two
RE: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Jack, Peter's point ``Hot Deployment'' can be located in Chapter 2 p29-34 http://www.develop.com/us/technology/developmentorseriesdownload.aspx?id =11 Shed. Way out of my league -Original Message- From: Pilgrim, Peter [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 6:16 To: 'Struts Developers List' Cc: [EMAIL PROTECTED] Subject: RE: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea] I think I got a book at home in the attic that went into so-called ``Hot Deployment'' in great detail. (Been a year since I last looked at it for generic service locator idea, in the end I found myself looking at IoC / Dependency Injections pattern.) It is addison wesley from 2001-2002. Let me google for you ... Yep! Here it is http://www.amazon.co.uk/exec/obidos/ASIN/0201753065/qid=1101813082/sr=1- 5/ref=sr_1_2_5/202-3643115-2068623 # Component Development for the Java Platform (DevelopMentor Series) # by Stuart Halloway # Paperback 304 pages (January 7, 2002) # Publisher: Addison Wesley # ISBN: 0201753065 This is where I got my information from that Hot Deployment is hard to achieve in Java without careful programming. I think you ask too much for developers of an application frameworks to follow strict programming rules in whatever hot deployment scheme you invent. Let's it was so simple we'd all be doing it. -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: 29 November 2004 09:00 To: Struts Developers List Cc: [EMAIL PROTECTED] Subject: Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea] Here is code, as opposed to pretty pictures -- LOL ;-) This is intended to demonstrate how simple Had is in contrast to normal Service Locator or Inversion of Control (Dependency Injection) frameworks. Remember, THIS IS ALL THE CODE. There are no NanoContainers. Not XML. No Config classes, etc. Where you want to have a single class with potential changes in implementations, you simply do not change the name of the class, e.g. provide new implementations under the same name. Where you want implementations that are different, e.g. if the Action class were an interface, you simply use different names for the different implementations and then you can hot deploy variations on the code in classes with those names. This allows you to change an existing implementation radically either by hot deploy or by name. Which you want to do depends on the situation. ActionServlet would want to be, for example, an interface that allowed differing implementations under ActionServlet without having different named implemenations, like you have with IoC and Service Locator solutions. On the other hand, you also would get hot deploy of various Action implementations under different names, e.g. LogonAction, PublishAction, etc. A working application with the App interface and client tester is available in a zip file, classes.zip, at http://131.191.32.112:8080/classes.zip This code has some additions that allow us to see whether or not a particular object has the last loaded implementation of AppImpl. The code includes: App.java AppImpl.java AppHotFactory.java TestAppClientTester.java SiteConstant.java Classpath.java.java To use a new AppImpl, all you have to do is to drop the AppImpl.class into the classes/deploy/com/crackwillow/app directory and call AppHotFactory.loadAppImpl(). To see the name command work with the client, start the client with java com.crackwillow.testing.TestAppClientTester NEW_NAME Jack -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
--- Craig McClanahan [EMAIL PROTECTED] wrote: On Mon, 29 Nov 2004 10:34:13 -0800 (PST), David Graham [EMAIL PROTECTED] wrote: --- Craig McClanahan [EMAIL PROTECTED] wrote: I agree with Don's assessment, but wanted to add an FYI note -- Shale does zero-config for #3 (because the mapping between a JSP page and the corresponding ViewController is implicit), and doesn't require #1 unless you need it for doing Commons Validator stuff. Simpler is definitely better. But is adding yet another framework to Struts simplifying anything for the user or just for us developers? If we add Spring, we would need to know the following to write a Struts webapp: 1. struts-config.xml 2. validator-rules.xml 3. spring.xml (or whatever they call the config file) 4. possibly tiles-config.xml 5. possibly jsf config files How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps. David The current Shale version of struts-mailreader requires *one* configuration file (WEB-INF/faces-config.xml), and adding client side validation and/or Tiles *might* add one for each (although that is not a given). For example, Spring config files are only needed if you want to use Spring in addition to JSF -- if you are satisfied with the setter injection support that JSF already provides, you don't need Spring for basic IoC functionality. Tell me again why it is ok for Stuts 1.x to require more configuration files than Shale does :-) My basic concern is that we're heading down a path that doesn't simplify things for Struts users (including myself in that group) and instead using the next shiny technology in front of us. If Spring and/or JSF simplify using Struts, then I wholeheartedly support using them. But first we need to show how they accomplish that and not just use them because they're cool. Writing Java webapps should be easy. David Craig __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21244] - FormFile implementations should be serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=21244. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=21244 --- Additional Comments From [EMAIL PROTECTED] 2004-11-30 17:42 --- This bug isn't resolved but could be resolved very easy. The internal used DefaultFileItem class to hold the upload data contains a member named dfos of type DeferredFileOutputStream. This member must be declared as transient because Streams cannot be serialized. I think, that this would fix any problem with serialized upload forms. I cannot access the cvs repository but I made a local diff -u to the file based on revision 1.21. Here is the diff I made. @@ -156,7 +156,7 @@ /** * Output stream for this item. */ -private DeferredFileOutputStream dfos; +private transient DeferredFileOutputStream dfos; -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21244] - FormFile implementations should be serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=21244. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=21244 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-11-30 17:43 --- This bug isn't resolved but could be resolved very easy. The internal used DefaultFileItem class to hold the upload data contains a member named dfos of type DeferredFileOutputStream. This member must be declared as transient because Streams cannot be serialized. I think, that this would fix any problem with serialized upload forms. I cannot access the cvs repository but I made a local diff -u to the file based on revision 1.21. Here is the diff I made. @@ -156,7 +156,7 @@ /** * Output stream for this item. */ -private DeferredFileOutputStream dfos; +private transient DeferredFileOutputStream dfos; -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Writing Java webapps should be easy. http://www.hacknot.info/hacknot/action/showEntry?eid=45 Kind of a lengthy read, but it seemed appropriate. - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Roadmaps (was Spring dreaming ...)
On Tue, 30 Nov 2004 07:45:17 -0500, Ted Husted [EMAIL PROTECTED] wrote: Speaking of todos, is there more to be done on the struts-faces taglib? Or is that ready for a release vote? There are two outstanding bugs ... 32014 and 32370. The latter is fairly straightforward, the former is a must fix (the current wrapper that was added for MyFaces compatibility breaks the servlet API rules, but changing that makes Tiles not work). I'd also like to see MyFaces get to the point where it can actually run with Struts (since lots of people will try it) -- as of 1.0.7 they still had some bugs (which I filed in their SF bugtracking system a while back). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
On Tue, 30 Nov 2004 08:38:54 -0800 (PST), David Graham [EMAIL PROTECTED] wrote: My basic concern is that we're heading down a path that doesn't simplify things for Struts users (including myself in that group) and instead using the next shiny technology in front of us. If Spring and/or JSF simplify using Struts, then I wholeheartedly support using them. But first we need to show how they accomplish that and not just use them because they're cool. Does your definition of easier include writing less Java code? and less stuff in configuration files? If so, please compare the mailreader code in Struts 1.x versus the Shale-ized version. You'll find substantial improvements. If those aspects are not included in your definition, I'd be curious what is. Writing Java webapps should be easy. I'd say as easy as possible, but no easier :-) David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chain enhancement idea
At 3:31 PM + 11/30/04, Pilgrim, Peter wrote: The theory is to compose your own request processor, but has anyone got a working example of such a beastie (yet)? Well, I'm not sure what you mean, but I have a production app which includes eight locally developed commands interspersed among the standard chain commands. These are responsible for instantiating and populating our ActionContext class (similar to some things we've discussed here recently), deriving the user ID from a variety of possible authentication sources, establishing the user's session based on the authenticated ID, enforcing access control rules, and executing our view controller code before dispatching to the requested view. A chain based RP made throwing in each of these in its place extremely simple, while adding each of these in the appropriate place by extending any other RequestProcessor class would have been extremely cumbersome. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
+ 1 .V David Graham wrote: If Spring and/or JSF simplify using Struts, then I wholeheartedly support using them. But first we need to show how they accomplish that and not just use them because they're cool. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6096] - [resources] PropertyMessageResources uses HashMap instead of Set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=6096. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=6096 [EMAIL PROTECTED] changed: What|Removed |Added Component|Sandbox |Resources Summary|PropertyMessageResources|[resources] |uses HashMap instead of Set |PropertyMessageResources ||uses HashMap instead of Set -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Good points, but there do exist tools to somewhat aide in configuration. True, not all configs have tools for them, and not all editors/IDEs support all tools ... but the tools do exist none-the-less :-) ... 'course, it's still nice to know the format of a config file, in case there's some feature you can't realize using a tool. WSAS tells me, for example, that I have a broken link in my config file as a result of referencing a tile through the forward attribute of an action. It annoys me, but, of course, it works fine (Seems WSAD 5.1.1 only supports Struts 1.1). I can imagine a circumstance where a config could change by adding an attribute or some other thing so that the tool couldn't edit these pieces. Eddie - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, November 29, 2004 12:34 PM Subject: Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig) But is adding yet another framework to Struts simplifying anything for the user or just for us developers? If we add Spring, we would need to know the following to write a Struts webapp: 1. struts-config.xml 2. validator-rules.xml 3. spring.xml (or whatever they call the config file) 4. possibly tiles-config.xml 5. possibly jsf config files How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps. David --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0448-1, 11/26/2004 Tested on: 11/30/2004 12:22:38 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32014] - HttpServletRequestWrapper in struts-faces broken for servlet 2.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32014. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32014 [EMAIL PROTECTED] changed: What|Removed |Added Summary|HttpServletRequestWrapper in|HttpServletRequestWrapper in |struts-faces broken for |struts-faces broken for |servlet 2.4 |servlet 2.4 --- Additional Comments From [EMAIL PROTECTED] 2004-11-30 19:45 --- On the dev list, Craig wrote that this fix causes Tiles not to work. Can anyone provide more information about this? Presumably we should also be changing o.a.s.upload.MultipartRequestWrapper to extend HttpServletRequestWrapper when we move to Servlet 2.3 for Struts core. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] SVN / Eclipse / Subclipse error
I tried subclipse over the weekend, and I would have to agree. I am really dissapointed so far. I am well versed with the Eclipse CVS stuff, but Subclipse was a nightmare. It hosed my repository and It may have been the cause of my hosed eclipse install. I don't know what version of Subversion Apache is using, but if it is anything besides 1.1rc2 subclipse is not tested with it. All in all, I decided it is too early for subclipse, which is dissapointing, because I am not sure tigris sis still supporting/developing it. If you do get it working, please let me know. I want to post some instructions for using it with Struts. On Tue, 30 Nov 2004 08:55:15 -0600, Matt Bathje [EMAIL PROTECTED] wrote: James Mitchell wrote: Sorry for the OT, but I figured some folks here are doing this. I'm trying out Subclipse and getting this error: http://cvs.apache.org/~jmitchell/server-cert-invalid.jpg How are you getting around this? Command line works fine for me, but I would really like to use Eclipse. James - maybe this will be of some help, I have it bookmarked from when I first started using Subclipse... http://archives.real-time.com/pipermail/cocoon-devel/2004-May/033497.html (I don't remember what exactly I had to do at the command line though...) Matt - 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]
RE: [OT] SVN / Eclipse / Subclipse error
Subclipse just released an updated version today. http://subclipse.tigris.org/0.9.23/changelog.html (Note the Feature Change - IMPORTANT paragraph is not true, that change didn't make the release) I am subscribed to their dev list to keep tabs on the progress. They are still working on it and a new committer just joined that has been contributing a good deal. Synchronization is still not working but Subclipse definitely works although it's not yet up to the high standards of Eclipse CVS. -Original Message- From: Michael Rasmussen [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 1:53 PM To: Struts Developers List Subject: Re: [OT] SVN / Eclipse / Subclipse error I tried subclipse over the weekend, and I would have to agree. I am really dissapointed so far. I am well versed with the Eclipse CVS stuff, but Subclipse was a nightmare. It hosed my repository and It may have been the cause of my hosed eclipse install. I don't know what version of Subversion Apache is using, but if it is anything besides 1.1rc2 subclipse is not tested with it. All in all, I decided it is too early for subclipse, which is dissapointing, because I am not sure tigris sis still supporting/developing it. If you do get it working, please let me know. I want to post some instructions for using it with Struts. On Tue, 30 Nov 2004 08:55:15 -0600, Matt Bathje [EMAIL PROTECTED] wrote: James Mitchell wrote: Sorry for the OT, but I figured some folks here are doing this. I'm trying out Subclipse and getting this error: http://cvs.apache.org/~jmitchell/server-cert-invalid.jpg How are you getting around this? Command line works fine for me, but I would really like to use Eclipse. James - maybe this will be of some help, I have it bookmarked from when I first started using Subclipse... http://archives.real-time.com/pipermail/cocoon-devel/2004- May/033497.html (I don't remember what exactly I had to do at the command line though...) Matt - 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]
DO NOT REPLY [Bug 32396] - contentType has no effect with tomcat 5.0.28
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32396. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32396 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-11-30 19:20 --- I don't believe there's any evidence that this is a Struts bug. I just took a simple Struts app (Niall's validatorjs example which happened to be in my local Tomcat webapps dir) and added the same controller... line you specified below (except that i closed the element because I didn't have any other values to set) and when I retrieved the page, it was typed UTF-8. When that line was not in the struts-config.xml, the content type had no character encoding. I'm using Tomcat 5.0.16, but I am skeptical that the version number is the difference. Please try this with another Struts app in the same servlet container. You can get the one I used from http://niallp.pwp.blueyonder.co.uk/validatorjs.html -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain enhancement idea
Peter, Thanks for your view. I have made a good working prototype sice the first email. Interested persons can see my updates below: Pilgrim, Peter wrote: -Original Message- From: BaTien Duong [mailto:[EMAIL PROTECTED] Greetings and request expert advice: Commons-chain invented by Craig proves to be very flexible and work in conjuction with other great technonologies. What i am trying to figure out is a proper and practical places for using CoR and IoC (such as Spring framework) in the construction and configuration of software objects. I put out some of my preliminary thinking and hope some experts care to add more arguments to enlighten us. 1) Both CoR and IoC (and also Jsf setter injection) enable the configuration and linking objects via XML metadata. But IoC allows the object configuration at a finer level of object attributes and take care of the objects declared as singleton. In this sense, IoC is finer grain than CoR in object creation, configuration and management. 2) CoR is very light weight and appropriate for programmatically created processes. It does not not have the complexity and the depth of plug-in features as Spring IoC. Chain of Responsibility is pattern that separates the sending of a message from the receiver of message. So it solves different problem for inverse of control. I think you are looking at this from the perspective of `callback interfaces', therefore IoC appears to have much more power and depth. 3) CoR is finer grain than IoC in the construction and rounting of services within and between software layers, while IoC is aprropriate at the application level. IoC is an application level, because it does help with configuration and look up of services, beans or other artefacts. The CoR is a messaging pattern primarily. It is not a question of either CoR or IoC, you can use both of them together. The question is how? That is question of architecture, what is the best way to build a house, I think you will find a million and one answers there. There are ways of designing software, but one needs to understand what the patterns are, what are they purporting to solve. After that it is easier to decide if a particular pattern is heavy or lightweight, better or worse, because each pattern has it original context of application. hth Here is how based on my working prototype: Using commons-chain Agility, i build a request/response framework for communicating and specialized processing between different software layers or containers: web tier with portal container, business tier with containers such as authentication/authorization, portlets, services, etc. Each container is a singleton catalog to provide its specialized action commands. Each specialized thread-safe command just extends its base and override the handle(request) method similar to Struts actionCommand. Spring IoC is used to instantiate and configure application singletons (such as catalog) with default attributes, while CoR commands are instantiated only when needed and will be removed from its catalog if not used by a specified time. 4) If we want to combine Jsf as view controller, Spring IoC and commons-chain CoR, a practical infrastructure may be something like followings: a) Jsf as a view controller takes care of objects directly related to User Interface (UI) b) Spring IoC takes the responsibility of object creation, especially singletons and fine grain configurations of objects not directly related to UI. This is a proper choice of configuration if other features of Spring framework such as application level event and aop are used. An IoC container can take over construction of objects that you required a lightweight container full stop (period). If you want to take advantage of AOP light weight containers then you must register your objects with the IoC container beforehand. c) CoR is used to construct Front Controller a la pattern of Struts of each software module, the rounting of services among modules, and action commands (or chain) of specialized services in each service module. It programmatically links created components from IoC to a finer grain at each software module, which holds the module Catalog of commands. I think Struts is a FrontController. So I'd be more inclined to let Struts be Struts. There appears to be confusion about CoR and IoC and also various idioms and patterns common place in the J2EE world. In the new Struts applications I think there are three chains: front controller, action, and view. The chain of the front controller effectively ties together the CoR for the request processor. The other two chains are for Web User Interface actions and view rendering technologies. I think the latter two chains are well understood, but the front controller chain is not at the moment, at least by me. The original idea of commons chain was to solve the request processor
RE: [OT] SVN / Eclipse / Subclipse error
James, Fetch https://svn.apache.org in IE, you should get a Security Alert. Just View Certificate = Install Certificate. It worked on Win 2K, eclipse 3.0/3.1 with subclipse 0.9.22/0.9.23. Upgrade subclipse javahl worked right out of the box. Shed. -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 7:38 To: Struts Developers List Subject: [OT] SVN / Eclipse / Subclipse error Sorry for the OT, but I figured some folks here are doing this. I'm trying out Subclipse and getting this error: http://cvs.apache.org/~jmitchell/server-cert-invalid.jpg How are you getting around this? Command line works fine for me, but I would really like to use Eclipse. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Very applicable actually :) Let's look it this way - what types of information needs to go into configuration? I see the following types: 1. Action/Backing bean definitions. Perferably support for connecting with business objects. 2. Form/field definitions and validations. 3. ActionForwards/Navigation My understanding how these are handled by several major frameworks: Struts 1. Actions defined in struts-config.xml. No support for linking to business objects. 2. Forms defined in struts-config. Validations in validation-rules.xml 3. ActionForwards in struts-config.xml, no support for navigation JSF 1. Backing beans defined in faces-config.xml. Integration with Spring to connect to bus objects. 2. Forms and validations defined in the JSP's. No support for 1:M forms (save custom components) 3. No action forwards as page based. Navigation information stored in faces-config.xml Tapestry 1. Beans definied in each page's specification xml file. Support for bus object linking with hivemind. 2. Form fields defined in page spec file. No support for 1:M forms (save custom components). 3. No action forwards as page based. No explicit navigation configuration. One could argue Tapestry was the simplest, however it could also be argued the opposite since each page needs its own xml configuration file. The question is what and where do we want the user to be able to configure. On one extreme of configuration, NanoWeb/NanoWar require no configuration as the framework handles everything. On the other side, Struts seems to require configuration for everything. The better approach depends on your objectives and requirements, as well as personal taste. I'd argue Struts should continue to provide the maximum flexibility, but search for ways to provide intelligent defaults wherever possible to allow the new developer to be able to pick up Struts quickly, yet allow the advanced user the capability to customize the framework to their needs. I like Ted's one DTD idea to bring everything together, yet provide import-type capability to let those that perfer multiple files split out sections. I also like Spring's idea of separating the configuration from the code, to allow for alternate configuration schemes which may not even use XML. I think we should continue to strive for flexibility to allow innovative projects like Beehive to more easily explore new ideas and techniques. Don On Tue, 30 Nov 2004 10:47:23 -0600, Durham David R Jr Contr 805 CSPTS/SCE [EMAIL PROTECTED] wrote: Writing Java webapps should be easy. http://www.hacknot.info/hacknot/action/showEntry?eid=45 Kind of a lengthy read, but it seemed appropriate. - Dave - 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]
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Thanks for the information, Peter. A couple of comments within. To think ahead to the next couple of submissions, I know about Halloway, and based most of what I have done so far on his thinking. On Tue, 30 Nov 2004 11:04:58 -, Pilgrim, Peter [EMAIL PROTECTED] wrote: Hence WebLogic etc have Admin Server and Managed Server to handle application and web container requirements, but it would be harder to further divide this macro architecture into more finer architecture and also have good ease-of-development deployment. Seems to me like it would be worth while if we are talking about a basic web architecture. I am going to pursue this a bit. Thanks for these references. I take it you have worked extensively with WebLogic's servers (Admin and Managed)? Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Hi, Paul, Sorry to disappoint you, but thanks for stopping in to say you are not interested. LOL Seriously, this is a think tank thread not a completed idea which is being ballyhooed thread. If you know a better way than is being presented, please step up. I have not seen this conversation and am learning a lot and still pretty convinced there is some ore to be mined in these hills. What I am interested in is whether or not from the perspective of the developer of applications or the user of a container a hot deploy container might provide the best and easiest environment. Being interesting, first, or anything like that is not important to me. It does seem as if you have some knowledge which I would encourage you to share. But, I am not here to be deep. Just to be practical. Jack From my perspective, I kept hoping it was something deeper, but (no insult intended at all) it just kept seeming like someone figured out how to marry the factory pattern with a classloader. Much more interesting classloader magic has been done in the Eclipse internals, for example. -Paul Speed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Thanks again. More useful information, Craig. I am trying to figure out a good way to do a Registry.java class without messing up garbage collection. I was hoping to use finalize() to keep track outside of the garbage collection loop of live classes, but have discovered, I think, that only classes with new in their creation have their finalize() method called during garbage collection. Do you have any ideas on a good hook for a registry on garbage collection and live classes which does not inhibit garbage collection? Callback? Anyone else with an idea on that? Jack On Tue, 30 Nov 2004 00:21:42 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: Restarting the application works (for this particular scenario) ... but it makes any attempt to pretend to do hot deploy pretty pointless - the newly restarted app will already pick up the new version of your implementation class, without any special attention on the part of the app itself. There is no need, if you're willing to restart the app, to do anything like this. While the hot deploy part of the hot deploy would not be utilized in this case, the dependency injection equivalent would, and without the xml configuration being required. So, there seems to be some, if not a considerable, gain. Yes? Jack -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
While I'm one who has had good experiences with Spring's BeanFactory for managing my business objects, maybe we should focus first on defining what Struts is and what needs to be configured. This would allow us to move more flexibly to various configuration approaches, or conceivably support more than one. I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. Is there any interest in this, or is it cracked? If it's not cracked, we might also take a longer-term look at abstracting the session, which seems tedious, but has some of the same issues. We may never need to truly abstract away the HttpServletRequest, since the Chain context will have the same lifecycle and serve about the same purpose. Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
I'm putting a cap on my work here for the moment. I would be interested if anyone has some ideas, directions, etc. they could offer on the Registry issues. I would like to thank everyone, even Paul ;-), for their assistance on this thread. I need to do some homework and then will be back on this. Imagine me fading out with one of those background dreamy voices on the tube as in the Brady Bunch talking like a bubble in a cartoon, saying What a great bunch of guys and gals; I will return soon to this place. LOL Jack -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts API Bean (was Spring dreaming)
On the topic of a Struts API bean, I completely agree. We should have one bean, probably actually stored in the servlet context, which contains references to all the Struts-specific components like configuration elements and message resources. Now this, and the Spring topic, do overlap since this API bean could actually be a Spring BeanFactory which might be a more flexible approach actually. This would be separate from the ActionContext idea which would hold references to objects necessary for the execution of actions (chain context, http request/response, all current Action helper methods, etc). Ted, in fact, suggested an API bean previously as well, and I believe has even started sketching out what one might look like. Don Joe Germuska wrote: While I'm one who has had good experiences with Spring's BeanFactory for managing my business objects, maybe we should focus first on defining what Struts is and what needs to be configured. This would allow us to move more flexibly to various configuration approaches, or conceivably support more than one. I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. Is there any interest in this, or is it cracked? If it's not cracked, we might also take a longer-term look at abstracting the session, which seems tedious, but has some of the same issues. We may never need to truly abstract away the HttpServletRequest, since the Chain context will have the same lifecycle and serve about the same purpose. Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Second call: add generic mapped property to ActionConfig
Sure, works for me :) Don Joe Germuska wrote: snip / Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Experiences with MockObjects for Servlet testing?
At 5:13 PM + 11/23/04, Gareth Webbley wrote: I don't know if this is the correct way to do it but if you call setupGetAttribute on the MockServletContext with the key that you require and a null value, when the code you want to test calls getAttribute it will get a null value (which I assume is what you want in the test) and the AssertionFailedError will not be seen. I think the idea is you call setupGetAttribute with each attribute you expect the code you are testing to try to get even if you want the code to receive a null value. If the code attempts to get an attribute which you haven't told the MockServletContext about you get the AssertionFailedError. Gareth: This moved me further, but only to another error: 1) testActionCaching(org.apache.struts.chain.TestCreateAction)junit.framework.AssertionFailedError: attributes.actions has run out of objects. The JavaDoc for the Mock servlet objects is hopeless. Can you point to any other good docs for using the MockObjects for servlet testing? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
--- Joe Germuska [EMAIL PROTECTED] wrote: snip This sounds like a good idea to me. I generally avoid Properties in favor of Maps in external interfaces but the casting really is a pain. Properties is a Map so you could store any old object in there anyways. David Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
On Tue, 30 Nov 2004 17:15:51 -0600, Joe Germuska wrote: I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. Like it? I implemented it two years nine months ago :) * http://svn.apache.org/viewcvs.cgi/struts/trunk/src/share/org/apache/struts/config/ConfigHelperInterface.java?rev=48889view=markup It's also mentioned on the proposed updates to the Roadmap. * http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=29427 under the moniker ViewContext. I was going to try and work on updating the website tonight, but my flight was delayed, and I might not get to it. I do think we should be passing a Struts API bean out to the view, which could also include a context for arbitrary properties. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain enhancement idea
Is your implementation of Agility something you could share with us, BaTien? -Ted. On Tue, 30 Nov 2004 12:23:39 -0700, BaTien Duong wrote: Here is how based on my working prototype: Using commons-chain Agility, i build a request/response framework for communicating and specialized processing between different software layers or containers: web tier with portal container, business tier with containers such as authentication/authorization, portlets, services, etc. Each container is a singleton catalog to provide its specialized action commands. Each specialized thread- safe command just extends its base and override the handle(request) method similar to Struts actionCommand. Spring IoC is used to instantiate and configure application singletons (such as catalog) with default attributes, while CoR commands are instantiated only when needed and will be removed from its catalog if not used by a specified time. snip/ In the above framework, i use Jsf+Tile as a view controller. A page is submitted directly to Jsf which is routed to a tile definition via MyFaces. I intent to use Shale as the application controller when shale has a custom ViewHandler to handle tiles. Currently, i use shale as a single servlet filter to wrap all application filters. User action event is handled by Jsf actionListener that passes user and hidden inputs (which include not only the requested action but also the catalog of the action and other properties) to the processUserAction(passedString) of an adapter. It receives the request outcome and set the outcome for Jsf navigation. Under this framework, chain catalog is the front controller of its specialized container, whose commands are very similar to struts actionCommand which must be done in thread safe. Since a chain is also a command, we can later drill down to a more elaborate process driven by business. The framework is very neat and flexible. That may be the reason why Ted calls his little framework Agility. BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Second call: add generic mapped property to ActionConfig
I like the idea of having a mapped property like this, but I'm not sold on this particular mechanism for implementing it. The reason is that it takes the general purpose set-property element and makes a particular property name special. That doesn't seem very clean to me, and we could end up breaking apps where people are already using a 'props' property. I'd prefer to use a new element nested within the action element for this, or perhaps even better, enhance the existing set-property element to handle it. The latter would allow the same mechanism to use used anywhere we currently allow set-property to be used. One example of how we might do this: Do things the way we do now (i.e. a custom property): set-property property=foo value=bar/ Set a mapped property instead of an individual one: set-property key=foo value=bar/ Notice the use of 'key' instead of 'property' to indicate that this will land up as a key/value pair in the mapped property set. -- Martin Cooper On Tue, 30 Nov 2004 16:05:16 -0800, Don Brown [EMAIL PROTECTED] wrote: Sure, works for me :) Don Joe Germuska wrote: snip / Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe - 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]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
On Tue, 30 Nov 2004 17:15:51 -0600, Joe Germuska [EMAIL PROTECTED] wrote: While I'm one who has had good experiences with Spring's BeanFactory for managing my business objects, maybe we should focus first on defining what Struts is and what needs to be configured. This would allow us to move more flexibly to various configuration approaches, or conceivably support more than one. I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. +1 for defining a context, reducing servlet API dependencies, and making the framework more testable. :-) -- Martin Cooper Is there any interest in this, or is it cracked? If it's not cracked, we might also take a longer-term look at abstracting the session, which seems tedious, but has some of the same issues. We may never need to truly abstract away the HttpServletRequest, since the Chain context will have the same lifecycle and serve about the same purpose. Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts API Bean (was Spring dreaming)
On Tue, 30 Nov 2004 16:00:49 -0800, Don Brown [EMAIL PROTECTED] wrote: On the topic of a Struts API bean, I completely agree. We should have one bean, probably actually stored in the servlet context, which contains references to all the Struts-specific components like configuration elements and message resources. Now this, and the Spring topic, do overlap since this API bean could actually be a Spring BeanFactory which might be a more flexible approach actually. This would be separate from the ActionContext idea which would hold references to objects necessary for the execution of actions (chain context, http request/response, all current Action helper methods, etc). Well, let's generalise that to references to objects necessary for the processing of a specific request, and not tie it to actions per se. ;-) But yes, this would be where things like the current module and the module's resource bundles are stashed, amongst other things as you suggested. -- Martin Cooper Ted, in fact, suggested an API bean previously as well, and I believe has even started sketching out what one might look like. Don Joe Germuska wrote: While I'm one who has had good experiences with Spring's BeanFactory for managing my business objects, maybe we should focus first on defining what Struts is and what needs to be configured. This would allow us to move more flexibly to various configuration approaches, or conceivably support more than one. I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. Is there any interest in this, or is it cracked? If it's not cracked, we might also take a longer-term look at abstracting the session, which seems tedious, but has some of the same issues. We may never need to truly abstract away the HttpServletRequest, since the Chain context will have the same lifecycle and serve about the same purpose. Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe - 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]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Yep, that's a lot of what I had in mind. But I had been thinking that there was call for some more functionality in the controller layers as well as in the view. The interface is read-only, which is right for a view, but maybe incomplete in other layers. But I'm ready for bed now, so I will have to sleep on it before I could say just what write type methods I think there would need to be. Joe At 11:16 PM -0500 11/30/04, Ted Husted wrote: On Tue, 30 Nov 2004 17:15:51 -0600, Joe Germuska wrote: ÝI've been thinking for a while that we should stop storing so many Ýthings directly in the ServletContext and instead, define a ÝStruts object which would hold these things. ÝI've mentioned this Ýobliquely a few times and not gotten much response, so maybe no one Ýelse likes the idea. ÝOr maybe it's been too oblique. ÝBenefits of Ýsomething like this would be reducing dependencies on the Servlet ÝAPI and providing a better environment for testing. Like it? I implemented it two years nine months ago :) * http://svn.apache.org/viewcvs.cgi/struts/trunk/src/share/org/apache/struts/config/ConfigHelperInterface.java?rev=48889view=markup It's also mentioned on the proposed updates to the Roadmap. * http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=29427 under the moniker ViewContext. I was going to try and work on updating the website tonight, but my flight was delayed, and I might not get to it. I do think we should be passing a Struts API bean out to the view, which could also include a context for arbitrary properties. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Re: Second call: add generic mapped property to ActionConfig
Yes, I like this better. Then, a method on ActionConfig: public String getProperty(String key) which returns the value which was set. As an implementation detail, there would also be a setProperty(String key, String value). This method would obey the configured/frozen semantics of other properties of ActionConfigs, so that users don't mistakenly change values during runtime on a shared object. I think I like Martin's proposed configuration syntax also. I suppose it could be confusing in some ways, but I think those who need to use it would figure it out. I'll probably do this in the next few days. Thanks for the opinions... Joe At 8:30 PM -0800 11/30/04, Martin Cooper wrote: I like the idea of having a mapped property like this, but I'm not sold on this particular mechanism for implementing it. The reason is that it takes the general purpose set-property element and makes a particular property name special. That doesn't seem very clean to me, and we could end up breaking apps where people are already using a 'props' property. I'd prefer to use a new element nested within the action element for this, or perhaps even better, enhance the existing set-property element to handle it. The latter would allow the same mechanism to use used anywhere we currently allow set-property to be used. One example of how we might do this: Do things the way we do now (i.e. a custom property): set-property property=foo value=bar/ Set a mapped property instead of an individual one: set-property key=foo value=bar/ Notice the use of 'key' instead of 'property' to indicate that this will land up as a key/value pair in the mapped property set. -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
