[OS-webwork] Building with Eclipse M4?
Anybody here work with Webwork in Eclipse? My eval IDEA license will expire soon and the timing isn't right to commit to that product. I'm on OS X with a beta 1.4 jdk release available. Is there anybody in here that can describe the correct way to import Webwork from CVS into Eclipse. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action configuration XML [Commands]
Chris Nokleberg wrote: I don't understand this logic. A property default is a default for form parameters, obviously it can change. If you want to fix the value for a particular mapping, you add it to actions.xml. Not quite. In an action there are two sets of parameters: initialization parameters and form parameters. From an action point of view they are equivalent however, since both are set through set* methods. If both are set the same way then there is a potential security problem if a user sets an init parameter through a form submission. I.e. a parameter which was supposed to be set through some initialization parameter is instead provided by the user. The way to get around that is to: 1) Set form parameters first and init parameters later. However, this makes it impossible to use the init parameters during the prepare() step, which is where they would be perhaps most useful. 2) Require that all init parameters are set in xwork.xml. Even if the default is ok, the value must be provided again, or else there is a security hole. Both of these two issues go away if init-parameters are provided through the context, or similar, i.e. not by calling set* methods in the action. The argument that it will hurt performance is really misleading IMHO. You're assuming a certain implementation. Sure, I'm assuming reflection. Is there any other way to do it? For one thing, since the parameters and values and destination classes are known ahead of time, you can pre-convert all of the values. etc., etc. That's certainly possible, and would remove some of the overhead. The other issues still remain. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Chris Nokleberg wrote: Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. That is a lot of extra machinery where pinning the action would work instead. A lot of extra machinery?! You declare what roles may access it in xwork.xml. One could even provide defaults at the package level. How is that a lot of extra machinery? Between skinning and support for declarative security, it seems to me the latter is wanted by more people. How do you know this? BTW, if interceptors had at least an optional URL-mapping component, you could do skinning via /* - DefaultSkinInterceptor /bar/* - BarSkinInterceptor So one should write an interceptor for a skin? Isn't that a little too much extra machinery? I find it strange how on one hand you argue against triggering functionality based on URL-matching, What argument are you talking about? AFAIK I haven't made any such argument. but on the other hand argue for that exactly through your skinning examples. Not following. What in the skinning examples is triggering functionality based on URL-matching? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
boxed wrote: I will run the action without a result a few times to start off to make sure it compiles and goes through to success and so forth. I also have some (very few) actions that don't actually have a view at all, but write directly to the servlet output stream. Yes I know it's ugly, I hate it too, but there are several cases where I am pretty much forced to do this, most notably when the output needs to be streaming in some way. There is another early development thing you can do to make initial development easier, but that includes a change to MakeIterator (my diff and source is attached) and a default mapping of success to a jsp that does: ww:iterator ww:print value=value/propertyType / ww:print value=key /br / /ww:iterator I find it very handy for initial debugging. That's a very good point. So, it seems that .action invocation is indeed something that is necessary to keep. The argument against .action invocation, then, is only with regard to declarative security. Would it be ok to declare what roles may access it in xwork.xml? (both on action and package level) One nice thing about that is that the information could be used by many different invokers, as opposed to the declarative security through web.xml option which only works for the web case. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Action invocation
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] The argument against .action invocation, then, is only with regard to declarative security. Would it be ok to declare what roles may access it in xwork.xml? (both on action and package level) That's the argument against .action invocation with any path. If we pin actions to certain paths in the config files, as I've proposed, then this is not an issue. One nice thing about that is that the information could be used by many different invokers, as opposed to the declarative security through web.xml option which only works for the web case. Then you have to synchronize your roles in web.xml with the roles in xwork.xml. Plus, your servlet container can't automatically determine that you aren't logged in when you try to access a secured area and pop up the log-in prompt or load the log-in form. Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Re: Action invocation
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Chris Nokleberg wrote: Here's another way: define the roles that are allowed to access an action in xwork.xml, and create an interceptor that checks it. Then it can work exactly like how web.xml works, except it can do so for the case where an unsecure action calls a secure action too. That is a lot of extra machinery where pinning the action would work instead. A lot of extra machinery?! You declare what roles may access it in xwork.xml. One could even provide defaults at the package level. How is that a lot of extra machinery? Creating an extra interceptor to re-create J2EE declarative security is at least some extra machinery compared to just using what is there. I'm not saying that it's bad, in fact I kind of like the idea of restricting which roles can run packages of actions, but I would prefer to add that IN ADDITION to being able to pin packages to certain URL paths to enable the use of J2EE declarative security and make it optional. It's sounding to me like we really need 2 configuration files here: 1) xwork.xml : the standard xwork configuration which applies to all Dispatcher types. This would include package and action configuration 2) xwork-web.xml : configures web specific configurations, such as URL paths to pin packages, and view mappings The reason I would say to put the view mappings in the xwork-web.xml is because you might want to use the same set of actions for web and Swing based apps, and you'd want to have different view mappings. Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Jason Carreira wrote: That's the argument against .action invocation with any path. If we pin actions to certain paths in the config files, as I've proposed, then this is not an issue. True, but it's more configuration to do. If it can be avoided that'd be nice. One nice thing about that is that the information could be used by many different invokers, as opposed to the declarative security through web.xml option which only works for the web case. Then you have to synchronize your roles in web.xml with the roles in xwork.xml. Plus, your servlet container can't automatically determine that you aren't logged in when you try to access a secured area and pop up the log-in prompt or load the log-in form. No, but the controller servlet can, I think. If the execution interceptor returns LOGIN, then the controller should be able to return headers that correspond to showing the log-in prompt, or one could simply have a view mapped to LOGIN that returns those headers. Or am I missing something? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Jason Carreira wrote: Creating an extra interceptor to re-create J2EE declarative security is at least some extra machinery compared to just using what is there. I'm not saying that it's bad, in fact I kind of like the idea of restricting which roles can run packages of actions, but I would prefer to add that IN ADDITION to being able to pin packages to certain URL paths to enable the use of J2EE declarative security and make it optional. It's sounding to me like we really need 2 configuration files here: 1) xwork.xml : the standard xwork configuration which applies to all Dispatcher types. This would include package and action configuration 2) xwork-web.xml : configures web specific configurations, such as URL paths to pin packages, and view mappings The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. The reason I would say to put the view mappings in the xwork-web.xml is because you might want to use the same set of actions for web and Swing based apps, and you'd want to have different view mappings. Interesting point. How many people would use it though? How realistic is that? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Re: Action invocation
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. I'm planning on using Xdoclet, I don't know about you. :-) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Action invocation
Jason Carreira wrote: As opposed to the extra configuration to assign roles to packages and coordinate them with the roles in web.xml? I really don't like the idea of putting security information into xwork. If we pinned packages to URL paths, and protected the paths using J2EE declarative security, you've only got security information in one place, and it can be changed at deploy time (and even at run time, depending on your servlet container). Good point. I agree with that. But, there's still a need to add roles to xwork.xml I think, for the cases where the actions are invoked by other actions, or by some dispatcher other then a servlet controller. No, but the controller servlet can, I think. If the execution interceptor returns LOGIN, then the controller should be able to return headers that correspond to showing the log-in prompt, or one could simply have a view mapped to LOGIN that returns those headers. Or am I missing something? Can this be done? I'm not sure... I think this would require container-specific code for each container we support. Isn't just a case of returning standard HTTP headers? (for the prompt I mean). Also, what should happen if an action is invoked through an include and is not allowed access to. This is by far the most common case I have anyway (I don't have ANY other case). How would that work? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
On 3/1/03 7:25 PM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: Mike Cannon-Brookes wrote: Hrm - no, this is thinking the wrong way mate :) If webwork defined paths, security would work perfectly right? So why not have webwork only 'work' if the path is correct (and defined)? Ie /admin/foo.action would execute foo, but /bar/admin/foo.action would execute nothing. Then the action would be pinned to that particular path, and skinning wouldn't work. I have _never_ needed to use the fact that actions can move paths, and I would hasten to guess that 95% of WebWork users don't care either? Leave the option open to do both, and we'll satisfy the security problems (by pinning paths). -mike PS IMHO the principle of least surprise here is that actions are NOT available anywhere. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Mike Cannon-Brookes wrote: I have _never_ needed to use the fact that actions can move paths, and I would hasten to guess that 95% of WebWork users don't care either? That might be so, yes. Leave the option open to do both, and we'll satisfy the security problems (by pinning paths). Make the path's optional then. Ok, that could work. PS IMHO the principle of least surprise here is that actions are NOT available anywhere. Maybe, maybe not. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation
Damn! A little late :(. - Original Message - From: matt baldree [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 04, 2003 9:56 AM Subject: Re: [OS-webwork] Re: Action invocation Can someone summarize the issues? If you build XWork the way you want what would be left out? I don't think we can build a framework that will meet everyone's needs and I don't think the new framework will be 100% backwards compatible with WW nor do I think it should be. I'd rather see a clean room design and see what desired requirements fall out. I think there are many ways to slice this. If we had a document defining the requirements, I think these discussions could be more productive. Rickard, could you draft a requirements document from your point of view and post it on WIKI? -Matt - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 04, 2003 8:46 AM Subject: Re: [OS-webwork] Re: Action invocation Jason Carreira wrote: The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. I'm planning on using Xdoclet, I don't know about you. :-) I'd probably use runtime attributes where possible, which is basically the same thing. That does take care of some of those issues, but it'd almost have to be mandatory for it to be practical to use. Ah well... personally I don't really care, since I have never used declarative security and will never use it either. Maybe it would be better if I did a framework for my own needs instead, and let you guys do what you is feel best in XWork. It seems we have very different requirements, much of it coming from the point that most of you seem to be doing straight web apps whereas I'm almost exclusively doing portlet-style apps with a lot of state machine-ish stuff. I have a lot of needs you don't have, and the other way round. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] So long
N! The discussion on here has been VERY pleasant to see, a lot of smart things said and I felt that real progress was being made. Please ignore the idiots on IRC. It's a little boys club where if you don't want to play with them they pout and sulk. Don't make the mistake of assuming that those who are loudest are the majority. Don't be discouraged by the whiny tone of IRC, if you're unhappy in that medium, then avoid it. You wouldn't be the first highly able and competent developer to choose to not play with those kids. Please reconsider your decision, and take up the task of xwork architecture once again! On Saturday, January 4, 2003, at 10:57 AM, Rickard Öberg wrote: All, After having read all comments on the changes I wanted to make, as well as some not-so-nice comments by people on #java (boxed and Joe Ottinger for example), I've decided that it's not a good idea for me to be architecting XWork. It seems I and most of you have rather different requirements for what such a framework should contain, and how it would work. Thus, trying to make a framework which fits both worlds is just too much pain. So, I'm resigning from the position as architect of XWork. If noone else is interested I'd suggest that Pat resume his work. I'll probably start working on another framework instead, but which would be totally geared towards the upcoming Portlet API. AFAICT portlets is going to become a very nice way to build web components and pluggable web apps in the coming year, so I see little reason for me to work on a non-portlet approach. Good luck! regards, Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Re: Action invocation [state machine]
Rickard, You said it yourself, you're geared toward a state-machine-type of development. Well I am too, actually... heavily influenced by the OSWorkflow statemachine (I see large parallels between OSWF and WW -- especially with chaining). My point here is that I think you should stay around. With my help I think that we can address all the open issues, ignore all the jackass comments, and still get all your cool ideas in. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 04, 2003 6:46 AM Subject: Re: [OS-webwork] Re: Action invocation Jason Carreira wrote: The problem with that is keeping them in sync. I'd prefer using one file with namespaces instead. I'm planning on using Xdoclet, I don't know about you. :-) I'd probably use runtime attributes where possible, which is basically the same thing. That does take care of some of those issues, but it'd almost have to be mandatory for it to be practical to use. Ah well... personally I don't really care, since I have never used declarative security and will never use it either. Maybe it would be better if I did a framework for my own needs instead, and let you guys do what you is feel best in XWork. It seems we have very different requirements, much of it coming from the point that most of you seem to be doing straight web apps whereas I'm almost exclusively doing portlet-style apps with a lot of state machine-ish stuff. I have a lot of needs you don't have, and the other way round. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] What happens if you forget templates?
Today I created a web app but I forgot to copy the template directory
to my context root but
what I noticed is that I didn't get any error messages at all so this
could be quite a difficult problem to solve without them. Of course I
didn't get any HTML for my ui tags so that's a bit of a giveaway really.
I'm wondering
If you can expect IncludeTag's include method to throw an exception.
I'm guessing that RequestDispatcher isn't always going to return null
if the path isn't found.
What about rd.include ... what exceptions will it throw in the event
the path isn't found?
I think the framework should do a better job of handling this situation.
if you rename your template directory run your webapp you will not get
servlet exception or an ioexception.
public static void include(String aResult, PageContext aContext)
throws ServletException, IOException
{
String resourcePath =
getContextRelativePath(aContext.getRequest(), aResult);
RequestDispatcher rd =
aContext.getRequest().getRequestDispatcher(resourcePath);
if (rd == null)
throw new ServletException(Not a valid resource path: +
resourcePath);
PageResponse pageResponse = new
PageResponse((HttpServletResponse) aContext.getResponse());
// Include the resource
rd.include((HttpServletRequest)aContext.getRequest(),
pageResponse);
//write the response back to the JspWriter, using the correct
encoding.
String encoding = getEncoding();
if (encoding != null)
{
//use the encoding specified in the property file
pageResponse.getContent().writeTo(aContext.getOut(),
encoding);
}
else
{
//use the platform specific encoding
pageResponse.getContent().writeTo(aContext.getOut(), null);
}
}
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] So long
Well, I certainly hope you reconsider. Xwork could certainly use your talents. I don't really think the ideas presented here are that far apart. Perhaps you could list what you see as the biggest requirements for your portlet app from Xwork, and we can see where the gaps lie. Jason -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 10:57 AM To: WebWork Subject: [OS-webwork] So long All, After having read all comments on the changes I wanted to make, as well as some not-so-nice comments by people on #java (boxed and Joe Ottinger for example), I've decided that it's not a good idea for me to be architecting XWork. It seems I and most of you have rather different requirements for what such a framework should contain, and how it would work. Thus, trying to make a framework which fits both worlds is just too much pain. So, I'm resigning from the position as architect of XWork. If noone else is interested I'd suggest that Pat resume his work. I'll probably start working on another framework instead, but which would be totally geared towards the upcoming Portlet API. AFAICT portlets is going to become a very nice way to build web components and pluggable web apps in the coming year, so I see little reason for me to work on a non-portlet approach. Good luck! regards, Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Re: Action invocation
Ah well... personally I don't really care, since I have never used declarative security and will never use it either. You might change your tune when you're asked to integrate your CMS product with an existing security framework... Especially if it's a large user base and they've gone with an enterprise security infrastructure based on something like Netegrity Siteminder. Those products will have integration with large app servers, etc., but you'd have to develop your own plugins. Using standard security frameworks allows you to more easily integrate with a whole security system. This is why I've pushed for us to stay with standard J2EE security rather than developing our own user / role framework. Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] So long
I would have to say +1 to this - Hani has summarised it exactly. There are many fools on IRC, and as they say a lot - very little of it is useful, most of it is utter crap. Ignore them. I for one don't see why we can't all work together to build a better framework, rather than splintering all the time. As Patrick said, we're in some sort of discussion-design-paralysis at the moment. He who does, wins. Just build it and they will use it - people will always argue on a mailing list, whether they will actually build it themselves is something totally different. Please reconsider from me too. -mike On 5/1/03 3:50 AM, Hani Suleiman ([EMAIL PROTECTED]) penned the words: N! The discussion on here has been VERY pleasant to see, a lot of smart things said and I felt that real progress was being made. Please ignore the idiots on IRC. It's a little boys club where if you don't want to play with them they pout and sulk. Don't make the mistake of assuming that those who are loudest are the majority. Don't be discouraged by the whiny tone of IRC, if you're unhappy in that medium, then avoid it. You wouldn't be the first highly able and competent developer to choose to not play with those kids. Please reconsider your decision, and take up the task of xwork architecture once again! On Saturday, January 4, 2003, at 10:57 AM, Rickard Öberg wrote: All, After having read all comments on the changes I wanted to make, as well as some not-so-nice comments by people on #java (boxed and Joe Ottinger for example), I've decided that it's not a good idea for me to be architecting XWork. It seems I and most of you have rather different requirements for what such a framework should contain, and how it would work. Thus, trying to make a framework which fits both worlds is just too much pain. So, I'm resigning from the position as architect of XWork. If noone else is interested I'd suggest that Pat resume his work. I'll probably start working on another framework instead, but which would be totally geared towards the upcoming Portlet API. AFAICT portlets is going to become a very nice way to build web components and pluggable web apps in the coming year, so I see little reason for me to work on a non-portlet approach. Good luck! regards, Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] So long
After having read all comments on the changes I wanted to make, as well as some not-so-nice comments by people on #java (boxed and Joe Ottinger for example), I've decided that it's not a good idea for me to be architecting XWork. Afaik, the only thing me and epesh said was that we're afraid xwork in your hands would turn into a portlet beast instead of the simple MVC framework it started out as. I really believe you are overreacting. Dissent is necessary for a constructive environment, and I am a dissenter by nature :P Yes, I would prefer Pat as the xwork architect because he would design it to fit my needs, that doesn't mean I'm right. Personally I don't think security has a place in xwork core code, it seems like a separate xwork-security module to me. Can this be done? I think this goes for quite a bit of the stuff you want in xwork, and I'd love to see you give input to pat as to what interfaces xwork needs to expose to make this happen, but I don't want to have xwork security in code that doesn't need it. As you're one of the people who talk about performance the most, I believe you can relate to this. In summary, I think your input will help xwork, but I also think we need to hold you back a bit so as to not make xwork into your framework, but OUR framework :P Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Action invocation
+1 here. Michael Blake Day Artistry Studios - e-commerce design, implementation and hosting email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mobile: 770.480.1547 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Carreira Sent: Thursday, January 02, 2003 3:33 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Action invocation -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] That is how I have implemented the filter currently: if there's an action for the JSP, then execute it, otherwise do nothing (i.e. run JSP as usual). /Rickard I don't like the idea of exposing the view we're mapping to. What If I want to change the view that is mapped from the action? I think it would be better to have: http://somehost.com/myPackage/myAction So you don't have to have any kind of extension... Just logical URLs that make sense. Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Action invocation
I may be late to the conversation, but I just wanted to mention the obvious. Having .action extensions does not expose the fact that a person is using WebWork (or XWork). You can even change the extension to whatever you want (try .dll, hehe). Michael Blake Day Artistry Studios - e-commerce design, implementation and hosting email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mobile: 770.480.1547 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Oberg Sent: Thursday, January 02, 2003 1:27 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action invocation Bruce Ritchie wrote: I'm with Pat here .. I actually prefer having urls with the .action in them to having pages with ww:action tags in them. But I didn't suggest that you'd use action tags... that was the WW way, and it worked, but with the filter it's much more transparent and the security problem with .action's is gone. For one thing, they perform better. Another reason is that I have the same situation as Pat, the same jsp is the success page for multiple actions. One final reason is that the migration path from ww to xw for applications now requires filters to handle the (automatic) migration from the old .action urls to the new jsp only urls. I guess it would be possible to add .action support as well, but if it's possible to avoid I think we should, for reasons mentioned (hiding implementation, security). /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Re: Action invocation
Can't we just add a path parameter to the action definitions in xwork.xml? Michael Blake Day Artistry Studios - e-commerce design, implementation and hosting email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mobile: 770.480.1547 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Öberg Sent: Thursday, January 02, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: Action invocation Chris Miller wrote: Remind me again why .action causes problems with declaritive security? Surely the real problem is that Webwork currently doesn't care if an arbitrary path is specified in the URL. ie: http://www.me.com/abc123/admin/deleteUser.action is treated the same as http://www.me.com/admin/deleteUser.action - which makes it very messy to nail down in web.xml. That *is* the problem. And itt's not messy; it's impossible! No matter how you construct your web.xml I can circumvent it by doing an arbitrary path like so: http://www.me.com/jkldsdfglkjglkdhgdklhg/asdasdasd/deleteUser.action If .action invocations are not allowed then it's possible to use declarative security. Plus if execution of actions is only possible if a URL has been previously associated with it during form creation, then it's even safer. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
