Re: Chain enhancement idea
On Wed, 24 Nov 2004 11:03:23 -0700, BaTien Duong [EMAIL PROTECTED] wrote: [snip] 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. I don't think of these as mutually exclusive. Why not set up a mechanism to configure your CoR command chains out of Chain and Command beans instantiated via your favorite IoC container? The XML format supported by Commons Chain is a convenience, not a requirement. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale application-wide controller
On Wed, 24 Nov 2004 11:44:04 -0800, Martin Cooper [EMAIL PROTECTED] wrote: Is there any reason that a JSF-independent version of the application-wide controller scheme, as just checked in, couldn't be part of Struts 1.3? That should work fine, as long as 1.3 is going to be based on Servlet 2.3 or later. Tweaks to un-JSF-ize this would be quite small. Or, for that matter, even part of the Commons Filters component, or even Chain itself? It seems like a much too useful general purpose filter to bury it in Shale. ;-) It's also a shame that you guys are so focused on the current version that you haven't had a chance to see the light about the future too :-). Also, it seems unfortunate that ShaleWebContext appears to be already nailed to the servlet API, rather than usable with portlets as well. As soon as I can prove to myself that you can really use filters in a portlet environment, I'll make it work for that too (adding the portlet API jar as a dependency, of course). -- Martin Cooper Craig - 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: Shale application-wide controller
On Wed, 24 Nov 2004 14:39:45 -0800, Dakota Jack [EMAIL PROTECTED] wrote: Where is this checked in. folks? We recently reorganized the repository so that independent pieces of Struts could be branched and released independently of each other. As a result, the SVN repository for the core of Struts itself is: http://svn.apache.org/repos/asf/struts/core/trunk while all the sandbox stuff (including struts-chain, struts-shale, struts-shale-mailreader) is at: http://svn.apache.org/repos/asf/struts/sandbox/trunk Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Apache Struts Wiki] Updated: SiteNavigation
I reverted the defacement, but didn't see any confirmation email. Craig On Thu, 25 Nov 2004 18:31:18 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Date: 2004-11-25T10:31:18 Editor: HnhhuHnk [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: SiteNavigation URL: http://wiki.apache.org/struts/SiteNavigation - 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]
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 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]
If I'm reading the code right, your factory for any given class has to know a bunch of nitty gritty details in order to implement the transferState() method, right? So, whenever I add new state information to the application class, I have to update transferState() as well? I don't see any mechanism to replace references to previous instances of a newly loaded implementation class -- without that, hot deploy doesn't seem particularly useful. Or, for that matter, any mechanism to suspend access to the old instance while the state is being transferred. I definitely don't like the notion of having more than one class with the same name floating around ... that's just asking for confusion and problems in debugging. Overall, it seems like an interesting attempt to do the kinds of things that implementation inheritance (using more typical service locator patterns), and/or (JDK 1.3 or later) dynamic proxies, let you deal with in ways that are more to my personal taste. Craig On Mon, 29 Nov 2004 00:59:43 -0800, Dakota Jack [EMAIL PROTECTED] wrote: 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]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
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. Craig On Mon, 29 Nov 2004 10:03:16 -0800, Don Brown [EMAIL PROTECTED] wrote: struts-config.xml accomplishes the following tasks: 1. Defines form models 2. Defines and configures Actions 3. Defines and configures mappings of actions 4. Defines and configures plugins 5. Defines and configures message resources 6. Defines and configures request processor I see Spring vastly improving, if not completely replacing, #2, #4, #5, and #6. It could even be argued #1 should be moved into a form definition file that integrates validator field configuration. Therefore, I'd imagine a Springified Struts only needing struts-config.xml for #3, defining action mappings, with probably another configuration element to point to the Spring context/BeanFactory file for the module (loaded as a child of a global Spring context/BeanFactory) and the bean id's the request process, message resources, and plugins can be found under. Don Joe Germuska wrote: snip / The more we go down this road of more robust configuration/initialization, the more I think we are going to realize Spring already does this and does it better. I suspect you're right, as I have come to prefer Spring's BeanFactory to Digester for this kind of thing. Have you ever looked at configuring Struts completely using Spring? It might be an interesting exercise, along with possibly coming up with an XSLT process to make current Struts config files usable with Spring! 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: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
On Mon, 29 Nov 2004 15:04:48 -0800, Dakota Jack [EMAIL PROTECTED] wrote: Thanks for this thoughtful response, Craig. Very helpful. Notes are within: On Mon, 29 Nov 2004 09:02:04 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: If I'm reading the code right, your factory for any given class has to know a bunch of nitty gritty details in order to implement the transferState() method, right? So, whenever I add new state information to the application class, I have to update transferState() as well? Yup! Dang! LOL Nothing is free, is it? I have changed the factory transfer state code to newApp.setState(existingApp.getState()); The people changing the implementation will know what state they want to keep, to alter, or whatever, and this allows them to do it. In the actual example of the AppImpl, I do with with a StateContainer. I have made these changes in the http://131.191.32.112:8080/classes.zip That's better, but still requires me to be able to produce this artificial state object. It's not obvious to me what happens if that state information is modified (on another thread) while getState() is executing, if it includes live references to other hot deploy instances, and a few goodies like that. file. I don't see any mechanism to replace references to previous instances of a newly loaded implementation class -- without that, hot deploy doesn't seem particularly useful. Or, for that matter, any mechanism to suspend access to the old instance while the state is being transferred. The previous instance, when loaded, is replaced with the new version. Or, do you mean generally? If you are talking about something like a registry, then that is what my question on the previous email was about. I am concerned that I be able to keep track of instances of an implementation but not stop garbage collection. My head is not coming up with interesting ideas on that one. I am sure that must exist. Do you have a suggestion on that? Or, if I am not reading you right, please elaborate. From a simplistic viewpoint, I see IoC type frameworks being used in a couple of different ways: * create on demand -- every time I need an instance of a service object, I call the appropriate factory method, use this resource, and then throw away my reference to it. (Using JNDI resources normally also follows this model). * create at startup -- leverage the IoC architecture to configure the actual implementation class separately, and call the factory (or whatever) only once, at application startup; caching the object reference I get back. Convenienty, this object is also set up with whatever dependencies it needs (using constructor injection, setter injection, or whatever). My concern with your hot deploy strategy is that it works fine for the first case, but not at all for the second ... and people who just read the name are going to feel misled when they find that they can't transparently swap *existing* instances of the service object being used. They can only change the implementation class for *new* instances -- and that isn't any different from what an IoC container that allows configuration changes can do. I definitely don't like the notion of having more than one class with the same name floating around ... that's just asking for confusion and problems in debugging. Yah. I have to agree on that one. That was just an extra which I thought was neat but which might be too confusing. Overall, it seems like an interesting attempt to do the kinds of things that implementation inheritance (using more typical service locator patterns), and/or (JDK 1.3 or later) dynamic proxies, let you deal with in ways that are more to my personal taste. Explain, if you would, on the dynamic proxies. I think I know what you mean but do not want to muddy the waters and would rather have you elaborate a bit. Okay? Eschew obfuscation and avoid metaphors 'til the cows come home! From JDK 1.3 onwards, you can create a class that *appears* to implement one or more particular interfaces, but doesn't really. This is an easy way to decorate existing objects to customize their behavior. The technique could be used to accomplish your idea of changing behavior on the fly -- but, of course, if you use create on demand and are using an IoC container that allows its configuration to be changed on the fly, then you don't even need dynamic proxies to change behavior at runtime. See java.lang.reflect.Proxy for more info. Thanks, again, Jack Craig Craig On Mon, 29 Nov 2004 00:59:43 -0800, Dakota Jack [EMAIL PROTECTED] wrote: 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
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
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 ...
}
Now, in your scheme you upgrade the Bar class (of course, setting up a
new class loader to contain it). 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.
You can tell me to use create on demand instead, but then I don't
need anything fancier than an IoC framework that lets me reconfigure
on the fly.
And, current IoC approaches provide me other important benefits:
* Multiple implementations can be used without the user having
to know the implementation class name.
* Don't need the artificial confusion of multiple instances of the
same class name.
For those reasons alone, I'm satisfied sticking with current IoC
approaches, and have sort of lost interest in pursuing this any
further.
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]
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: 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: [OT] Re: WeakReference
Don't forget that Strings are immutable in Java :-).
You might have better luck experimenting with a JavaBean that has
getters/setters for the properties you want to be able to mess with.
Craig
On Wed, 1 Dec 2004 23:44:38 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
Thanks for the response, Paul. Here's what I am up to. I can get an
object from the weak reference created from a strong reference. What
I want to do, and am not sure if I can (I am starting to think I
cannot), is to grab the object with the weak reference and make
changes which will happen also with the strong reference. So far, it
seems that when I have the object of a weak reference created form a
strong reference and change this object, it does not affect the object
of the strong reference.
E.g.
package com.crackwillow.deploy;
import java.lang.ref.WeakReference;
import java.lang.ref.Reference;
public class MyReference {
public static void main(String [] params) {
Stringstring = new String(Aa);
WeakReference wr = new WeakReference(string);
wr = replace(wr);
System.out.println(string);
System.out.println(wr);
string = (String)((Reference)wr).get();
System.out.println(string);
}
public static WeakReference replace(WeakReference wr) {
return new WeakReference(((String)wr.get()).replaceAll(A,B));
}
}
Apparently there is no connection between the objects referred to by
string and wr in the code shown above.
Is this clearer?
Jack
On Thu, 02 Dec 2004 02:03:39 -0500, Paul Speed [EMAIL PROTECTED] wrote:
A WeakReference is just a way of holding a reference to an object that
will not keep it from being garbage collected (a very useful thing).
There are also ways that you can track when it has been garbage
collected. Once it has been garbage collected, it's gone though. All
you have is any data you originally associated with your WeakReference
(by subclassing or some other method). You cannot access the referenced
object anymore because it doesn't exist.
While the object still exists (ie: is strongly referenced some where),
you can still access it through the WeakReference. You just have to
expect that at some point you may go to retrieve it from the
WeakReference and get a null.
Maybe it would help to know what you are trying to do with it. There
are other Reference implementations that may be better suited.
-Paul
Dakota Jack wrote:
Working here on a new paradigm, sort of, I think.
Apparently you can track what has happened to a strong reference with
a weak reference but you cannot manipulate the object referred to by
the strong reference by manipulating the weak reference. Is that
right? Seems odd to me.
Jack
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: WeakReference
On Thu, 2 Dec 2004 11:56:31 -0800, Dakota Jack [EMAIL PROTECTED] wrote: Essentially, I am trying to keep a WeakReference to Point classes so that when I update the Point.class I can change the classes for all the PointImpl objects out there. My understanding of Java (extensive in many areas, but not necessarily comprehensive here) is that this kind of replacement is *not* possible at all. At best, you can create new instances of the new class and then transfer the state information -- but that still doesn't clean up references that other objects will have to the old instance. Jack Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Call me crazy, but I want it all.
On Thu, 9 Dec 2004 11:36:10 -0500, James Mitchell [EMAIL PROTECTED] wrote: Also, why do we have so many copies of the mailreader example all over the place? Why can't we just keep one copy and have a build that can handle building for core or chain or shale or xyz? For the most part, they aren't the same. The canonical Struts mailreader app has been reimplemented in struts-faces with JSF tags but the same actions (twice, once without Tiles and once with), in Shale (completely re-implemented with JSF tags and the replacement for actions (much simpler, too, but that's for another thread :-). The common thread (at least among the implementations I've seen so far) is the abstraction of the DAO APIs (UserDatabase, User, Subscription) and the corresponding implementation that uses an XML document for persistence. That part has already been abstracted out ... it would be straightforward for the customized implementations to use that part from a common source, while keeping their own copies of what might be unique. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Craig - 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: Minimum Ant version for building Struts
+1. Just because we are conservative on runtime APIs doesn't mean we have to be conservative on our own environments :-). Craig On Fri, 10 Dec 2004 22:12:07 -0800 (PST), Martin Cooper [EMAIL PROTECTED] wrote: Currently, we say that Ant 1.5.4 is required for building Struts. I'd like to bump that to 1.6.2 as a minimum, so that we can take advantage of some of the features that were introduced in Ant 1.6. Anyone have any objections? -- Martin Cooper - 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: Any objections to adding Ant get's to build.xml?
On Thu, 16 Dec 2004 22:10:50 -0800, Don Brown [EMAIL PROTECTED] wrote: I'm setting up Struts to build from Ant (again), and have to go through the hassle of setting up build.properties. When I brought struts-bsf in, I changed its build.xml to, if a lib directory didn't exist, create one and use Ant's get task to pull the jars from ibiblio. It wouldn't be a long term solution to our building woes, but I figure if I have to go through the pain of setting up build.properties, I might as well make it easier for the next guy/gal. If you want nightly builds to work :-), the build.xml file had better work, with minimal need for custom build.properties files, although I'll obviously maintain those as needed for Struts and the commons package it depends on. A deeper issue, though, is that the way Maven currently generates Ant build.xml files is to duplicate hard coded URLs for the dependencies to be retrieved. Besides being very tough on people who try to build when not connected to the net, the fatal flaw is when you run into dependencies that cannot (for license reasons) be posted individually in a repository. Examples include the Commons Email dependence on JavaMail. If you're willing to hand create the Ant scripts so that you can still use build.properties type mechanisms to override these URLs, that's fine. If not, then I think it's a waste of time, because there is no solution for the non-redistributable-binary-dependencies scenario. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving Validator Depenency to Version 1.1.4
+1. That's the version of Commons Validator I plan to support in Shale as well. Craig On Thu, 16 Dec 2004 23:15:21 -, Niall Pemberton [EMAIL PROTECTED] wrote: Does anyone object to me moving Strut's dependency on to the recently released Version 1.1.4 of Commons Validator? Its a very minor maintenance release of Validator, but will allow the issues with Validator and different resource bundles to be resolved. Details of changes in 1.1.4 are here: http://jakarta.apache.org/commons/validator/changes-report.html Niall - 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: Escape html
The purpose for filtering these four characters is to avoid cross site scripting attacks that would otherwise be possible if an application accepted an input text field that had something like a script element in it, and then wrote that text to an HTML output stream with no modifications. Are there any other characters that should be filtered for security reasons? If not, what's the use case for converting anything else to its xxx; equivalent? Which, among other things, can cause you some grief if you're trying to do XML validation of the resulting output. Craig On Sun, 19 Dec 2004 18:51:32 -0300, Edgar Poce [EMAIL PROTECTED] wrote: Hi TagUtils.filter(String value) only filters 4 html sensitive characters while there are many more. Is there any special reason or it's a bug? Regards Edgar - 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: Escape html
On Sun, 19 Dec 2004 19:24:23 -0300, Edgar Poce [EMAIL PROTECTED] wrote: Are there any other characters that should be filtered for security reasons? I think there are not. I thought it was a html escape tool and I expected it replaced 'à' with agrave for example. But I see it's not the purpose. Has it any sense to add an escape attribute with values html, javascript, ...? I guess I am still missing the use case for doing this sort of thing ... what's the reasoning? If you're talking about webapps, by the way, another option is to use a Servlet Filter that intercepts the output and performs this sort of transformation. That solution would work on *any* way to generate the markup -- without requiring that the application source be modified. Thanks for your quick response Edgar Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extracting taglibs
I think a separate subproject for Tiles (including the code and the tags) probably makes the most sense. If we don't mind the dependency back onto Struts, then this could also include the Struts PlugIn that is currently used to configure it -- although it would probably be better that this class stay part of Struts so that the Tiles library could be used stand alone. In addition, there should be mechanisms to configure the Tiles definitions even if Struts is not present, via TilesServlet (which I believe already exists?) and/or a new ServletContextListener implementation since we're willing to use Servlet 2.3. Craig On Tue, 21 Dec 2004 18:29:43 -0800, Don Brown [EMAIL PROTECTED] wrote: It has been discussed, I believe, to separate Tiles from Struts, but no one seemed to know where it would go. jakarta-commons doesn't want taglibs, and for some reason I don't remember, the taglibs project wasn't accepted. It would be kinda funny, though, since Tiles used to be its own project that was assimilated into Struts when Struts was trying to divest iteself of code into commons. I mentioned the separation of Tiles from their taglibs as I thought I heard somewhere of Velocity being able to use Tiles. I could be wrong though. Don Eddie Bush wrote: Actually, I'd tend to agree with that. It makes more sense than separating Tiles and the Tiles taglibs - don't think you'd use the former without the latter. Maybe ... but I don't. On Tue, 21 Dec 2004 20:35:53 -0500, Deadman, Hal [EMAIL PROTECTED] wrote: Haven't look into this much but it would seem better to have a completely separate tiles sub-project that struts core would use. Don't JSF and Spring currently use tiles and have to include struts.jar when all they really want is tiles? -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 21, 2004 7:51 PM To: Struts Developers List Subject: Extracting taglibs My basic assumption in approaching taglibs extraction into its own subproject is it can reference Struts classes, but Struts classes shouldn't reference it. If that is correct, here are the changes I see happening to extract taglibs: 1. Move o.a.s.taglib out into its own subproject src tree 2. Remove methods in RequestUtils that delegate to TagUtils. They are marked as deprecated anyways and explicitly say they will be removed after 1.2. 3. Move properties in o.a.s.taglib.html.Constants that are referred to in Struts core code into o.a.s.Globals. (cancel and token keys) 4. Move o.a.s.taglib.tiles to o.a.s.tiles.taglib This one I'm not sure about. Should/can tiles be used w/o its jsp taglibs? If not, then it should stay in core w/ tiles. Otherwise, it could be moved out too. That should be it, as far as I can tell. taglibs are already pretty well isolated from the rest of Struts which will make the extraction pretty straightforward. I'd like to get this done before Christmas (25th) if there are no objections. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extracting taglibs
On Tue, 21 Dec 2004 20:45:03 -0800, Don Brown [EMAIL PROTECTED] wrote: I agree as well. This lets us follow a consistent approach to subprojects, where they may (and probably should) link to Struts core, but Struts core should not depend on them. I hope this can actually be accomplished ... but I recall playing around with this particular separation when we had our testbed Subversion installation, and the interdependencies were much more invasive than I would have originally expected ... to the point that I deferred actually finishing this particular separation (since I was mostly focused on whether SVN made sense). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r123053 - /struts/core/trunk/build.xml
On 22 Dec 2004 06:11:56 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: martinc Date: Tue Dec 21 22:08:58 2004 New Revision: 123053 URL: http://svn.apache.org/viewcvs?view=revrev=123053 Log: Ensure that the nightly build still works, now that the Chain code is in the mainstream (assuming that I'm right about what properties it depends on). The revamped build isn't ready yet. Saw this too late for last night's run (20041222), but it will work tonight (20041223).. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ViewUtils and UtilityFactory (was Extracting taglibs)
On Thu, 23 Dec 2004 10:54:31 -0800, Dakota Jack [EMAIL PROTECTED] wrote: What does Commons FileUpload being Filter-ized mean? Martin has talked (on the Commons dev list) about his plans to upgrade Commons FileUpload to use a Servlet Filter, and the request wrapper features of Servlet 2.3, in the next version. This will enable much cleaner integration of file upload processing with existing web application architectures, because (for many use cases) the fact that ths request is in mutipart/form-data can be made totally transparent to the rest of the architecture. Jack Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-faces] JSF integration into Struts
On Thu, 23 Dec 2004 18:04:18 -0800, Don Brown [EMAIL PROTECTED] wrote: Craig McClanahan wrote: On Thu, 23 Dec 2004 12:31:19 -0800, Don Brown [EMAIL PROTECTED] wrote: snip / If that is correct, would it be possible to implement JSF within Struts chain? Could a JSF implementation be decomposed into chain commands, and therefore allow the user to mix and match? You'd have to replace the standard implementation of JSF's Lifecycle API while still ensuring that the JSF based functioning happens in the correct order. To my mind, it's easier to decompose what Struts does and bolt it onto JSF (basically the direction Shale is taking) versus the other way. I guess what I have in mind is the JSF integration approach Cocoon takes. Every request enters Cocoon, then certain pipelines can choose to hand the request off to JSF. Conceptually, I think it is a better fit with the advantages of the respective frameworks. Cocoon and Struts excel at a request-based approach, so it is a natural fit for them to be the controller for all requests, JSF or not. JSF, as an event-based framework, is a fine solution for components or complex, event-based pages. I guess I'm not seeing the advantage of having a controller (in the sense that we've traditionally used talking about Struts or Cocoon) in *front* of JSF's controller. In a very simplistic sense, there are three kinds of requests in the world: * UI State Change (example: tree control node open/close, where the component's state is managed server side). Should be handled by the view tier technology (JSF in this scenario, which Shale puts in front). * Form Submit to be validated (example: typical of what Struts form processing ins about). Should be handled by the application tier that enforces such things (in Shale, this is done by a combination of the JSF validators and an upcoming integration of Commons Validator, all managed transparently by the JSF lifecycle, including redisplay of the input page if validation fails. * Validated form submit to be processed by business logic (example: what we use actions for in Struts; in JSF/Shale this is the invocation of the action method bound to your submit button). There's still room for some overall per-request processing for things like enforcing authentication, performance logging, etc. That can all be handled with a Filter (Shale's filter predefines before and after chains that you can use to decorate the basic functionality. I guess I don't see why I need anything else as a controller -- with the possible exception of managing dialogs that are longer than a request and shorter than a session. What I've got so far is conceptually pretty similar to what you can do today by sharing a single form bean across multiple pages; the reason it's not posted yet is I haven't made the remove the session object when you leave the dialog part quite elegant enough yet. The end game here would be to make Struts a universal controller implementation that could front-end JSF, Cocoon (as it can do now with the Struts Cocoon plugin), continuations-based frameworks, or any other more specialized controller implementation. IMO, chain is great for a universal controller backbone, but poor/too-generic for an application-level controller framework. Not every request/workflow might be appropriate for JSF, but by putting it behind Struts, the developer has the option how best to handle it. I guess where I'm going with this is one of the huge advantages of an event-based view framework like JSF is the ability to have self-contained, complex components. On the other hand, I think event-based approaches are poor at handling complex workflows as code has to be split up into different event methods. It seems like a perfect marriage would be event-based framework for the components, but continuations-based framework for application events and actions. Stay tuned next week for a Shale checkin that addresses the complexity of managing dialogs -- I've made some good progress fleshing that out. Continuations are definitely a good way to deal with serial workflows like a wizard dialog, and I'd like to see us continue to explore that avenue -- it's just not (yet?) obvious to me that they are optimal for workflows with lots of branches in them. Consider, for example, a dialog for handling authentication at a portal that also allows self-registration and remember me cookies. The various paths through this logic are essentially the same as the front parts of MailReader (up to where you get to the main menu), plus a bypass branch if the user's cookie is still there. For extra fun, assume that the process of collecting user profile info takes multiple screens, and that the user might at any point cancel the whole thing (meaning no updates should show up in any database). Actually, I think continuations really excel at workflows
Re: [struts-faces] JSF integration into Struts
On Thu, 23 Dec 2004 22:24:28 -0800, Dakota Jack [EMAIL PROTECTED] wrote: I think, Don, that this integration is a bit smoke and mirrors Really what the integration is, if I understand it right, is just a switch to use either JSF or Struts. They really cannot work together because JSF has a page based controller which is inconsistent with everything Struts as we know does. Sorry Jack, you don't have it right at all. The current integration library absolutely lets you use JSF components in an application based on Struts 1.1 or 1.2. Plus, far from being smoke and mirrors, the code actually exists too -- unlike some proposed approaches :-). http://svn.apache.org/builds/struts/nightly/struts-faces/ Of course, this approach doesn't leverage anything of JSF other than the visual components, but that's OK if it floats your boat. Don's question was primarily around whether you put JSF in front of, or behind, a flow-through controller (the page based part isn't really the important issue -- the part about wanting to be in front, and processing *all* requests first, is the key one). The integration library currently puts JSF in front (for user interface events only), which I believe is the better architecture -- a particular request penetrates into the system only as far as it makes sense. There's no reason, for example, for any business logic action to get involved in a purely visual change like expanding or contracting a tree node. Putting JSF in front lets that happen; the current Struts architecture doesn't. As for the future, the queston that Struts 1.x developers need to ask ourselves is what's the value add of a flow-through controller in a JSF environment. Others have already shown, for example, that you can use Tiles and Commons Validator directly with JSF (without using the Struts controller architecture) -- and these are capabilities I already know how to integrate into Shale. Servlet Filters let you do all the overall per-request type things you might want to do; no extra infrastructure is needed for overall control things like is the user logged in checking. It's also quite pleasant to be done with form beans (JSF components already do the stuff we used to need them for); to have the logic to set up a page and process it's input next to each other instead of in two actions that have to be chained; to not need configuration beans at all; to be able to manage multi-request dialogs more gracefully (stay tuned for a Shale example next week); and to be able to use JSF components from multiple libraries; but I digress ... Jack Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Faces - what to do?
On 4/13/06, James Mitchell [EMAIL PROTECTED] wrote: Perhaps Craig can shed some light on this, but are we going to continue to support the struts-faces project? We should. There will be people who want to have a few JSF components on a few pages (or they want to migrate) -- and using this library is the right strategy for them. Don was also talking about porting this to action2, which I also support. If so, can someone please fix the faces example (1 and 2) apps? Has the source organization and the build scripts settled down now? If so, I can devote some time to this ... but not until the end of next week. One more long trip first (St. Petersburg, Russia). -- James Mitchell Craig
Re: Struts Faces - what to do?
On 4/13/06, James Mitchell [EMAIL PROTECTED] wrote: Yes, I believe things have settled down. Although I'm still working changes in the struts-scripting webapp. The error I was getting when deploying the faces-example1 app was: javax.faces.FacesException: Undefined component type org.apache.struts.faces.Html Sounds like a jar file is missing from the webapp ... not all that surprising giving all the changes going on. I'll take a look. I was under the assumption that the struts-faces library only buys someone partial compatibility. And what they get was only jsf-1.0 compatible anyway, but I will be happy to be corrected. It buys you either JSF 1.0 or 1.1 or 1.2 ... but, more importantly, it buys you the ability to use the UI components part of JSF even if you don't want to use the controller part. For example, it has full integration with Commons Validator and Tiles, but uses JSF component tags instead of Struts HTML tags. -- James Mitchell Craig
Re: Struts Faces - what to do?
On 4/14/06, Dakota Jack [EMAIL PROTECTED] wrote: Isn't the rule that this should have [faces] or something like that in the subject matter? It is a convention, not a rule. And it is more for the user list than the dev list -- people subscribed here are presumed to have a clue :-). Craig
Re: [action1] Which webapp dtds to include in struts-core.jar?
On 4/14/06, Wendy Smoak [EMAIL PROTECTED] wrote: Do we need to include webapp-2_2.dtd in struts-core.jar? I deleted it as part of the reorganization [1], so only the webapp 2.3 dtd remains. Should we include the one for 2.4 as well? We need the 2.2 DTD if Struts continues to support Servlet 2.2. We should also definitely include the 2.4 DTD, as that is now a popular platform. To make the inclusion effective, though, we'll also want to make sure it gets registered with the Digester that processes config files -- otherwise, including it will not make any difference. Separately, I'm ready (gulp!) to start moving Shale towards Maven2, and it's recommended soure directory organizations ... as long as you have-a-clue-about-Maven gurus promise to stand by my side and help :-). I had a question about the resources directories in the organization recommended by Maven. Does that include resource bundles for localization (which are normally placed somewhere in the src/java hierarchy currently), or is it just for configuration files? It shouldn't be too hard to remodel the existing organization and update the relevant Ant build.xml files, as a move towards forwards compatibility with the recommended structure. In terms of timing, though, my efforts will likely be after next week ... on Sunday I get on a plane for a couple of days in St. Petersburg, Russia (just when I got used to it being springtime, back to mixed rain and snow showers). But it makes a lot of sense to migrate the internal organization of the Shale source repositories now, to make the ultimate conversion easier. Anyone else who wants to help in this is, of course, welcome to have at it. [1] http://svn.apache.org/viewcvs?rev=394264view=rev Thanks, -- Wendy Craig
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
On 4/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/14/06, Craig McClanahan [EMAIL PROTECTED] wrote: Separately, I'm ready (gulp!) to start moving Shale towards Maven2, and it's recommended soure directory organizations ... as long as you have-a-clue-about-Maven gurus promise to stand by my side and help :-). Of course. :) I had a question about the resources directories in the organization recommended by Maven. Does that include resource bundles for localization (which are normally placed somewhere in the src/java hierarchy currently), or is it just for configuration files? Maven's recommended directory structure is src/main/java for .java files, and src/main/resources for everything else. With that, no configuration is necessary. http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html If you prefer to keep .properties files in with the source code, it takes some resource sections in the pom to get them included in the jar. Example: http://svn.apache.org/repos/asf/struts/action/trunk/core/pom.xml It shouldn't be too hard to remodel the existing organization and update the relevant Ant build.xml files, as a move towards forwards compatibility with the recommended structure. ... But it makes a lot of sense to migrate the internal organization of the Shale source repositories now, to make the ultimate conversion easier. Anyone else who wants to help in this is, of course, welcome to have at it. The major change is splitting core-library into multiple modules, one per jar. Which is the reason I've been resisting so far ... :-) I'll want to experiment with ways to get combined javadocs out of these artifacts (although probably two sets ... I got a suggestion to split the APIs that are interesting to application developers from the internal APIs for those extending the framework, and would like to produce two sets of javadocs with their appropriate packages. Are you planning to keep the Ant build after Maven 2 is in place? Ideally, no ... it's hard enough to keep one build environment in sync with reality. But we'll probably need some user feedback before decomissioning the Ant scripts. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
On 4/15/06, Brett Porter [EMAIL PROTECTED] wrote: are the apis with the other javadoc going to be in a separate module? This should make it easy to produce javadoc from there, and then go on to produce the aggregated javadoc for the others. Ideally not. It's already going to be painful to split up the core-library package (which now produces several JAR files) into separate modules solely because Maven likes one artifact per module. Shale publishes information on API stability ( http://struts.apache.org/struts-shale/api-stability.html) that also includes a column describing who should be using the APIs in each package ... application developers or those wanting to extend the framework. That is the basis on which I would want to split the javadocs, but they would also be based on combining back together all the application-related APIs and all the framework-related APIs back together again. - Brett Craig On 4/16/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/15/06, James Mitchell [EMAIL PROTECTED] wrote: Craig wrote I'll want to experiment with ways to get combined javadocs out of these artifacts (although probably two sets ... Can we do this with custom assemblies? Without trying it, I don't think so, because it's more than just copying files around. The Javadoc tool needs to create the frames and indexes so that everything is linked together. I think it will need two reportSets, so the Javadoc plugin runs twice with different configuration. Maybe something like this, which runs both the regular Javadoc doclet and the UMLGraph one: http://wiki.wsmoak.net/cgi-bin/wiki.pl?UMLGraph And here's a link to some work that I did last year, which includes pom.xml files and a script to rearrange Shale into Maven 2's preferred structure. I stopped in late November, so it doesn't include Shale Tiger or anything after that. http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleMaven2#build -- Wendy - 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: Struts BOF at JavaOne?
On 4/21/06, James Mitchell [EMAIL PROTECTED] wrote: I'm seriously considering coming to JavaOne this year. What should I expect as far as costs? (Conference Pass, lodging, meals, etc) Full conference pass is pretty hefty ... $2595 before May 15, $2695 afterwards. Cheapest hotels I have seen this year are around $175/night (including the discount you get if you go through the conference registration system, but not including tax). Lunch is included, but you're on your own for breakfast and dinner and beer (although there are often parties you can horn in on, as well as a couple of BOFs that I understand plan to serve liquid refreshments :-) -- San Francisco has the typical range of food types and price ranges for a big city, many pretty close by. Don't bother with a rental car ... you can take BART directly from the SFO airport to downtown and be within walking distance of Moscone nearly all the reasonable hotels (for the farther away ones, there's free bus service to/from Moscone during the conference). If you want to swing one extra night of expenses, think about also signing up for NetBeans Day (Monday). It's free to get in, but registration is highly desireable (last year we thoroughly filled up the allocated space; it'll be bigger this year but we expect more folks too). This would be my first time and since this will be totally on my dime, any way for me to cut costs? Not much you can do this year other than perhaps try to share a hotel room with someone else. Biggest savings is if you get a session accepted -- speakers get in for free. -- James Mitchell Craig
Re: Bugzilla to JIRA migration update
On 4/22/06, Don Brown [EMAIL PROTECTED] wrote: [snip] - Move Shale issues into its own project. We would have done this already, but we wanted to let Shale pick their own prefix. We propose SHL +1 on a separate project. I'm ok with SHL as a prefix, but would actually prefer to spell it out (SHALE). I haven't seen that three characters is a limitation that Jira imposes, right? - Move Tiles issues into its own project (?). Also needs a collective decision on a prefix. We propose TLS Does this include both the SAF1-dependent version of Tiles and the standalone version in the sandbox? I'd recommend that it be just the latter, and if so I'm ok with TLS (but would prefer TILES) as the prefix. - Update the public site and any other Bugzilla URL links, once the above has been accomplished For now, Bugzilla has been turned Closed for entry, which as I understand it, only means no new tickets. Infra is talking about removing the project completely (with a backup saved somewhere of course). A word about prefixes - these are important because JIRA and Confluence can use them to link commit messages and wiki pages to tickets. They are also an easy way to associate a bug ticket number with an actual project without looking it up. We'd like to get the prefix question resolved by tomorrow if possible, as this limbo stage is vulnerable to synchronization issues as Bugzilla is still linked to and can be modified Finally, you will find that your account might have been created for you from the Bugzilla import. Please let me know if you need to be added to the struts-developer group that allows you to close tickets. http://issues.apache.org/struts Don Craig
Re: Standalone Tiles as TLP
On 4/23/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/23/06, Don Brown [EMAIL PROTECTED] wrote: I would think it would be Tiles' responsibility to support deployment with Struts. In that view, Tiles would be its own project, yet part of it would depend on struts-action.jar to provide the Struts hooks. In the same way, they would provide Struts Action 2 hooks, if necessary. This is a tough one - for me, at least. Should an independent Tiles have glue code for Struts, or should it be Struts' responsibility to provide the glue? If we look at Velocity, the glue is over there, but we've also talked about it coming here. If we look at Validator, the glue is here. If we look at Chain, the servlet and portlet glue is over there. I've always thought it would be as Martin describes for Validator -- standalone Tiles would really be standalone, and each framework that wanted to utilize it would provide it's own glue to some particular version(s) of Standalone Tiles. That is what Shale already does with the standalone Tiles stuff -- for example, Shale integrates tiles into the standard JSF navigation mechanism. That's not something that it seems reasonable to impose on a standalone project. My preference, at least at this time, would be for the Struts / Tiles glue to stay here. That will help Standalone Tiles stand on its own feet, and especially help with the notion that it's now independent of Struts. Any perception - real or otherwise - that Tiles is tied to Struts will be detrimental to Tiles as an independent library. +1 -- Martin Cooper Craig
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
On 4/24/06, Don Brown [EMAIL PROTECTED] wrote: So... is that a +1? :) As for annotations, I'd imagine we'd keep the XML as override so most anything you can do with annotations, you could also do in XML. This would give Java 1.4 users mostly the same capabilities. I think he was expressing a technical concern :-). And, depending on how you want to use annotations, it's an important one. It is straightforward to see how one could use annotations at build time, even if the ultimate target platform is 1.4. You can do things like run the apt tools, generate new code (or maybe generate config files that correspond to what the annotations signify) as part of the build process -- as long as the build process itself was running on Java SE 5, of course. Even this might be too much of a leap for some organizations, however. But the annotations facility also provides *runtime* mechanisms to examine a Class instance and determine what annotations are present. I do not see how that can be done with something like Retroweaver, for two reasons: * The annotations themselves can't be stored in the compiled class, because there is nowhere to put them. * The APIs to do the reflective checks (added to the Class class in 1.5) don't exist in the 1.4 runtime. This would be a pretty serious limitation on what you might otherwise want to do with annotations -- but, again, it depends on the intended usage patterns. Because of the above issues, I'm -0 on this, (it's not reasonable for me to vote -1 since I'm not the one that is wanting to do the work). I think a better strategy would be to have the core framework depend solely on 1.4, but provide an optional layer on top which leverages 1.5 things for those who actually do have a 1.5 runtime environment. That's the approach taken by the Tiger Extensions to Shale[1]. And, the first two features of these extensions (use annotations instead of configuration files, and use annotations instead of implementing interfaces) are *very* similar to the sorts of things that would make 1.5 attractive in [action2]. Don Craig [1] http://struts.apache.org/struts-shale/features-tiger-extensions.html Alexandru Popescu wrote: This looks quite nice. I cannot figure out what means support for annotations. Even if they are left inside the classbytecode, you will not have access to the API to use them (except the case they are weaving the Class.class, but I really don't think so). ./alex -- .w( the_mindstorm )p. On 4/24/06, Don Brown [EMAIL PROTECTED] wrote: There has been a lot of discussion on Java 5 support for Struts Action 2, and from my reading of the comments, we have settled on a path, but I want to formalize it in a vote to ensure we are all on the same page. I vote we develop Struts Action 2 with Java 5, taking advantage of it where ever we can. At the same time, we should use Retroweaver to build jars that will run in a 1.4 JVM. For those that aren't familiar, Retroweaver supports conversion of an impressive amount of Java 5 features and language changes. In summary, Retroweaver supports [1]: * generics * extended for loops * static imports * autoboxing/unboxing * varargs * enumerations * annotations Therefore, our development philosophy will be to take _full_ advantage of Java 5, but provide a working jar for Java 1.4, however, we can't guarantee every Struts Action 2.0 feature will be available to Java 1.4 users. -- [ ] +1 Make Java 5 the target [ ] +0 I am fine with this move, but I'll still mainly interested in 1.4 [ ] -0 I am not too keen, because ... [ ] -1 I am against this move, because ... -- I'll tally the votes after at least 72 hours and include the count in our STATUS file. The vote is open to anyone. Don [1] http://retroweaver.sourceforge.net/documentation.html - 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]
Re: Proposal for change
On 4/24/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: I look forward to feedback. Thanks for listening! Without commenting on the merit of the proposal itself, or the reasoning presented as its justification, it is important to note that we (the Struts community) do not have free reign to do whatever we want in this regard. As part of Apache, the Struts community is accountable to the Apache Software Foundation's Board of Directors, and one of the things that gets watched is how well the various projects implement the Apache Way. And one of the key tenets of that way is how new committers get selected. Regardless of the details, anything along the general lines of what you describe would be quite different from the way Apache has grown from the very beginning to what it is today -- and it would, therefore, be looked at with a *lot* of skepticism by Apache as a whole. Trying to argue that the Apache Way is flawed, and needs to be fundamentally changed like this, does not seem likely (to me) to get much agreement Apache wide, given the ASF's history, and the success of many of its projects at building communities of committers that buy in to that culture -- and, by the way, produce some pretty popular software to boot. So what the heck is this Apache way thing? It is a culture; a way of gathering a community that interoperates ... and it can be tough at times to write down a descrption that makes sense. But [1] is a pretty good starting point. I'd also recommend looking through the documentation for the Incubator Project (where a specific exit criteria is that the folks participating in the new project get it about the Apache way). Frank Craig [1] http://www.apache.org/foundation/how-it-works.html PS: If you like the code but don't like the community, one of the best things about Apache is that the license gives you the right to fork and build your own community, operated according to whatever rules please you. So, even if a proposal like this is not accepted, you still have the opportunity to go build a better Struts -- that doesn't have to be done here.
Re: Proposal for change
On 4/24/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: * Rationale One of the issues that a number of people seem to have with the way Struts has progressed is the seeming inability (or difficulty at least) of getting new blood involved. There seems to be a perception by many that there is a bit of a closed club mentality with regard to being invited in as a committer and that the Struts community at large has no say in the matter. The latter statement is, as mentioned in my previous response, the way that *all* projects at Apache work -- it is not unique to Struts. Any claim that all of Apache is broken in this regard is going to be, umm, unlikely to be agreed with :-). What's more interesting is to examine the former statement, and compare it to the facts. The Who We Are page[1] lists the current folks who are on the PMC (and also have committer privileges), and who are committers not on the PMC. There's 14 and 13 names, respectively, giving a total of 27 (and this doesn't count the 10 previous committers who are now on the emeritus list, for a total of 37). That's a pretty good size number, compared to the average at Apache. But what is really interesting is to look at the timing of how we got from one committer (me) six years ago, to where we are today -- and focus especially on the more recent changes. In just the last year there have been quite a number of new committers added[2] ... six independent of the WebWork merger (Wendy, Gary, Greg, Shawn, Laurie, and Richard), two more (Jason and Patrick) directly because of the merger, and five more who have commit rights to the WebWork incubator code and will become Struts committers as soon as it graduates. There is also one outstanding invitation that, for personal reasons fo the individual involved, will be accepted later rather than now. That is a pretty large percentage increase for a single year, even discounting the merger -- and have you ever seen other competing communities come together like this? Hmm ... doesn't seem like the existing community is particularly closed to new blood to me. Examining how the new folks got themselves nominated and elected is also interesting. In every case, it was based on continuous contributions of code, documentation, user list help, build script maintenance, or whatever made a *positive* difference for everyone. Indeed, if you go back to the days when folks like Ted and Martin were added, a lot of it was being tired of applying all the patches they were contributing :-). All of these folks get it -- so it is not just a couple of dictatorial snobs sitting on top of the mountain dictating who is in and who is out :-). There is also another interesting observation here -- you don't have to be a committer to initiate changes to the Struts code base. What you have to do is justify your bugfix or RFE to the point where an existing committer is willing to take responsibility for cleaning up any messes that committing the change might cause. So, you only have to convince one of the various folks to get your patch in. Failure to succeed in that goal *could* be a close minded community, but it also just might be that the proposed change doesn't fit with what the committers as a whole have in mind (it only takes one commiter -1 to make a committed change get reversed, so we pay attention to this as part of the decision process on accepting a patch). Just in the little time I have had to spend on Struts in the last year, I've committed patches from at least 20 different people. Spread across the six years that Struts has existed, and all the committers who have done the same thing, we are talking many *hundreds* of people who have contributed at least some code or documentation to what is now Struts. I just don't buy the presumption that the current system is broken. I won't presume to convince *you* to think that way -- it's your perogative to think whatever you want -- but I will certainly take into account whether someone gets it before I would ever vote for them to be a committer. Fortunately for those who either don't, or don't want to, buy into this, the Apache license gives you the freedom to take the code and go start your own community, operating according to your own rules, if you don't like the way things work here. But you are starting from a rationale that does not match the objective facts, so I'm not even going to be interested in trying to hash out details of how to change something that does not need to be changed. Craig [1] http://struts.apache.org/volunteers.html [2] http://struts.apache.org/announce.html
Re: Proposal for change
On 4/25/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/25/06, Ted Husted [EMAIL PROTECTED] wrote: Actually, there are three public lists. * user@ for helping people use the product * dev@ for discussing changes to the product * commit@ for logging changes to the product Right now, we have the issue trackers and wiki posting to dev@, but I sometimes wonder if it would be cleaner to have all the automatic posts going to commit@, especially if we are going to be hooking forums up to the lists. I was wishing for that today as I set up filters to get all the JIRA messages out of my struts-dev label. IIRC this has been suggested before. :) What about issues@ rather than directing them to commits@ (which they really aren't)? FWIW, this (four lists) is what the ADF Faces incubator podling chose (dev,user,issues,commits). There's actually yet one more category of automated messages (wiki changes), but I suspect the volume of those is low enough not to bother anyone. -- Wendy Craig
Re: Proposal for change
On 4/25/06, Patrick Lightbody [EMAIL PROTECTED] wrote: Any chance that as you discuss this there would be a move to make dev@ not receive all commit@ messages? Some of us (me) prefer to use RSS and forcing the emails seems a bit heavy handed. I've historically been a holdout on this issue (based on the philosophy that anyone who is interested in the development of a project should be watching the commit messages too, and having separate lists for commit messages makes it too easy to ignore those), but I'd be ok with separate lists if the majority of the commiters want it that way. Craig
Re: [PROPOSAL] Separate lists for notifications vs. discussion
On 4/25/06, Wendy Smoak [EMAIL PROTECTED] wrote: To make it easier to filter and sort messages, and to facilitate presenting the lists through alternate interfaces such as forums and RSS feeds, I propose that we do the following: * establish [EMAIL PROTECTED] and direct JIRA emails to it * unsubscribe [EMAIL PROTECTED] (svn commit messages and Wiki diffs) from dev@ Initially, the subscriber lists for these two could be copied from dev@, so that current subscribers are not affected. (Except for possibly needing to reconfigure mail filters.) +1 on both suggestions. I can appreciate Don's concerns about the issues list, but I would still like people to have the option to receive all commits on *all* JIRA projects related to the Struts community, without having to manually subscribe to each project individually. If someone is interested in only one project, they can of course ignore the issues list and subscribe to that JIRA project directly. Thanks, -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to keep feature changes on the front burner (Re: This has gone too far.)
On 4/26/06, Don Brown [EMAIL PROTECTED] wrote: Craig McClanahan wrote: On 4/26/06, Don Brown [EMAIL PROTECTED] wrote: I'd like to see tickets become the ultimate tracker, including collecting votes. I see it working this way: - any significant change requires a ticket - a committer reviews the ticket and decides on a fix version or rejects it outright - discussion ensues on the ticket, _not_ on the dev list - a vote is called for on the ticket if necessary - the release manager must resolve or move the ticket before rolling a release This approach allows for considerable debate, however ensures the ticket will ultimately be dealt with in some fashion. I agree Struts has been very good about fixing bugs, however, we need to extend that same courtesy to other tickets. I know not all agree my philosphy, but I think a ticket requires a clear decision on the part of the committers. If it is to be accepted, give it a fix version. If we think it is interesting, but aren't willing to commit to it, mark it TBD or Future. If we don't agree, reject it. What we've missed is the first step: giving it a fix version, leaving all the enhancement tickets to wallow around, waiting for attention. WebWork has been very good about following this approach, and I think it is something we should adopt. I can buy into this in general, but do not think we want to completely give up on lazy consensus either -- it should be fine for a committer to go ahead and commit a change (at least up to a certain size -- judgement call here) without waiting for another committer to agree. If there is objection later, these things can generally be backed out. Sorry, I didn't mean to imply we were removing lazy consensus. Didn't think so, but just wanted to make sure. Tickets can be opened, fix version assigned, and closed in the same day. They still will be subject to a review by the release manager at release, however. I'm just saying we should be using tickets to track these changes and give a clear place for their discussion and later reference. +1. Don Craig
Re: Make the site docs more generic
On 4/26/06, Don Brown [EMAIL PROTECTED] wrote: I propose we try to minimize the site content that will be in a continuous state of flux, like detailed roadmap or milestone plans, as recent wiki activity has show it to be a superior tool for development planning. I'd like to see one roadmap page with a very high level list of proposed versions and a sentence or two on their purpose. This will make them easier to maintain and be less confusing for users when they inevitably fall out of date. I'm still something of a JIRA newbie, but I agree that we should keep the content of this sort of web page *very* high level, and feature a link to the JIRA roadmap for detailed information. Don Craig
Re: closing and reopening jira issues
On 4/26/06, Don Brown [EMAIL PROTECTED] wrote: The resolved/closed question is interesting. I guess they could be resolved, but reviewed and closed by the release manager. Otherwise, I'd agree that they seem to function the same for open source projects anyways. In my day job scenario, we have the developers who commit changes switch an issue to Resolved, and then QE verifies the result and switches it to Closed. I'd hate to see us stick all of that responsibility solely on a release manager right before a release (doubt we'd ever get a volunteer to do it twice :-), but maybe we could have the release manager declare a moratorium on changes, and then have all the committers take on the task of verifying the issues that have been purported to be fixed? Don Craig Brett Porter wrote: We actually eliminated the resolve step since weren't using it independantly of resolve, however this doesn't affect the other part. I'm not exactly sure of the technical details of how we made editing possible when it was resolved/closed - but I can find out. It doesn't actually transition to any different steps in between. Cheers, Brett On 4/27/06, Don Brown [EMAIL PROTECTED] wrote: What does the end workflow look like? Do you just add a transition to resolve to the close step? Don Brett Porter wrote: Hi, I've noticed that there have been 1 or 2 mails recently on this list to reopen and close jira issues. Am I correct in assuming this is to be able to edit the fix version or other details? If this will be a regular occurrence, I recommend working with the jira admins to create a custom workflow. We've done that in Maven and it allows you to edit issues that are closed with appropriate permissions. It's a big timesaver if used responsibly. just my $A0.02 Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.2 Quality
On 4/26/06, Don Brown [EMAIL PROTECTED] wrote: Stupid HTML email editor... ignore that shale stuff :) Rats ... thought that was a very enjoyable Freudian slip :-). Craig /me is downloading the 1.3.2 build ... Don Brown wrote: The first Action 1 release since the recent reorganization, we have a Struts Action Framework 1.3.2 build to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease132 http://wiki.apache.org/struts/ShaleRelease102 the Struts Action Framework v1.3.2 test build has been completed and deployed to http://svn.apache.org/dist/struts/action/v1.3.2 http://svn.apache.org/dist/struts/shale/v1.0.2/ In my testing, I found the following issues: 1. Struts faces example webapps both don't work 2. Taglib integration tests don't work Otherwise, all the example applications worked correctly. Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. My vote is for Beta quality, as there are no unreleased dependencies, all the key example apps work correctly, and I've personally had the 1.3.x code in production for over six months without any problems. Only Beta because the docs need work and there are a few outstanding bugs in JIRA that should be addressed in the next release. - 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: Suggestion: Google Calendar for Struts
On 4/28/06, Jason Carreira [EMAIL PROTECTED] wrote: So who's account do we want to create it under? I suppose we can give permissions to multiple people to maintain calendar events and user permissions... How about if we ask the PMC Chair (Martin at the moment) to create a pseudo-account for this purpose (so that it's not tied to any particular person), and then share the password appropriately? Craig
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
On 4/28/06, Don Brown [EMAIL PROTECTED] wrote: I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. Status: http://incubator.apache.org/projects/webwork2.html [X] +1 Let's bring it in, and I'm committed to the project [ ] +0 Let's bring it in, but I won't be involved [ ] -0 I'd rather not, but I'm not involved, and here's why... [ ] -1 Let's not, and here's why... Craig
Re: [PROPOSAL] Separate lists for notifications vs. discussion
On 5/1/06, Martin Cooper [EMAIL PROTECTED] wrote: On 5/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/30/06, Brett Porter [EMAIL PROTECTED] wrote: My bad - fixed. Sorry for the inconvenience. I have also subscribed all committers to the 'allow' list for commits to save the moderators some time. Thanks, Brett! We also need to send the Wiki diffs to commits@ instead of [EMAIL PROTECTED] Is that something that someone here can fix, or do I need to open another issue with infrastructure? I know how to do this, but I don't have the perms. ;-( It seems you need either apmail or root to change it, so I guess a ticket is in order. Brett, It so happens I have apmail karma ... if you want to forward me the necessary steps I should be able to take care of this. Craig -- Martin Cooper I'll update mail.xml with the new list descriptions tonight. Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Separate lists for notifications vs. discussion
On 5/1/06, Brett Porter [EMAIL PROTECTED] wrote: Martin was the one that knew the steps - I've not done anything with the wikidiffs myself. :) Aha ... note to self ... match the names to the indent levels :-) Cheers, Brett Craig On 5/2/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/1/06, Martin Cooper [EMAIL PROTECTED] wrote: On 5/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/30/06, Brett Porter [EMAIL PROTECTED] wrote: My bad - fixed. Sorry for the inconvenience. I have also subscribed all committers to the 'allow' list for commits to save the moderators some time. Thanks, Brett! We also need to send the Wiki diffs to commits@ instead of [EMAIL PROTECTED] Is that something that someone here can fix, or do I need to open another issue with infrastructure? I know how to do this, but I don't have the perms. ;-( It seems you need either apmail or root to change it, so I guess a ticket is in order. Brett, It so happens I have apmail karma ... if you want to forward me the necessary steps I should be able to take care of this. Craig -- Martin Cooper I'll update mail.xml with the new list descriptions tonight. Thanks, Wendy - 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: [VOTE] Release the struts-parent pom v2
On 5/3/06, Wendy Smoak [EMAIL PROTECTED] wrote: We need to release version 2 of the struts-parent pom: * http://svn.apache.org/repos/asf/struts/maven/trunk/pom/pom.xml +1 Craig
Re: [action2] Public API first draft
On 5/5/06, Don Brown [EMAIL PROTECTED] wrote: It isn't about using Cocoon or building another version of it, but rather learning from others design choices and consequences. I see Struts Action 2 as a chance to quit competing and start collaborating. Merging with WebWork was the first important step, but equally important was Tim from Stripes joining the design discussion, and IMO, finding a way to leverage other project's experiences including Cocoon. The point isn't that we should do whatever Cocoon did, but there is value in learning from how they tackled a similar problem. In the end, we may go with a new abstraction layer, but it is still important to make that decision fully informed. If support for a portlet environment is a goal for SAF2, remember that there is more to it than just papering over the differences between the portlet and servlet APIs. You also have to deal at the functional level with the differences in the request processing lifecycle of the underlying container. In particular, consider the scenario where there are six portlets on the same page. One (and only one) of them will be the destination of an incoming GET or POST request (the processAction() part of the portlet lifecycle), followed by all six of them doing the render() portion of the lifecycle -- potentially simultaneously on multiple threads. Also, request attributes from the portlet that performed the processAction() are *not* carried forward to the render() call on that same portlet. JSF dealt with this by formally dividing the request processing lifecycle in two, along the same lines. (In a web application, it just calls the them serially for the one-and-only request.) That, plus the abstraction of ExternalContext, made supporting JSF in portlets pretty straightforward. It would seem that now (when API design is being discussed) would be a good time to decide if portlet support matters, and (if it does) to take the lifecycle differences into consideration in the design. Don Craig
Re: [action2] Leveraging known constructs (was Public API first draft)
On 5/5/06, Joe Germuska [EMAIL PROTECTED] wrote: That doesn't reference either of those interfaces -- but I think the JSTL behaves very unpredictably given objects that implement both interfaces. I can't remember the specifics, but since the syntax for indexing list elements as well as map keys is the same, it just breaks down. It is certainly possible for an implementation of EL evaluation to be broken, but the specs have always been explict about what to do in this scenario ... check for mapiness before you check for listiness. Craig
Re: [action2] Public API first draft
On 5/5/06, Don Brown [EMAIL PROTECTED] wrote: These are very good points. How does JSF handle the multiple renders? For the implementation questions below, my answers are based on the jsf-portlet bridge code in the RI's java.net project. AFAICT, the implementations inside MyFaces and the portals.apache.org bridges project are pretty similar, but might not be identical. The JSF lifecycle is implemented by a single portlet with the two standard lifecycle methods. The portlet container calls processAction() for the portlet that processes the form post, which is mapped to a call to JSF's Lifecycle.process() method. This in turn triggers the Restore View through Invoke Application phases of the standard JSF lifecycle (in action framework terms, that is everything up to and including calling the action method). Then, the portlet container will call render() on the JSF portlet for *every* portlet on the page, which gets mapped to a call to JSF's Lifecycle.render() method, which does the Render Response phase of the lifecycle (i.e. the moral equivalent of forwarding to the JSP page that you navigated to). The net effect is that one portlet runs through both phases of the portlet lifecycle, while all the other portlets only run through the rendering phase. Do you have to ensure your backing bean is session scoped? Wouldn't a request scope mean the data would be lost at the end of the processAction()? Yes, you would lose request attribute data at the end of processAction() -- the container is explicitly prohibited from carrying them forward. But, when you think about it, this actually makes sense. A portlet *always* needs to be prepared to rerender its current state, because it might not be the one that receives the next GET or POST request, so it needs to save enough state information (in session scope or cookies or ...) to make that possible. There's one other subtlety to sessions in portlets -- it turns out there are two kinds. You can have session attributes in portlet scope (specific to a particular instance of a particular portlet) or in applicaton scope (per user, like a servlet session). The former is useful for the kind of state saving referenced above, while the latter is used the same way we use session scope in webapps. The point here, though, is we'd need to decide whether or not to expose both concepts in an abstraction API (JSF did not, and I'm not sure this was the right long term choice.) How would you expect a portlet lifecycle to be supported with a stateless Action-based framework? I would think we'd want to support some explicit notion of a setup phase right before rendering, and a cleanup phase afterwards. That way, you can do things like open a Hibernate session and do a query that's needed to populate a table, then clean up the session afterwards. (JSF makes this possible with before phase and after phase' event listeners, while Shale exposes these concepts directly as callbacks to the prerender() and destroy() methods on your backing bean if it implements ViewController.) With this structure, the Action framework would actually have two controllers in a portlet environment ... one for the processAction() part and one for the render() part. In a webapp, it would all be just one, essentially concatenating the processing steps. We would also want some sort of environment-independent action context object that was implemented differently for the two environments, but that seems likely to be desireable anyway. Don Craig
Re: [action2] Public API first draft
On 5/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: Therefore, I personally consider JSR-168 a big mistake, and I would prefer it to die peacefully. Consider the way the world was before JSR-168 happened ... every portal server had their own completely different API for building portlets, and bunches of folks who come out the web application world think that almost portlet solutions[1] are enough -- seemingly without caring that they just added yet another incompatible API to the mix :-) Michael. Craig [1] http://www.theserverside.com/news/thread.tss?thread_id=40274
Re: [action2] Public API first draft
On 5/5/06, Jason Carreira [EMAIL PROTECTED] wrote: I would think we'd want to support some explicit notion of a setup phase right before rendering, and a cleanup phase afterwards. That way, you can do things like open a Hibernate session and do a query that's needed to populate a table, then clean up the session afterwards. (JSF makes this possible with before phase and after phase' event listeners, while Shale exposes these concepts directly as callbacks to the prerender() and destroy() methods on your backing bean if it implements ViewController.) We can do this with interceptors. Since each phase will have it's own action, the interceptors will wrap the entire call from the portlet dispatcher... I don't think there's a way to do something like keep a Hibernate session open across the processAction() and render() calls, though. The only way I can think of to do this would be an egregious hack using static variables or something ... not a good idea. But you could certainly use interceptors to keep one Hibernate session open for the processAction() part, and a different session open for the render() part. Indeed, because the latter would be read only you'd likely want to do this anyway so that any locks from the processing part would have been released a little earlier. Craig With this structure, the Action framework would actually have two controllers in a portlet environment ... one for the processAction() part and one for the render() part. In a webapp, it would all be just one, essentially concatenating the processing steps. We would also want some sort of environment-independent action context object that was implemented differently for the two environments, but that seems likely to be desireable anyway. Or more... I think WebWork's support is one of the few to support the other portlet states like minimized. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317messageID=57318#57318 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Messages Round II (was Leveraging known constructs (was Public API firs
On 5/5/06, Jason Carreira [EMAIL PROTECTED] wrote: Yeah, I generally like it, but I still prefer the more obvious addError(), addWarning(). I like my methods as verbs... makes reading the code easier (to me). I can see how verbs make the code easier to *read*, but not sharing a common prefix like add makes the code easier to *write*, especially if your favorite editor does code completion ... Craig
Re: [VOTE] Struts Action Framework v1.3.3 Quality
On 5/7/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Struts Action Framework 1.3.3 Test Build is available to evaluate for release quality. The release plan is available on the wiki: http://wiki.apache.org/struts/StrutsActionRelease133 The test build, including signatures and checksums, has been deployed to: http://svn.apache.org/dist/struts/action/v1.3.3 In addition, all jars, webapps, sources and javadocs are available in Apache's Maven snapshot repository under groupId 'org.apache.struts.action'. http://cvs.apache.org/maven-snapshot-repository Known issues: * struts-faces-example2 does not work The Specification-Title entry in the manifest for many (all?) of the generated JAR files is corrupted. The struts-faces-example2 app is not initializing when deployed, failing on a ClassNotFoundException for the MyFaces startup class. In turn, this is because the MyFaces implementation library (myfaces-impl-1.0.9.jar) is not being included in the WEB-INF/lib directory (as it is on the first example app). I'll see if I can fix this, if no one else beats me to it. Looks like it's probably a missing dependency in the POM, because there are a few other missing JAR files that the MyFaces impl would be declaring. Separately, I'll file RFE requests to update to a more recent MyFaces build, but that will also require ensuring that the struts-faces library works with it. Craig Once you have had a chance to review this test build, please respond with a vote on its quality: [ ] Alpha [ ] Beta [ ] General Availability (GA) We welcome votes from all community members, however, only the votes of Struts PMC members are binding. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.3 Quality
On 5/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: The struts-faces-example2 app is not initializing when deployed, failing on a ClassNotFoundException for the MyFaces startup class. In turn, this is because the MyFaces implementation library ( myfaces-impl-1.0.9.jar) is not being included in the WEB-INF/lib directory (as it is on the first example app). I'll see if I can fix this, if no one else beats me to it. Looks like it's probably a missing dependency in the POM, because there are a few other missing JAR files that the MyFaces impl would be declaring. I had some time to do further digging in on this one, and have made some progress (I'm at the JAX conference, but my talks are all tomorrow and most of the sessions today are in German, which does me little good :-). I've got a patch prepared (see below) that cleans up most of the issues. In brief, it does the following: * Restore FacesTilesRequestProcessor.java to the build, after making processValidate() throw InvalidCancelException (see below for more on this issue). * Correct dependency issues in the pom.xml for the second example. * Correct references to the tiles TLD file to use the canonical URL (but there's an outstanding problem here). * Correct struts-config.xml to load the internal copies of the validator-rules.xml resource. * Make struts-tiles a compile time dependency for faces. I can commit these to the trunk anytime it won't disrupt trying to get a release out. However, these changes do not completely address everything. The second faces example will still fail, for at least two reasons: * The missing DTD files in struts-tiles-xxx.jar that Jurgen Zimmerman reported. * The fact that META-INF/tld/struts-tiles.tld is *also* missing from this jar file. It looks like Maven's resource copying process is not recursive by default, so perhaps it's missing this due to the nested tld directory? The only problem I have with the attached patch is the change to the processValidate() method signature -- adding InvalidCancelException as a *checked* exception makes it impossible to write a single version of the struts-faces library that supports both 1.2 and 1.3. Worst case, we can probably branch the faces sources and create a variant that works there (potentially acceptable because the faces library hasn't ever had a GA release) -- but would you guys also consider making this an unchecked exception instead of a checked exception? That way, it would not need to be added to the throws clause, and wouldn't break compilation on FacesTilesRequestProcessor. Craig Index: faces/src/main/java/org/apache/struts/faces/application/FacesTilesRequestProcessor.java.bak === --- faces/src/main/java/org/apache/struts/faces/application/FacesTilesRequestProcessor.java.bak (revision 404950) +++ faces/src/main/java/org/apache/struts/faces/application/FacesTilesRequestProcessor.java.bak (working copy) @@ -1,465 +0,0 @@ -/* - * Copyright 2002,2004 The Apache Software Foundation. - * - * Licensed under the Apache License, Version 2.0 (the License); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an AS IS BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - */ - -package org.apache.struts.faces.application; - - -import java.io.IOException; -import javax.faces.FactoryFinder; -import javax.faces.application.ViewHandler; -import javax.faces.component.UICommand; -import javax.faces.component.UIComponent; -import javax.faces.context.FacesContext; -import javax.faces.context.FacesContextFactory; -import javax.faces.event.ActionEvent; -import javax.faces.lifecycle.Lifecycle; -import javax.faces.lifecycle.LifecycleFactory; -import javax.servlet.ServletException; -import javax.servlet.http.HttpServletRequest; -import javax.servlet.http.HttpServletResponse; -import org.apache.commons.logging.Log; -import org.apache.commons.logging.LogFactory; -import org.apache.struts.Globals; -import org.apache.struts.action.Action; -import org.apache.struts.action.ActionForm; -import org.apache.struts.action.ActionForward; -import org.apache.struts.action.ActionMapping; -import org.apache.struts.config.FormBeanConfig; -import org.apache.struts.config.ForwardConfig; -import org.apache.struts.faces.Constants; -import org.apache.struts.faces.component.FormComponent; -import org.apache.struts.tiles.TilesRequestProcessor; - - -/** - * pConcrete implementation of codeRequestProcessor/code that - * implements the standard Struts request processing lifecycle on a - * request that was received as an codeActionEvent/code by our
Re: [VOTE] Struts Action Framework v1.3.3 Quality
On 5/8/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: The struts-faces-example2 app is not initializing when deployed, failing on a ClassNotFoundException for the MyFaces startup class. In turn, this is because the MyFaces implementation library ( myfaces-impl-1.0.9.jar) is not being included in the WEB-INF/lib directory (as it is on the first example app). I'll see if I can fix this, if no one else beats me to it. Looks like it's probably a missing dependency in the POM, because there are a few other missing JAR files that the MyFaces impl would be declaring. I had some time to do further digging in on this one, and have made some progress (I'm at the JAX conference, but my talks are all tomorrow and most of the sessions today are in German, which does me little good :-). I've got a patch prepared (see below) that cleans up most of the issues. In brief, it does the following: * Restore FacesTilesRequestProcessor.java to the build, after making processValidate() throw InvalidCancelException (see below for more on this issue). * Correct dependency issues in the pom.xml for the second example. * Correct references to the tiles TLD file to use the canonical URL (but there's an outstanding problem here). * Correct struts-config.xml to load the internal copies of the validator-rules.xml resource. * Make struts-tiles a compile time dependency for faces. I can commit these to the trunk anytime it won't disrupt trying to get a release out. However, these changes do not completely address everything. The second faces example will still fail, for at least two reasons: * The missing DTD files in struts-tiles-xxx.jar that Jurgen Zimmerman reported. * The fact that META-INF/tld/struts-tiles.tld is *also* missing from this jar file. It looks like Maven's resource copying process is not recursive by default, so perhaps it's missing this due to the nested tld directory? The only problem I have with the attached patch is the change to the processValidate() method signature -- adding InvalidCancelException as a *checked* exception makes it impossible to write a single version of the struts-faces library that supports both 1.2 and 1.3. Worst case, we can probably branch the faces sources and create a variant that works there (potentially acceptable because the faces library hasn't ever had a GA release) -- but would you guys also consider making this an unchecked exception instead of a checked exception? That way, it would not need to be added to the throws clause, and wouldn't break compilation on FacesTilesRequestProcessor. Firstly FacesRequestProcessor has had the InvalidCancelException added to the processValidate() method signature, so you probably want to consider that as well: http://svn.apache.org/viewcvs.cgi?rev=392070view=rev Yah, that is probably a compelling enough reason to make the change here as well, for consistency. The problem is that Struts 1.2.9 has been released with the processValidate() method declaring the InvalidCancelException exception. This does at least mean that if you do add InvalidCancelException to the method signature then it can be used with 1.2.9+ versions. If not and you still think changing it to an unchecked exception is the best approach, then it would need a new 1.2.x release. The only solution I can see that accomodates all versions though is to remove the implementation of the processValidate() method from the faces RP implementations - since all they do is debug logging - this would seem a good approach IMO. OK, if it doesn't invalidate *all* of the 1.2 releases, then it's much less important to try to change this. Upgrade to 1.2.9 is going to be much more palatable than upgrade to 1.3.x even after 1.3 goes GA. Maybe a bigger issue though is that faces doesn't really support 1.3 at all - since it relies on the existing RP - rather than providing a set of Commands to plug into the ComposableRequestProcessor. More precisely, it relies on 1.3 continuing to provide legacy support for the old RP approach :-). But your point is well taken -- the 1.3 version of the library should definitely be rearchitected to use CRP. I'll put in an RFE for that. Niall Craig Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Stupid Maven Question
I notice that, when a release manager is cutting a new release, she or he
has to update the version element of all the dependent pom.xml files (in
the recent case, from 1.3.3-SNAPSHOT to 1.3.3, and then from 1.3.3 to
1.3.4-SNAPSHOT). Since these poms all inherit from a parent pom that has
the version number in it, is it possible to use ${pom.version} in all the
child poms as well, to avoid having to change this in more than one place?
Craig
Re: Struts-Faces: Is this a bug?
On 5/9/06, A. Alonso Dominguez [EMAIL PROTECTED] wrote:
Hi there!
I'm trying to use the new struts-action framework, version 1.3.3 with
tiles
and faces. I'm following the example applications but I found possibly a
bug
when rendering a struts-based FormBean.
The jsp code that I was using is as follows:
s:errors /
s:form action=/login id=login styleClass=loginForm
focus=username
h:panelGrid columns=2
f:facet name=header
h:panelGroup
h:graphicImage
url=/common/skin/social-labs/img/circle1.png
/
s:message key=page.logon.form
f:param name=arg0 value=Social Labs /
/s:message
/h:panelGroup
/f:facet
h:outputLabel for=username
s:message key=form.logon.username /
/h:outputLabel
h:inputText id=username size=25 value=#{logonForm.username}
/
h:outputLabel for=password
s:message filter=false key=form.logon.password /
/h:outputLabel
h:inputSecret id=password size=25 value=#{logonForm.password}
/
f:facet name=footer
h:commandButton id=submit type=SUBMIT styleClass=img
image=/common/skin/social-labs/img/login.png /
/f:facet
/h:panelGrid
/s:form
but when it's rendered to the view, the HTML form's action attribute
references /common/skin/default/layout/base.do. There is not any action
in
my application with that url. Instead there is a file
/common/skin/default/layout/base.jsp which is the base file for the
tiles
definitions:
definition name=base.layout
page=/common/skin/default/layout/base.jsp
put name=title value= /
put name=navigation value= /
put name=body value= /
putList name=scripts
add value= /
/putList
/definition
I dived inside the org.apache.struts.faces.renderer.FormRenderer code
and
I found this code (line 280):
protected String action(FacesContext context, UIComponent component) {
String actionURL =
context.getApplication().getViewHandler().
getActionURL(context, context.getViewRoot().getViewId());
if (log.isTraceEnabled()) {
log.trace(getActionURL( + context.getViewRoot().getViewId()
+
) -- + actionURL);
}
return (context.getExternalContext().encodeActionURL(actionURL));
}
which really does nothing with the actionURL, It just takes de ViewRootId
and returns it to the caller.
Playing with this code I have now the following:
protected String action(FacesContext context, UIComponent component,
ModuleConfig moduleConfig) {
//String actionURL =
//context.getApplication ().getViewHandler().
//getActionURL(context, context.getViewRoot().getViewId());
FormComponent form = (FormComponent) component;
String actionURL = context.getApplication().getViewHandler().
getActionURL(context, moduleConfig.getPrefix() +
form.getAction());
if (log.isTraceEnabled()) {
log.trace(getActionURL( + context.getViewRoot().getViewId()
+
) -- + actionURL);
}
return (context.getExternalContext().encodeActionURL(actionURL));
}
I don't know if this is the correct way for retrieving the real actionURL
but It works now and I'm using it.
Should this be posted as a bug??
Yes, this does sound like a bug. Could you please file an issue on it,
using project name Struts Action 1 and component Faces?
http://issues.apache.org/struts/
Craig
Re: [PROPOSAL] Separate lists for notifications vs. discussion
On 5/11/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/1/06, Martin Cooper [EMAIL PROTECTED] wrote: On 5/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: We also need to send the Wiki diffs to commits@ instead of [EMAIL PROTECTED] Is that something that someone here can fix, or do I need to open another issue with infrastructure? I know how to do this, but I don't have the perms. ;-( It seems you need either apmail or root to change it, so I guess a ticket is in order. ... It so happens I have apmail karma ... if you want to forward me the necessary steps I should be able to take care of this. Martin and Craig, do you think you can make this change? If not, let me know and I'll open an issue with infrastructure. I tried to do this, but my apmail karma only works on the mail server, not on minotaur where this particular file needs to be edited. It will be necessary to file an infra issue for it, although I suspect they'll consider things like getting SVN back up to be more important right at the moment :-). -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/11/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/11/06, Niall Pemberton [EMAIL PROTECTED] wrote: I have taken some time to check out the 1.3.4 version today - upgrading my webapp to this version (was on 1.2.9) and the only other issue(s) I came up with is that we used to distribute things like the validator-rules.xml config and taglib tlds in the lib directory. I releaize that these are now all packaged in the jar and the distro does include the source - but I expect quite a few people will still have these manually configured and will have difficulty finding them in the distro. First, thank you for taking the time to review 1.3.4. I really appreciate it. I thought about including those resources, and decided against it. They were not in the 1.3.0 'lib' distribution, either. I'm willing to answer the questions on the user list, and I think we should encourage people to configure their apps to use the latest versions of the resources that we've provided in the jar files. +1 on the recommended configuration approach (use the canonical URLs instead of references to explicit resources in WEB-INF). Since we now require Servlet 2.3, there's little reason to configure tlds in web.xml, and there's no reason to keep a copy of validator-rules.xml in WEB-INF when it can be loaded from struts-core.jar. We can include them in 'lib' in the next distribution if more people disagree. (But as you pointed out, they are included with the source.) I think we should include the DTDs in some convenient place like lib in the distro in *addition* to the previous comments on recommended configuration practices. There's lots of documentation about valid options in the DTD documents themselves that is not reproduced anywhere else. It should be as easy as possible to get to these files for *reading* them, not just for using them in an app. Craig
Re: [OT] reading resources from nested JARs (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/11/06, Joe Germuska [EMAIL PROTECTED] wrote: At 10:50 AM -0700 5/11/06, Michael Jouravlev wrote: I think it is much cleaner to have DTDs and other default XML files in the JAR, but sometimes it might not work. The hosting that I use for the samples, uses Tomcat 4.x, which supposedly should support SRV 2.3 and therefore it should be able to pull DTDs from classpath. Yet, this does not work, I don't know exactly why. But if I put DTD files into lib directory and configure them in web.xml then everything works fine. Do you deploy your webapps as WARs? We often find ourselves bumping up against something when we need to read classpath resources from a JAR within another JAR; in fact, this is why we don't deploy webapps as WARs, and we've also had similar problems with the classworlds uberjar mechanism which makes JARs for standalone execution along a model similar to WARs. Has anyone ever seen formal documentation of this issue? We've always just worked around it. The particular version of Tomcat used by this hosting provider is broken ( i.e. it has bugs) with reference to this issue -- it is supposed to work. And I know from experience it works correctly on 5.0.x versions. Craig The bottom line, it is better to hide DTDs in the JAR, but in case it does not work a readily available HOW-TO should be provided. Indeed. -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SAF1 - Struts-Faces] s:loadMessages / can't load the correct MessageResources in a multimodule webapp
On 5/12/06, A. Alonso Dominguez [EMAIL PROTECTED] wrote:
Hi there,
I think that there is a bug in the implementation of the
org.apache.struts.faces.taglib.LoadMessagesTag. When working in a
multimodule webapp with several messages-resources / per module, the
s:loadMessages / tag can't find the appropiate MessageResources instance
via messages attribute.
The reason for this is the way that the tag uses to locate the appropiate
MessageResources instance. This code explains it (line 76):
public int doStartTag() {
// Acquire the Locale to be wrapped
Locale locale =
FacesContext.getCurrentInstance().getViewRoot().getLocale();
// Acquire the MessageResources to be wrapped
MessageResources messages = null;
if (this.messages == null) {
messages = (MessageResources)
pageContext.getAttribute(Globals.MESSAGES_KEY,
PageContext.REQUEST_SCOPE);
if (messages == null) {
messages = (MessageResources)
pageContext.getAttribute(Globals.MESSAGES_KEY,
PageContext.APPLICATION_SCOPE
);
}
} else {
messages = (MessageResources)
pageContext.getAttribute(this.messages,
PageContext.REQUEST_SCOPE);
}
// Expose a Map instance under the specified request attribute key
pageContext.setAttribute(var,
new MessagesMap(messages, locale),
PageContext.APPLICATION_SCOPE);
// Skip the body of this tag (if any)
return (SKIP_BODY);
}
As you can see, this code doesn't supports modules.
If we want to load a different bundle than the one configured as the
default, we must use the messages attribute but this code tries to load
that MessageResources instance from the APPLICATION_SCOPE rather that
search
for it inside the REQUEST_SCOPE.
In a multimodule webapp the MessageResources instances are loaded on
startup
inside the APPLICATION_SCOPE with the key:
org.apache.struts.action/MESSAGE + [modulePrefix]
If we have more than one MessageResources instance per module the will be
loaded with the key:
[bundleKey] + [modulePrefix]
So, the above code can't load any of those kind of messages resources.
This
can be solved easily:
public int doStartTag() throws JspException {
// Acquire the Locale to be wrapped
Locale locale =
FacesContext.getCurrentInstance().getViewRoot().getLocale();
ModuleConfig modConfig = ModuleUtils.getInstance
().getModuleConfig(
(HttpServletRequest) pageContext.getRequest(),
pageContext.getServletContext());
// Acquire the MessageResources to be wrapped
MessageResources messages = null;
if (this.messages == null) {
messages = (MessageResources)
pageContext.getAttribute(Globals.MESSAGES_KEY,
PageContext.REQUEST_SCOPE);
if (messages == null) {
messages = (MessageResources)
pageContext.getAttribute(Globals.MESSAGES_KEY +
modConfig.getPrefix(),
PageContext.APPLICATION_SCOPE
);
}
} else {
messages = (MessageResources)
pageContext.getAttribute(this.messages,
PageContext.REQUEST_SCOPE);
if(messages == null) {
messages = (MessageResources)
pageContext.getAttribute(this.messages +
modConfig.getPrefix(),
PageContext.APPLICATION_SCOPE
);
}
}
if(messages == null)
throw new JspException(MessageResources bundle +
this.messages + not
found);
// Expose a Map instance under the specified request attribute key
pageContext.setAttribute(var,
new MessagesMap(messages, locale),
PageContext.REQUEST_SCOPE);
// Skip the body of this tag (if any)
return (SKIP_BODY);
}
Should I open a new issue about this?
Yes please ... this is not an issue (pardon the pun :-) that I was aware of.
http://issues.apache.org/struts/
Alonso
Craig
Re: [PROPOSAL] Separate lists for notifications vs. discussion
On 5/12/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: I tried to do this, but my apmail karma only works on the mail server, not on minotaur where this particular file needs to be edited. Done. http://issues.apache.org/jira/browse/INFRA-802 Thanks ... I meant to do that, but got distracted by preparations for a demo I'm going to do in the Tuesday keynote next week. It'll be a fun one ... you'll want to make sure you see it :-) -- Wendy Craig
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/13/06, Ted Husted [EMAIL PROTECTED] wrote: On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: [ ] Alpha [X] Beta [ ] General Availability (GA) I would prefer that we resolve the DTD issue before marking a distribution ready for primetime. I agree ... and vote for beta as well. But we should spend some more time testing to see if there are any other lurking ghosts before we send Wendy off on yet another cycle through the release plan process. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts Action Framework v1.3.4 Quality
On 5/13/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/13/06, Ted Husted [EMAIL PROTECTED] wrote: I would prefer that we resolve the DTD issue before marking a distribution ready for primetime. I agree ... and vote for beta as well. But we should spend some more time testing to see if there are any other lurking ghosts before we send Wendy off on yet another cycle through the release plan process. I see two choices. Make the two-line change to XmlParser and roll 1.3.5 immediately with *only* that change, or wait a while and see if anything else comes up. I'm trying to find the motivation for Plan A. Because if we do that, and no one objects to calling the vote immediately... we could count the vote in time for Don's talk on Wednesday. Plan B assumes that people are going to continue to test 1.3.4, and I don't know how likely that really is. Right now I just feel like I'm going to make someone unhappy, no matter what I do. Or don't do, as the case may be. I hope that I wasn't implying I would be unhappy if you were *willing* to roll 1.3.5 immediately ... that'd be fine. However, I would be unhappy with all of us other committers if we stopped testing 1.3.4 at all, until 1.3.5became available, and we surface yet another two line change next week. Where, by the way, I suspect you'll be pretty busy :-). But if you want to go for it, I'm game -- can do a small bit of testing on Monday. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Process thoughts (Re: [VOTE] Struts Action Framework v1.3.4 Quality)
On 5/16/06, Ted Husted [EMAIL PROTECTED] wrote: On 5/16/06, Don Brown [EMAIL PROTECTED] wrote: I think the solution is to: 1. Make betas publicly available and widely known like our 1.1 betas were +1 I think the notion that we can't announce and mirrors Betas is a misunderstanding. We can mirror an announce *any* release, even an Alpha. Announce and mirror are two different things. IIRC, Apache's general guidelines on mirror are GA releases only (although we've probably been among the folks that bypassed that policy on occasion). Sorry not to have time (here at JavaOne this week) to do the historical research to back this up, hence the disclaimer that this might be my foggy memory. Craig
Re: [action2] Combining JSF and SAF2
On 5/21/06, Kito D. Mann [EMAIL PROTECTED] wrote: Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This will allow SAF2 developers to work with JSF components (and the market is growing nicely). I wonder how well Shale will run in this context... Don and I had a chance to chat about this idea last week at JavaOne (glad to see the phase listener strategy worked out so well :-). You'll want to look at SAF2+JSF for cases where you've got a primarily action controller driven application architecture, but where you want to use some really cool JSF components here and there on your pages -- without *having* to convert the entire page to use components. You'll be able to do that, without throwing away all the rest of your architecture (but you won't be leveraging anything in JSF other than the components). If you're building an app around the JSF controller (perhaps because you like the JSF approach to navigation, or its lifecycle), on the other hand, you'd be better off starting with JSF+Shale. Just to make things a bit more interesting, several of the Struts committers got together and talked about how we can share common stuff between the two frameworks ... and some ideas that are already on the Shale roadmap[1][2] involve support for XWork interceptors in addition to (and probably ultimately preferred to) using Commons Chain to decorate the overall request lifecycle. This will likely end up being fairly similar to what Don did in terms of being able to customize each phase individually. I'll have more detailed comments when I've had a chance to dig in a little deeper. Craig [1] http://issues.apache.org/struts/browse/SHALE-108 [2] http://issues.apache.org/struts/browse/SHALE-136
Re: [shale] some improvement proposal for performance
On 5/24/06, Gary VanMatre [EMAIL PROTECTED] wrote: the following code demo an hotswap design for file change monitoring. the only limitation is that shall use getMap() first and once. map idMap = getMap(), and latter use idMap variable through an request thread. you can use weaked referenced variable and threadlocal to improve the following demo further. in clay, watchdog maybe hotswapable I think. I'm not sold on the Thread based file watch but I don't have a good handle on what types of threading are allowed. I'll go with Craig's opinion on this one. It's legal for a webapp to create threads beyond the request processing thread(s) provided by the container, so long as they do not directly or indirectly reference any request or response objects handed to any particular request. In a JSF-based app, you also need to be aware that component processing is *not* safe for multiple thread access, because it is assumed only the request processing thread will access the tree. For configuration file updating, it should be feasible to start a background thread for this kind of thing ... but I'd like to make sure that we share this kind of technology between Shale and SAF2. In particular, WebWork has some code that already exists which we can look at for this purpose. Craig
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On 5/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Thu, May 25, 2006 2:12 pm, Jason Carreira wrote: I'm still waiting to see how this plays out... I've been a big proponent of Dojo and built several Dojo widgets, but I understand that it can be tricky and not as easy to use as we'd all like. I think there'll be room for different strategies and implementations, and we'll figure it out as we go. It's been talked about here, but I don't know how much interest there might be... At this moment I'm grabbing the code I started and intend to finish it this weekend... My plan is to create 4 interceptors. Two for input and two for output, one each for XML and one each for JSON. How I envision it working is that let's say for example you want to send XML to an Action and get JSON back... ok, so you add the (a) AjaxXMLInputInterceptor and (b) AjaxJsonOutputInterceptor to the stack... On input, (a) determines (not quite sure how yet) that the request has XML in the request body. So it gets it, parses it, and sets the fields on the Action as I outlined yesterday. I would expect a well-behaved client to set the content type on the incoming request to text/xml for XML content, so you should be able to check that. Likewise, isn't JSON content supposed to be sent with text/javascript? On output, (b) takes the Action and generates JSON from its fields. And you should, of course, set the correct content type on the response too. Craig At least initially, the only added config is the new interceptors. There are some obvious ways to expand this, and some obvious problems, but for a first pass I think it's enough. I believe this will allow you to make Ajax calls to an Action from any Ajax code, without much of any extra work on your part. It should also allow for XML/JSON responses, at least simplistically, without any extra work. Does this sound reasonable to anyone? I'm going to go ahead and do it in any case as it is my first try at writing an interceptor, and also the first time I'm doing anything that requires even minimal internal knowledge of XW/WW, so it should be a learning experience if nothing else. I may be missing something, but it seems like it might be useful too :) Frank - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32216messageID=62655#62655 - 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: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On 5/25/06, Joe Germuska [EMAIL PROTECTED] wrote: Likewise, isn't JSON content supposed to be sent with text/javascript? actually, no, application/json text/* types are meant to be things that are more human readable, despite the historic reality of text/javascript http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-04.txt Ah ... thanks Joe. I had looked around the JSON site for an authoritative statement on this, but hadn't found this one. Joe Craig
Re: Request to publish Struts 1.3.5
On 5/28/06, Paul Benedict [EMAIL PROTECTED] wrote: Ted, I am asking about the website, not the builds. I know the developer builds are always available, but I see no reason why we shouldn't publish the 1.3.x website on the left-hand bar as we release new beta versions. We don't need a vote for that. To publish a beta release on the website, we need to put the release somewhere that the download link can point to. That really evolves down to two choices: * Link it to an Apache server (where Wendy's test build is) and suffer the wrath of the Apache infrastructure group when a huge number of people try to download it -- given how widely Struts is used, this is likely to be a very serious hit on the Apache infrastructure. * Publish the release in the usual way so that it goes to the mirror sites, to spread the download impact around the world. The first choice is totally inappropriate, and will get a guaranteed -1 from me. If we want to tell the world about a release, it needs to go out to the mirrors -- which means it needs to be published just like a GA release. *That* is when it is reasonable to link it off the website, as well as tell the user list about it. Paul Craig
Re: [shale] Maven 2 build -- Help Wanted
On 5/31/06, Sean Schofield [EMAIL PROTECTED] wrote: PS. core-library tests are now compiling although there are several failures Good news ... on further review, the test module's compile time dependency on core is really conceptual rather than actual ... there is no import that requires this. I've removed the dependency from the Ant build.xml for test-framework ... Wendy, you should also be able to update the POM now to bypass the circular dependency issue. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 build -- Help Wanted
On 5/31/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/31/06, Sean Schofield [EMAIL PROTECTED] wrote: I bet this makes the core stuff work in Creator. OK I moved it to be a subproject of core-library and for now, its not automatically being built when you build core-library (since we're missing the jars.) I also moved one of the test cases to the proper location and modified the script. Why a sub-project of core? It's a separate, optional jar, like shale-tiger. I think it belongs in shale/designtime as its own module. I agree ... and, if I understood you correctly, switching to a Maven build will require not only this, but also splitting up core into separate modules for each deliverable artifact, right? Given that, I don't see the need to create hierarchical Maven projects unless there is some compelling advantage we get on inheriting dependencies from parent poms or something. Suggestion: We need to have separate trunk for each shale subproject. core-library/trunk shale-test/trunk, etc. It will not suffice to have a single struts-shale/trunk because we want to be able to release the subprojects independently. Do you forsee us needing to release them separately? I think the single distribution with one version number is less confusing for users. Separate releases are less work individually for release managers (easier to verify, etc.,) but you end up doing more of them. But we're going to do the separation thing anyway, right, even if we don't release separately? I can certainly see a case for something like the test framework being releasable separately. We tried it briefly for Struts Action, and ended up going back to a single distribution. The only piece that I can see needing a separate release is shale-test, and even that's not causing a problem right now. It's not causing a problem now because nobody has asked for a high priority bug fix or feature enhancement, who is not also willing to wait for another Shale omnibus release. Craig, any thoughts on this one? By the way, you can clean up the circular compile dependency stuff now :-). -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 build -- Help Wanted
On 5/31/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/31/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/31/06, Wendy Smoak [EMAIL PROTECTED] wrote: Do you forsee us needing to release them separately? I think the single distribution with one version number is less confusing for users. Separate releases are less work individually for release managers (easier to verify, etc.,) but you end up doing more of them. But we're going to do the separation thing anyway, right, even if we don't release separately? I can certainly see a case for something like the test framework being releasable separately. Separate jars, yes. Now we're discussing the difference between: shale/trunk/core shale/trunk/test-framework and shale/core/trunk shale/test-framework/trunk Ah ... now I see where you're going. But even if we went the first way, couldn't you still fork from shale/trunk/test-framework to shale/branches/test-framework/1.2.3 if version 1.2.3 was actually released separately? The former implies that all the jars are versioned and released together. The latter is what Sean is suggesting, a separate trunk for each module. I can see a reason to have Clay and Test Framework on separate trunks, but I'm not so sure that spring and tiles really need a separate release cycle from core. The test framework is reorganized and building with just the Servlet API and HtmlUnit as provided and optional dependencies, respectively. http://svn.apache.org/repos/test/struts/struts-shale/trunk/test-framework/pom.xml I'm going to move designtime back out to shale/designtime. That makes sense as well ... it would not likely every be released separately. Sean, I removed the MyFaces dependency from core-library. For now, enable a profile with either -Pmyfaces or -Pjsfri depending on what you want to build with. We need to make the MyFaces profile active by default, while also being able to deactivate it to build with the RI. Sounds good. -- Wendy Craig
Re: [shale] Maven 2 build -- Help Wanted
On 5/31/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 5/31/06, Sean Schofield [EMAIL PROTECTED] wrote: Well design time is inherently linked to core. It makes no sense to release one without the other. With shale-test, you might in fact release that separately from core so if it has its own trunk and set of branches, that is easier to do. If they are always going to be released together, then one struts-shale/trunk is fine. Right now I see: shale/clay/trunk shale/test-framework/trunk shale/???/trunk/[core,tiles,spring,designtime,tiger,apps] Not sure what to call that last one: shale/shale/trunk? shale/main/trunk? What do you think? Using main works for me if we want to go this way. But, does apps really belong underneath main (I can see the logic on the rest of them)? And, do we really need this at all (versus shale/trunk/*) given that you can svn copy a branch of, say, shale/trunk/test to something like shale/branches/test/1_2_3 at any time you want to do a separate release of one component? -- Wendy Craig
Re: [shale] Maven 2 build -- Help Wanted
On 5/31/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Wendy Smoak [EMAIL PROTECTED] On 5/31/06, Sean Schofield wrote: I think the ultimate answer depends on whether we know for sure that we want separate releases. It doesn't sound like we know for sure so maybe we should just stick with one shale/trunk. For MyFaces we had as a goal to break out tomahawk from the core. But it doesn't sound like we have that strong of a reason in this case. I think there's a good argument for releasing Clay and the Test Framework separately. I have a couple more variations of the rolodex usecase example in the works. I agree that it would be good to pull Clay out of the core usecases. What ever it takes to let maven do it's magic. I would also like to setup a Clay mail reader version. Could we go ahead and add an empty maven project under the clay-plugin for this in addition to the usecases? Sounds like a good opportunity to test out Maven's archetype capabilities, if that part of the conversion is done :-). Craig Sean, why don't you go ahead and check in what you've got, and don't worry too much about recording the commands it took to get there exactly. With the test repo as a reference, we'll be able to figure it out. I don't want to lose momentum, and it's easier to discuss the project structure when there's something real to check out and look at. :) Once we agree on the overall structure, we can start moving things in the Struts svn repo, with the understanding that it may take a few days to get it all arranged and building again. After the new structuring, I could move the Clay usecase stuff out into a empty maven project. I'm a maven newbie so I'll let you guys to the new wiring :-) Gary Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 build -- Help Wanted
On 5/31/06, Sean Schofield [EMAIL PROTECTED] wrote: Sean, why don't you go ahead and check in what you've got, and don't worry too much about recording the commands it took to get there exactly. With the test repo as a reference, we'll be able to figure it out. I don't want to lose momentum, and it's easier to discuss the project structure when there's something real to check out and look at. :) Why don't we just make a struts-shale-mvn directory in the real ASF repo. Just copy the existing struts-shale? As long as there is nothing pressing (next 10 days or so) to check in, we can just work in the copy. Then when we're happy we cut delete the original and rename back to struts-shale. Ultimately I think this will be faster b/c we won't have to check in all of the poms and move everything around again. Plus we'll have the svn emails as a record if we need to replicate it. Worse case there is a crucial bug that can be fixed in the original location as well as the reorg one. That makes sense to me ... it'll be a lot easier to keep the inevitable small changes over the next few days in sync if it's all in one repository -- plus, we get the benefit of the visible audit trail courtesy of the commit emails. Thoughts? Wendy Sean Craig
Re: svn commit: r410977 - in /struts/shale/branches/mvn_reorg: core-library/src/conf/ core-library/src/designtime/ core-library/src/java/ core-library/src/main/ core-library/src/main/java/ core-librar
On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: There were a couple of commits to shale between when mvn_reorg was copied and this commit. Without looking over this file by file, I hope we aren't losing anything. I'm watching closely on the commits I'm doing, and I imagine Gary will do the same. I plan to duplicate the necessary changes once the under construction dust settes down a bit :-). Also, what's the status of the reorg? Are we supposed to still help out in the test repo? Or in mvn_reorg? Or in shale/trunk? Once Sean is done with the initial updates, we'll want to test i mvn_reorg. After we're satisfied with that, and catch up on pending commits, we'll move mvn_reorg back to the trunk and proceed from there. -- James Mitchell Craig On Jun 1, 2006, at 6:16 PM, [EMAIL PROTECTED] wrote: Author: schof Date: Thu Jun 1 15:16:48 2006 New Revision: 410977 URL: http://svn.apache.org/viewvc?rev=410977view=rev Log: committed changes in Wendy's original shale-reorg-core-01.sh script Added: struts/shale/branches/mvn_reorg/core-library/src/main/ struts/shale/branches/mvn_reorg/core-library/src/main/java/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/java/ struts/shale/branches/mvn_reorg/core-library/src/main/resources/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/conf/ struts/shale/branches/mvn_reorg/core-library/src/site/ struts/shale/branches/mvn_reorg/core-library/src/site/site.xml - copied unchanged from r410974, struts/shale/branches/ mvn_reorg/core-library/xdocs/navigation.xml struts/shale/branches/mvn_reorg/core-library/src/site/xdoc/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/xdocs/ struts/shale/branches/mvn_reorg/core-library/src/site/xdoc/xdocs/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/xdocs/ struts/shale/branches/mvn_reorg/core-library/src/test/java/ struts/shale/branches/mvn_reorg/core-library/src/test/java/org/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/test/org/ struts/shale/branches/mvn_reorg/designtime/src/ struts/shale/branches/mvn_reorg/designtime/src/main/ struts/shale/branches/mvn_reorg/designtime/src/main/java/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/designtime/ struts/shale/branches/mvn_reorg/spring/src/ struts/shale/branches/mvn_reorg/spring/src/main/ struts/shale/branches/mvn_reorg/spring/src/main/java/ struts/shale/branches/mvn_reorg/spring/src/main/java/org/ struts/shale/branches/mvn_reorg/spring/src/main/java/org/apache/ struts/shale/branches/mvn_reorg/spring/src/main/java/org/apache/ shale/ struts/shale/branches/mvn_reorg/spring/src/main/java/org/apache/ shale/spring/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/java/org/apache/shale/spring/ struts/shale/branches/mvn_reorg/spring/src/main/resources/ struts/shale/branches/mvn_reorg/spring/src/main/resources/META- INF/ struts/shale/branches/mvn_reorg/spring/src/main/resources/META- INF/faces-config.xml - copied unchanged from r410974, struts/shale/branches/ mvn_reorg/core-library/src/java/org/apache/shale/spring/faces- config.xml struts/shale/branches/mvn_reorg/tiles/src/ struts/shale/branches/mvn_reorg/tiles/src/main/ struts/shale/branches/mvn_reorg/tiles/src/main/java/ struts/shale/branches/mvn_reorg/tiles/src/main/java/org/ struts/shale/branches/mvn_reorg/tiles/src/main/java/org/apache/ struts/shale/branches/mvn_reorg/tiles/src/main/java/org/apache/ shale/ struts/shale/branches/mvn_reorg/tiles/src/main/java/org/apache/ shale/tiles/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/java/org/apache/shale/tiles/ struts/shale/branches/mvn_reorg/tiles/src/main/resources/ struts/shale/branches/mvn_reorg/tiles/src/main/resources/META-INF/ struts/shale/branches/mvn_reorg/tiles/src/main/resources/META- INF/faces-config.xml - copied unchanged from r410974, struts/shale/branches/ mvn_reorg/core-library/src/java/org/apache/shale/tiles/faces- config.xml Removed: struts/shale/branches/mvn_reorg/core-library/src/conf/ struts/shale/branches/mvn_reorg/core-library/src/designtime/ struts/shale/branches/mvn_reorg/core-library/src/java/ struts/shale/branches/mvn_reorg/core-library/src/main/java/org/ apache/shale/spring/ struts/shale/branches/mvn_reorg/core-library/src/main/java/org/ apache/shale/tiles/ struts/shale/branches/mvn_reorg/core-library/src/site/xdoc/ navigation.xml struts/shale/branches/mvn_reorg/core-library/src/site/xdoc/ xdocs/navigation.xml struts/shale/branches/mvn_reorg/core-library/src/test/org/ struts/shale/branches/mvn_reorg/core-library/xdocs/
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. One problem seems to be with AbstractJsfTestCase and a null pointer when referencing the servletContext variable from a subclass. My guess is that there is a missing configuration resource. @Craig: Any ideas? Try running mvn -Pmyfaces test and then examine the output in target. All of the necessary resource files shoudl be in the classes or test-classes dirs. If not, then we missed something. I'll pull the mvn_reorg stuff and check this out. Sean Craig On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: So I can run svn move foo/bar foo/buzz locally and then commit foo? This is the same as svn move https://foo.com/foo/bar https://foo.com/foo/buzz? Yes, exactly the same. The advantage is that you can do multiple commands locally, preview the results, and then commit all the changes at once. There are some limits, occasionally Subversion will complain that you need to commit before executing some command that you're trying to do. (Which is why that first script is separate.) Whatever is easier for you, though, it ends up being the same when you're done. -- Wendy - 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: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. One problem seems to be with AbstractJsfTestCase and a null pointer when referencing the servletContext variable from a subclass. My guess is that there is a missing configuration resource. @Craig: Any ideas? Try running mvn -Pmyfaces test and then examine the output in target. All of the necessary resource files shoudl be in the classes or test-classes dirs. If not, then we missed something. I'll pull the mvn_reorg stuff and check this out. @Sean/@Wendy: Is there any way to teach Maven to use an HTTP proxy when it does it's dependency downloads, like you can tell Subversion to? I spend most of my time connected to Sun's VPN network, and right now I have to disconnect from that to do the Maven stuff -- not fatal, but it's sure a pain. Sean Craig Craig On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: So I can run svn move foo/bar foo/buzz locally and then commit foo? This is the same as svn move https://foo.com/foo/bar https://foo.com/foo/buzz? Yes, exactly the same. The advantage is that you can do multiple commands locally, preview the results, and then commit all the changes at once. There are some limits, occasionally Subversion will complain that you need to commit before executing some command that you're trying to do. (Which is why that first script is separate.) Whatever is easier for you, though, it ends up being the same when you're done. -- Wendy - 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: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Is this what you need? http://maven.apache.org/guides/mini/guide-proxies.html Yes! Thanks ... but it leads to a stupid newbie question ... where's the user settings file go? :-) -- James Mitchell Craig On Jun 2, 2006, at 12:31 AM, Craig McClanahan wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. One problem seems to be with AbstractJsfTestCase and a null pointer when referencing the servletContext variable from a subclass. My guess is that there is a missing configuration resource. @Craig: Any ideas? Try running mvn -Pmyfaces test and then examine the output in target. All of the necessary resource files shoudl be in the classes or test-classes dirs. If not, then we missed something. I'll pull the mvn_reorg stuff and check this out. @Sean/@Wendy: Is there any way to teach Maven to use an HTTP proxy when it does it's dependency downloads, like you can tell Subversion to? I spend most of my time connected to Sun's VPN network, and right now I have to disconnect from that to do the Maven stuff -- not fatal, but it's sure a pain. Sean Craig Craig On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: So I can run svn move foo/bar foo/buzz locally and then commit foo? This is the same as svn move https://foo.com/foo/bar https://foo.com/foo/buzz? Yes, exactly the same. The advantage is that you can do multiple commands locally, preview the results, and then commit all the changes at once. There are some limits, occasionally Subversion will complain that you need to commit before executing some command that you're trying to do. (Which is why that first script is separate.) Whatever is easier for you, though, it ends up being the same when you're done. -- Wendy - 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]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: I keep mine here: ~/.m2/settings.xml That did the trick ... thanks James! -- James Mitchell Craig On Jun 2, 2006, at 12:38 AM, Craig McClanahan wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Is this what you need? http://maven.apache.org/guides/mini/guide-proxies.html Yes! Thanks ... but it leads to a stupid newbie question ... where's the user settings file go? :-) -- James Mitchell Craig On Jun 2, 2006, at 12:31 AM, Craig McClanahan wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. One problem seems to be with AbstractJsfTestCase and a null pointer when referencing the servletContext variable from a subclass. My guess is that there is a missing configuration resource. @Craig: Any ideas? Try running mvn -Pmyfaces test and then examine the output in target. All of the necessary resource files shoudl be in the classes or test-classes dirs. If not, then we missed something. I'll pull the mvn_reorg stuff and check this out. @Sean/@Wendy: Is there any way to teach Maven to use an HTTP proxy when it does it's dependency downloads, like you can tell Subversion to? I spend most of my time connected to Sun's VPN network, and right now I have to disconnect from that to do the Maven stuff -- not fatal, but it's sure a pain. Sean Craig Craig On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: So I can run svn move foo/bar foo/buzz locally and then commit foo? This is the same as svn move https://foo.com/foo/bar https://foo.com/foo/buzz? Yes, exactly the same. The advantage is that you can do multiple commands locally, preview the results, and then commit all the changes at once. There are some limits, occasionally Subversion will complain that you need to commit before executing some command that you're trying to do. (Which is why that first script is separate.) Whatever is easier for you, though, it ends up being the same when you're done. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. Core library builds and all the tests pass: mvn clean install -Pmyfaces Works for me now as well, with your latest patches. But shouldn't it also work without the -Pmyfaces because it's got activeByDefault set? By the way (if you beat me to it), the sql-browser example app also requires JDK 1.5 (an the tiger library). Craig It was a combination of a missing 'documentRoot' system property, and not having all of the non-Java resources in the right place in the jar file. The Ant build also copies messages.properties - message_en.properties, which isn't in the Maven build yet. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. Core library builds and all the tests pass: mvn clean install -Pmyfaces Works for me now as well, with your latest patches. But shouldn't it also work without the -Pmyfaces because it's got activeByDefault set? In addition, I wanted to try this using the JSF RI too, because (in theory) everything should still work. So I tried mvn clean install -Pjsfri It looks like Maven is trying to download the RI stuff from ibiblio, which isn't correct ... the necessary files are on the java.net repository ( https://maven-repository.dev.java.net/nonav/repository/) How does one go about telling Maven to get the javax.faces artifacts from here instead? Craig
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: In addition, I wanted to try this using the JSF RI too, because (in theory) everything should still work. So I tried mvn clean install -Pjsfri It looks like Maven is trying to download the RI stuff from ibiblio, which isn't correct ... the necessary files are on the java.net repository ( https://maven-repository.dev.java.net/nonav/repository/) How does one go about telling Maven to get the javax.faces artifacts from here instead? Put this in the shale parent pom, then adjust the version numbers on the RI dependencies. repositories repository idjava.net/id namejava.net Maven 1 Repository/name urlhttps://maven-repository.dev.java.net/nonav/repository/ /url layoutlegacy/layout /repository /repositories Thanks ... I've gotta get my feet wet with this stuff sometime, so now seems like a good opportunity :-). Although, it might ultimately make sense to do this in the Struts parent POM since SAF2 is using JSF as well. Did we set up profiles the same way there? (I'm gonna go ahead and do the Shale parent now, and worry about that later.) -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: Thanks ... I've gotta get my feet wet with this stuff sometime, so now seems like a good opportunity :-). Here's the 'maven model', the documentation for pom.xml: http://maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html There's probably a newer version somewhere, that's the one Google finds. Found the one on the Maven website[1] and added the appropriate entries. But now, when I try to run mvn clean test -Pjsfri the following bad things happen: * There's an obsolete jsf-api artifact on ibiblio -- can we specify a priority ordering somehow? * It fails to download the jsf-impl (but that could be my proxy not liking https -- investigating. By the way, the version number we want for both api and impl is 1.1_02 -- Wendy Craig Craig [1] http://maven.apache.org/ref/current/maven-model/maven.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Are you able to run the tiger tests? No. I got to the part in build.xml where it says Set up 'web application' for unit tests and decided that maven.test.skip=true would do for now. :) Craig, can you explain the testing strategy for shale-tiger? It's supposed to be similar to core-lbrary, in that the src/test directory will contain a bunch of JUnit tests. Since the module requires 1.5, the tests will as well, but other than that it should not be anything special. Craig -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Also, what's the deal with designtime? I briefly remember some discussion on it in this thread and was just wondering what the final result was. Will the binaries be made available via Maven repo? Or do we have to download creator and manually install the jars locally? I'm working on the public avaiability of this (we announced at JavaOne that Creator will be open sourced ... finalizing the planning now, but it's more likely to be months than weeks or days). In the mean time, I'll create a cheat sheet for how to copy the necessary JARs out of a downloaded Creator 2 (or Creator 2 Update 1) install and put them locally into your repository. -- James Mitchell Craig
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Are you able to run the tiger tests? No. I got to the part in build.xml where it says Set up 'web application' for unit tests and decided that maven.test.skip=true would do for now. :) Craig, can you explain the testing strategy for shale-tiger? It's supposed to be similar to core-lbrary, in that the src/test directory will contain a bunch of JUnit tests. Since the module requires 1.5, the tests will as well, but other than that it should not be anything special. OK, that's only half the story ... and the same thing will apply to use-cases (and potentially all of the other webapps when we get there). There are potentially two sets of tests. * src/test in the original repository contains JUnit unit tests that run standalone on the classes in the webapp's src/java directory. * src/systest in the original repository contains JUnit tests, but they (a) presume that the webapp has been deployed, and (b) use HtmlUnit to exercise the actual application and examine the returned HTML pages for correct output. I think of these as system integration tests rather than unit tests, but vastly prefer HtmlUnit based tests like this to something built with Cactus. Much simpler. We don't necessarily have to solve the systest issues tonight, but that'll probably bear some thought since the same principle would apply to any webapp in the repository (and, ideally, any user-defined webapp created via the archetype mechanisms). Craig Craig
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: Works for me now as well, with your latest patches. But shouldn't it also work without the -Pmyfaces because it's got activeByDefault set? I think so, too. :/ In addition there was some strangeness (discussed on [EMAIL PROTECTED]) with being able to deacivate an active-by-default profile. So I'm not yet sure how that part is going to work. I would hope they end up with a reasonable policy like if there is a -P option on the command line, activate only the profiles specified there; otherwise activate the active by default profile(s). Craig By the way (if you beat me to it), the sql-browser example app also requires JDK 1.5 (an the tiger library). Shale Tiger isn't building just yet, working on that now... -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: Found the one on the Maven website[1] and added the appropriate entries. But now, when I try to run mvn clean test -Pjsfri the following bad things happen: * There's an obsolete jsf-api artifact on ibiblio -- can we specify a priority ordering somehow? Not that I'm aware of. But ibiblio only has a pom for 1.1, so it shouldn't cause a problem if we're using version 1.1_02. If you mean the 'invalid pom' warnings, that's because java.net is a Maven 1 repo. * It fails to download the jsf-impl (but that could be my proxy not liking https -- investigating. After I added the repository and changed the version number, 'mvn clean install -Pjsfri' in core-library ran with no problems here. Me too when I disconnected from my VPN network (and commented out the appropriate proxy stuff). I've used https proxies for other things (including SVN commits to Apache), so it's likely to still be something with Maven ... but that's an issue that can wait for a night's sleep. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Sorry, I meant with Maven 2. I get a few test failures, even after correcting the missing .xml files from test. So did I. The tests fail with Maven2, so I looked at tiger/build.xml to see what might be missing. In build,xml, the 'test' target depends on 'test:webapp' which constructs a web application directory structure that I assume the tests depend on. Yes, they do ... Tiger needs to be able to parse the faces-config.xml files defined by the webapp just like the JSF runtime does, so I needed to be able to simulate a webapp directory structure for that in the unit tests. Note that the Ant scripts pass a basedir system property pointing at where the deployed webapp directory structure is -- we'll need to do something equivalent or change the tests to presume where the resources actually end up. Craig It might be as simple as arranging that into src/test/resources so it will be available for the m2 tests. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: And with that, I think I'm done for the night. Thanks for all the help! Likewise ... and thanks to James as well. -- Wendy Craig
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/2/06, Sean Schofield [EMAIL PROTECTED] wrote: We should rename core-library to shale-core. It saves a lot on maven/continuum headaches if the name of the dir matches the name of the artifact. We did not do this in MyFaces (for some valid reasons) but its a definite inconvenience. I haven't checked the other artifacts but that suggestion holds for those as well. +1 for shale-core, shale-test, shale-clay, etc., as directory names matching the artifactIds. +1 as well (convention over configuration strikes again :-). For the apps, I see a really long artifactId for the sql browser app, and would rather have it match the name of the war file: shale-sql-browser. That makes sense. And the name is also the default for the context path, right? Thanks, -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: Oops... wrong button! On 6/2/06, Sean Schofield [EMAIL PROTECTED] wrote: +1 for shale-core, shale-test, shale-clay, etc., as directory names matching the artifactIds. Done The list of modules in the parent pom needs to be changed to match. I'm working on this one ... but it raises two questions. * I presume we don't have to list the individual applications themseves in the shale-parent-pom file, because things get processed hierarchically? * When I try a build (like mvn test intall -Pmyfaces) from within one of the subdirectories (like shale-core), it tries to download struts-shale-parent-1.0.3-SNAPSHOT.pom (i.e. the file I'm modifying) from ibiblio. Shouldn't we be installing the local copy of the parent POM so it'll pick up all the most recent changes? Craig Are you suggesting changing the artifact id and then the name of the module to match it? If so +1 from me. Yes, for all the apps. I'll do it later (or tomorrow) if no one beats me to it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 build -- Help Wanted
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Ok, so I had some time this morning to help. I started looking at the apps to see what I could do to get them up to Maven2 par. I created a struts-shale-apps-parent (pom.xml under apps/) and added it as a module of struts-shale-parent. I then created struts-shale-apps-sql-browser (pom.xml under apps/sql- browser) and that almost works fine. With respect to 1.4 vs 1.5 for compilation, I'm not sure what all is going on with profile/activation inheritance and all, but even with this: Thanks. :) The 1.5 profile should be automatically activated if you're compiling with JDK 1.5. You shouldn't have to put anything on the command line. Is that not working? profile activation jdk1.5/jdk - /activation modules moduletiger/module /modules /profile -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Updated status -- we now can successfully compile all of the following modules using the new Maven build: shale-clay, shale-core, shale-remoting, shale-spring, shale-tiles, shale-tiger, shale-test However, the following modules still have unit test failures: * shale-clay: It looks like the component definitions for the standard JSF components are not getting recognized. Gary, could you take a look at these? * shale-tiger: The ant version of the tests builds a mock web application directory structure under target/test-webapp that is used to exercise the configuration loading classes. It doesn't look like we can emulate this by simply copying resources, because it assembles some things out of compiled classes. Is there a plugin where we can escape out to an actual Ant script when the tests are compiled? If so, it would be pretty easy to copy just the test:webapp target stuff from the original build. The POM will also need to pass the basedir property, if it doesn't already. I'll be working out the details on the last remaining top-level module (shale-designtime) late this evening. In the mean time, I'm going to comment it out of the parent POM because this module will always require some special processes at build time, and is not required for anything else. That will allow us to start hacking on the Shale sample apps once the test failure issues above are addressed. Craig
