Re: [OT] paranoid
LOL Oh, I didn't tell you, the JUEL plugin has some experimental psychic code in it. Part of the Apache 'I know what you did last summer!' project. :) Tom Musachy Barroso wrote: I was playing around with JUEL plugin last night, and while running the example I saw the first input on the form had my name on it. I spent 10 minutes trying to figure out how it knew it was me, until I (gave up) looked at the code and saw my name was hardcoded there. Nice work Tom :) //is anybody else doing/planning to do anything on this plugin? musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on JSPs and OGNL
Brian,
I worked on Unfied EL a bit towards the end of last year:
http://cwiki.apache.org/S2PLUGINS/unified-el-plugin.html I was able to
get it working for basic expressions, but it is nowhere near ready for
production. It would need a lot more coding/testing before it would
even be considered beta status. I also think there are some fundamental
limits to what can be done with standard JSP unified el. From my
investigation, I'm not sure we could support all of the cool stuff we
can do with OGNL. Another possibility is that Jesse talked about adding
a UEL compatability layer to OGNL. I haven't followed up so I'm not
sure if that went anywhere.
Tom
Brian Pontarelli wrote:
Just to preface this email, I've never been a big OGNL fan...
Okay, I'm updating everything to 2.1.1 and the new convention plugin
and realized a major change from 2.0.9 to 2.1.1 is that the struts
tags no longer accept JSP expressions, which has caused some major
headaches. I could change the tld, but that's non-standard with
Struts. My last email about compatibility didn't really get any
responses and I think that it is really important overall. Upgrading
between 2.0 and 2.1 is gonna be painful and it is something that
should probably be documented.
Here's some thoughts after having done some upgrading and also worked
with very green developers and loads of different clients over the
last year:
- The fact that some attributes take OGNL directly, some via aliases
like %{} and some not at all is REALLY confusing and cumbersome
- OGNL itself is strange since it has a tree structure and the #
syntax is confusing for new developers
- I still haven't figured out a way to get at some JSP concepts such
as include parameters (i.e. jsp:param values) and this requires
hacks like:
c:set name=foo value=${param['foo']}/
s:hidden name=foo value=%{#attr.foo}/
(yeah %{#parameters.foo} doesn't work for some reason. If someone
knows the fix, let me know)
- Different syntax to get values from objects inside and outside tags
in a JSP - on the page is JSP EL (required so you don't get nested XML
and your code can be XML validated) and OGNL in the tags. This is not
so pleasant
- Not well documented what is available from OGNL in the JSP
Thus far I haven't found any major benefit to OGNL in any of my
applications. I'm certain others have, but I would guess these are
minimal and could be handled by some ognl tag like ognl:eval/.
I know there are some folks trying to update to the UEL and this is
somewhat of thinking out loud about moving this timeline up to 2.1.1
or the immediate next release. It would seem that this will make
things a lot more standard overall. Anything I can do to help, just
let me know.
-bp
-
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: Thoughts on JSPs and OGNL
Unfortunately, I haven't had much (any) time to work on s2 at all since
December. Feel free to poke around and see how far you can get.
Tom
Brian Pontarelli wrote:
Tom Schneider wrote:
Brian,
I worked on Unfied EL a bit towards the end of last year:
http://cwiki.apache.org/S2PLUGINS/unified-el-plugin.html I was able
to get it working for basic expressions, but it is nowhere near ready
for production. It would need a lot more coding/testing before it
would even be considered beta status. I also think there are some
fundamental limits to what can be done with standard JSP unified el.
From my investigation, I'm not sure we could support all of the cool
stuff we can do with OGNL. Another possibility is that Jesse talked
about adding a UEL compatability layer to OGNL. I haven't followed
up so I'm not sure if that went anywhere.
My feeling is that the cool stuff with OGNL is probably better
suited for an action or somewhere else and even if it needed to be in
the page it could be handled via an OGNL tag. It would be nice to use
the same syntax anywhere on the JSP including in and out of tags. I
would even think that we could cover the majority of the cases using
UEL ${} syntax rather than the #{} syntax.
Here's another example. I was using the s:action tags quite a bit for
invoking setup actions and for creating select boxes and such. From
2.0.9 to 2.1.1 this broke. I used to be able to set into the s:param
an OGNL list and it would end up in the action just fine. Now it
doesn't work. It would be nice to just use JSP EL since I can pass in
a list object and the container is responsible for finding the object
and setting it into the taglib. So, now I just pass in a String and
for figure everything out myself, because I know it won't ever break
across versions of Struts and OGNL.
If you want some help with the UEL stuff, let me know. I'd definitely
like to see one language that is simple and efficient.
-bp
-
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 2.1.1 Release Planning
+1 for ditching JDK 1.4 on the Struts 2.1.x series. Struts 2.0.x should be a reasonable transition for those still on JDK 1.4. Tom On Jan 14, 2008 10:37 AM, Ted Husted [EMAIL PROTECTED] wrote: Works for me. It has to happen sometime. On Jan 14, 2008 11:27 AM, Al Sutton [EMAIL PROTECTED] wrote: Ditch JDK 1.4 support... problem solved ;). Al. - Original Message - From: Antonio Petrelli [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Monday, January 14, 2008 3:49 PM Subject: Re: Struts 2.1.1 Release Planning 2008/1/14, Ted Husted [EMAIL PROTECTED]: Is anyone else up to helping with the 2.1.1 release management? With the anniversary of the first Struts 2.0 GA coming up in February, it would be nice if we could squeeze out another tagged build. Wait some hours, until we clear things up about WW-2379: https://issues.apache.org/struts/browse/WW-2379 Antonio - 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: [S2] Libraries in JDK 1.4 distribution
I disagree, I think there is a support cost. If users are having issues with the 1.4 stuff, (which happens more often than not) then we're obligated to assist that user. If we dropped the 1.4 stuff, maybe for Struts 2.1, then we would no longer have that obligation. Long term I think we will drop the 1.4 stuff at some point, it's just a matter of figuring out when. Another advantage is the builds become a bit simpler. (Or at least there's a chunk of the build that goes away) I'm not arguing for dropping 1.4 support, but there are some reasons to consider it. Tom Antonio Petrelli wrote: 2008/1/12, Al Sutton [EMAIL PROTECTED]: I'd vote for sticking with the current approach for 2.0 and then dropping the 1.4 support entirely for 2.1. It would cause confusion to change the existing convention of dependancy packaging, but for a the new minor release (2.1) we can finally follow the statement on the struts2 website saying that Java 5 is a requirement and redirect the effort currently spent on the J4 release into improving the code code. I sincerely don't know why we should remove the J4 support, since it costs zero for us, thanks to Retrotranslator. Antonio - 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: Destroy Of Interceptor
You know, I think you're right! I searched the entire codebase (both xwork and struts) and I have found nowhere where we call destroy() on the interceptors. I guess that hasn't been an issue because if the destroy isn't being called, no big deal because your usually shutting down anyway. If we were to call destroy on the interceptors, I would expect it to happen in the cleanup() method of Dispatcher. This is where all the rest of the cleanup happens. At runtime, the list of interceptors is stored in the ActionConfig object. (part of xwork) Perhaps it might be a good idea to submit a patch that fixes this issue. :) (hint, hint) Tom Décio Heinzelmann Luckow wrote: Hi All, I´m studing Interceptors and I was looking for the local where Struts call the destroy() method of Interceptor. The init() method is called at the same time of construction of Interceptor, but I can´t find where the destroy is called. Someone know where its happen? Tanks! Décio Heinzelmann Luckow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Destroy-Of-Interceptor-tp14338766p14339890.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: web-beans ?
Actually, we've done a little more work on the scope plugin since we took it out of the sandbox: http://cwiki.apache.org/S2PLUGINS/scope-plugin.html Originally we took most of our API from Seam, but I think we'll be diverging from Seam a bit since it will make things easier for s2 users. My understanding is that Bob Lee is one of the leads on the web beans spec. So we might get JSR-299 support for free because we integrate with Guice. (At least that was my hope) That's why I haven't done much more with it. (That and a lot of the spec isn't applicable to an action based framework) Tom Ted Husted wrote: If by alternate implementation, you mean an implementation of JSR 299, that's something best discussed with the MyFaces group. Evidentially, Shale is merging with MyFaces, making MyFaces our one-stop JSF shop. :) Meanwhile, Don's been working on a scope plugin in the sandbox that mimic's Seam-style bijection. I'm not sure of the status, but you might want to have a look at what he's done so far. ' http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-scope-plugin/ Also in the Apache Struts sandbox is the JPA MailReader implementation that Wes mentioned. * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/ I'll probably be heads-down on some Ajax stuff the rest of December, but I hope to get back to this eventually. -- HTH, Ted * http://www.StrutsMentor.com/ On Dec 14, 2007 2:41 AM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I' just looked at jBoss Seam documentation. I wonder if anyone allready suggested to have similar features on Struts actions, that seems not so difficult to implement, by mixing an OpenSessionInView interceptor, some ModelDriven elements and injecting a JPA EntityManager in the action. As Seams is now promoted as a JSR (299), this could be nice to have Struts as an alternative implementation. Nico. - 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: In regards to Struts 2 Validation.
I have plenty of examples from our application.
The first is a case where the user must enter at least one phone
number and if the type of phone is selected, then the user must enter
a phone number. The validation code is as follows:
if(!hasFieldErrors(exampleData.phoneNumber1)
!hasFieldErrors(exampleData.phoneNumber2)
!hasFieldErrors(exampleData.phoneNumber3)
!hasFieldErrors(exampleData.phoneNumber4))
{
if((!exampleData.getPhoneNumber1().equals()
exampleData.getPhoneType1()== 0) ||
(!exampleData.getPhoneNumber2().equals()
exampleData.getPhoneType2()== 0) ||
(!exampleData.getPhoneNumber3().equals()
exampleData.getPhoneType3()== 0) ||
(!exampleData.getPhoneNumber4().equals()
exampleData.getPhoneType4()== 0))
{
addActionError(getText(phoneType.error));
}
if((exampleData.getPhoneNumber1().equals()
exampleData.getPhoneType1()!= 0) ||
(exampleData.getPhoneNumber2().equals()
exampleData.getPhoneType2()!= 0) ||
(exampleData.getPhoneNumber3().equals()
exampleData.getPhoneType3()!= 0) ||
(exampleData.getPhoneNumber4().equals()
exampleData.getPhoneType4()!= 0))
{
addActionError(getText(phoneNumber.error));
}
}
Note, I did not write this, this is taken straight from our source code.
The second example I have is a case where we want to use some logic to
validate prescription information. The validation for prescriptions
is tricky because the user doesn't have to enter prescriptions, but if
anything is entered for a prescription, then the prescription data is
fully validated. Note that we have several places in the app where
this is done so I'd prefer not to duplicate this validation logic in
all the places we need it. (i.e. don't want to violate the DRY
principle) I broke this out into a helper class for reusability. The
isEmpty() method on PrescriptionData checks to see if there is any
data populated.
public void validate(String propertyPrefix, List prescriptionList,
ValidationAware errors, TextProvider textProvider)
{
for (int i = 0; i prescriptionList.size(); i++)
{
PrescriptionData data = (PrescriptionData) prescriptionList.get(i);
// pull out conversion errors and set original values
ActionInvocation invocation =
ActionContext.getContext().getActionInvocation();
Map conversionErrors =
invocation.getInvocationContext().getConversionErrors();
if (!data.isEmpty())
{
if (data.getApplicantId() == 0)
{
errors.addFieldError(medication, textProvider
.getText(medicalQuestions.applicant.required));
}
if (ValidationUtils.isStringEmpty(data.getMedication()))
{
errors.addFieldError(medication, textProvider
.getText(medicalQuestions.medication.required));
}
if (ValidationUtils.isStringEmpty(data.getDescription()))
{
errors.addFieldError(description, textProvider
.getText(medicalQuestions.dosage.required));
}
if (!hasConversionError(propertyPrefix + [ + i +
].startDate, conversionErrors) data.getStartDate() == null)
{
errors.addFieldError(startDate, textProvider
.getText(medicalQuestions.startDate.required));
}
if (data.getStartDate() != null data.getEndDate() != null)
{
Calendar startCal = Calendar.getInstance();
startCal.setTime(data.getStartDate());
Calendar endCal = Calendar.getInstance();
endCal.setTime(data.getEndDate());
if (startCal.after(endCal))
{
errors.addActionError(textProvider.getText(medicalQuestions.startAfterEnd));
}
}
}
}
}
The final example is a case where some might consider it a 'business
rule', however, in my opinion, validation is validation regardless of
whether you're implementing business rule validation or simple UI
validation. My argument for this is the fact that the simple UI
validation is used as part of the business rule validation. (For
example, you might need to check that a string is not blank or null)
In this use case, we allow the user to enter a state and a zip and we
verify that the state and zip match. We do this by making sure that
the combination of state and zip produce at least one valid county.
if (!hasFieldErrors(siteLocationView.zip)
!hasFieldErrors(siteLocationView.state))
{
CountyData counties[] =
siteLocationProcess.getCountiesForZipAndState(siteLocationView
.getZip(), siteLocationView.getStateAbbr());
if (counties.length 1)
{
addActionError(getText(siteLocationView.zipcountymismatch.error));
}
}
This is a case where the validation is dependent on a business process object.
There's plenty more where that came from, so if you need more
examples, I'd be happy to provide them. These examples show how
verbose the
Re: [s2] Allowed methods next step
CMA = container managed authentication for those who haven't memorized
every three letter acronym under the sun.
What about using an s2 interceptor to enforce role security? That way
you could have an implementation for whatever security mechanism your
using and it's not tied to the struts configuration. I suppose we could
still have a place to store role metadata in the configuration, but I
wouldn't want the specific security enforcement logic to be tied to the
s2 itself.
Tom
Matt Raible wrote:
Is there anything on action that allows restricting roles? I
remember this being in S1 and I'm unsure if it exists in S2. If not,
it's something I believe we should add as I believe it's useful when
using CMA. When using Spring Security, I generally keep all my
configuration in my context file, but I can see why it's useful when
using CMA. If it is an attribute, I suppose having separate action
definitions is the best way to allow different roles for different
methods? If not, I could see some sort of method:role1/role2
shortcut being useful - but it might also make things more
complicated.
Matt
On Dec 9, 2007 5:30 AM, Don Brown [EMAIL PROTECTED] wrote:
Since the commit for this feature involved a rather large XWork change
(properly immutable configuration objects [1]), I decided to commit
what I have and discuss the next steps.
First, due the aforementioned fix [1], Brian, your SmartURL's
migration work will probably be most affected. I changed the
configuration objects to be immutable using a static inner builder
class pattern. This makes construction a bit tricker, so pay
attention to the changes in the code and tests for the codebehind
plugin. The bright side is the construction code is much more
readable and nasty state bugs should be gone. You can do nifty things
like this:
ActionConfig config = new ActionConfig.Builder(mypackage, foo/*/*,
foo.BarAction)
.methodName(execute)
.addParam(someparam, someval)
.addResultConfig(new
ResultConfig.Builder(success{1}, foo.MyResult)
.addParams(location, /foo.jsp)
.build())
.build();
As for the allowed methods, I originally suggested three options:
1. A new property/constant titled 'struts.restrictToDeclaredMethod'
that will instruct the ActionConfig (where the allowedMethods property
lives) to only allow the method that is explicitly defined (defaults
to 'execute'). If false, all methods will be allowed.
2. A new attribute on the action element called 'allowedMethods',
which takes a comma-separated list of method names to allow
3. A new @ActionMethod annotation for the codebehind plugin that
declares a method as callable
And after the comments, I see #2 is important and #3 I'll skip, since
Brian will be rewriting that stuff anyways.
To answer Matt's concern, yes, the default will be all public, no-arg
methods can be called, but what this will allow folks to do is limit
the methods that can be called, if they so choose. It also makes it
clearer to the developer what methods are being exposed through tools
like the config browser plugin. I'm also thinking it will be helpful
down the road when a plugin wants to move behind no-arg methods (I've
tried it, it can be pretty powerful).
See https://issues.apache.org/struts/browse/WW-2363
Any more thoughts?
Don
[1] http://jira.opensymphony.com/browse/XW-594
-
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: In regards to Struts 2 Validation.
Just wanted to chime in here. I have very specific goals that I am trying to achieve, so I thought I would explain them in detail. (this is something I've been tasked with at work) 1. We have a core product that is 'customized' for several client implementations. Validation is an area where we have a need to 'customize' certain validation rules. I think a way to separate out 'rules' that can be referenced via a key and replaced via configuration would work well here. Sort of a 'lite' rules engine targeted specifically to validation. 2. Ideally I would want to combine our current XML and action.validate validation. Right now we do the simple validation in XML and the rest of the validation in action.validate. I would prefer to have all validation in one place. 3. I want to be able to share validation between batch processes and the UI. Right now it's somewhat challenging to reuse validation between UI and batch processes. I would like one validation framework for both UI validation and validation in batch processes--at least for writing of the rules is concerned. Obviously there would need to be different adapters to invoke the validation in different contexts. 4. Validation should be easy to write and easy to use. I don't want a framework that is overly complex and hard to figure out. This is to satisfy the KISS principle. (Keep it simple stupid) So far, I like the grails validation the best. They have the concept of a 'constraint', which is like a rule but can be referenced directly in the groovy closure that defines the validation constraints. It should be easy enough to create new closures that define more complex validation directly in the closure. The other 2 projects I've looked at are: http://oval.sourceforge.net/ and https://springmodules.dev.java.net/docs/reference/0.8/html/validation.html#beanValidator. Both have some interesting concepts, but neither of them satisfy all of my needs out of the box. So that's where I'm currently at. I haven't had much time yet to really dig into this yet. Any additional ideas/suggestions would be greatly appreciated. Tom rburton wrote: Tom Schneider and a few other folks have been talking about validation in Struts 2 and how it can be improved. I figured it would be useful to spawn a thread in order to stir up some idea’s that may help inspire us. I know validation isn’t an easy task, and some would argue it’s a cross cutting concern; so does anyone have any idea’s on what they would like to see done? How can the existing validation framework be improved? My only issue with the existing validation framework is I can’t define validation rules which can be referenced in my validation.xml file. Any ideas would be greatly appreciated! Struts 2 = :rules: Best Regards, Richard L. Burton III P.S. I hate being at work on Sunday morning at 1 AM EST time to do a migration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP EL in struts2 tags
Well, I am definitely interested in this. I had no idea this was being planned. (I'll have to pop over to the OGNL site more often now) It definitely would be good for us to keep in sync since we may be duplicating efforts. My work thus far has been mostly a Proof of Concept, so I haven't invested too much time at this point. It would also probably be easier from a migration standpoint if we could get something like this going. Tom Jessek wrote: I don't know how relevant it is to the conversation or how awful it's going to be trying to do it but I did plan on taking a stab at creating a new unified-el compatible grammar for OGNL when I do my big IoC-friendly re-factor. (probably a 2.7.3 release kind of change) Since jboss and others already sound like they do some el extensions of their own to support parameter passing / other things it hopefully won't be too bad. I'll try and post updates wherever I can to get more people involved but knowing how you want to handle backwards compatibility - unified el + ognl stuff (if at all) and if OGNL needs to perform any extra tricks to make it happen would be a good thing to have ready and discuss / etc during that dev cycle. I'm guessing I'll probably start on it sometime this month and finish whenever. . Tom Schneider wrote: I was working on a proof of concept for Unified EL: http://cwiki.apache.org/S2PLUGINS/unified-el-plugin.html I had a basic value stack up and running, however, I never took it any farther than that. Richard Burton is planning on implemented an MVEL stack in the near future, but he's waiting on some changes from Chris Brock in MVEL itself. I think in the long run, we really need a new tag library to fully take advantage of the unfied EL. Even if we do that though, standard unified EL is not as powerful as OGNL. We would need to extend the language or be limited when compared to what is possible with OGNL today. Maybe for some people that's not an issue, but I fear that would keep some people from switching. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP EL in struts2 tags
I was working on a proof of concept for Unified EL: http://cwiki.apache.org/S2PLUGINS/unified-el-plugin.html I had a basic value stack up and running, however, I never took it any farther than that. Richard Burton is planning on implemented an MVEL stack in the near future, but he's waiting on some changes from Chris Brock in MVEL itself. I think in the long run, we really need a new tag library to fully take advantage of the unfied EL. Even if we do that though, standard unified EL is not as powerful as OGNL. We would need to extend the language or be limited when compared to what is possible with OGNL today. Maybe for some people that's not an issue, but I fear that would keep some people from switching. Tom Adam Hardy wrote: Ing. Andrea Vettori on 30/11/07 16:40, wrote: It seems to me that if the problem is triggered only when using a request parameter inside EL than EL should be on by default on s2 tags because using request parameters that way is bad practice (should'nt we use actions getters/setters and than call a jsp view?) I also think that this mixture of OGNL and EL is confusing and if I must choose to have only one I'll choose EL that's a standard and is supported on many other taglibs. I thought I heard Ted say a month ago that Don was doing some refactoring in XWork that would allow the script language to be pluggable. I missed any further comments on the subject though so I don't know if it was successful or still in the pipeline or what. Regards Adam - 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]
JRuby in Struts 2
These last 2 weeks, Richard Burton and I have been working on adding JRuby support to S2. We've been successful in getting a very basic action up and running, but we're running into something of an impedance mismatch between S2 and Ruby. Some of the issues we've run into: 1. Ruby's object properties are typeless, this means that when we go to set values on ruby actions and ruby domain objects, the type conversion is useless because we can't look at the property type to figure out what to convert it to. 2. No annotations in Ruby, a lot of functionality in S2 is driven through annotations. 3. For the reasons stated in #1 and #2, it's hard to recreate the domain model on a save action so the properties can be set back onto the domain model. For these reasons, it quickly becoming clear to me that we can't just create s2 actions in ruby. The language has too many differences with Java to really be a drop in replacement. (Groovy is much better in this regard) So the only alternative I can think of is to create a fundamentally new web framework that runs in s2, but uses Ruby as it's language. So I'm curious to see where others on the dev list see Ruby fitting into the s2 ecosystem. Should we have a rails-like framework that is pretty close to Ruby on Rails and makes an easy transition from rails? Or do we want something that diverges from the rails and provides an alternate to rails development on the JRuby platform? This is a Brave New World for struts so I think it's useful to get some ideas on where we might take this. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP EL in struts2 tags
It wouldn't even be a configuration change. Just drop the plugin jar in your s2 project and you're using my value stack. (Most likely breaking a lot of your OGNL) At this point, we execute the unified EL outside of the JSP engine, within the tags/value stack. So at a minimum, if we wanted to support EL at a JSP level, we'd have to create a new tld file. I'm not sure how that would work with the existing tags, it's been a while since I've written a taglib outside of s2/webwork. It all depends on how seamlessly you would want it to work with existing JSP taglibs, like JSTL. The work I've done would certainly be a darn good start. If we needed a whole new taglib, I think that would be a good amount of work. Tom Adam Hardy wrote: Very interesting. The situation at the moment is that EL and OGNL should not be used together, for security reasons as I understand it, and therefore S2 doesn't allow EL. It seems the ideal solution is to offer the option of either EL or OGNL, with only a change in one configuration option needed to specify which. Tom Schneider on 02/12/07 19:34, wrote: I was working on a proof of concept for Unified EL: http://cwiki.apache.org/S2PLUGINS/unified-el-plugin.html I had a basic value stack up and running, however, I never took it any farther than that. Richard Burton is planning on implemented an MVEL stack in the near future, but he's waiting on some changes from Chris Brock in MVEL itself. I think in the long run, we really need a new tag library to fully take advantage of the unfied EL. Even if we do that though, standard unified EL is not as powerful as OGNL. We would need to extend the language or be limited when compared to what is possible with OGNL today. Maybe for some people that's not an issue, but I fear that would keep some people from switching. Tom - 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: JRuby in Struts 2
I agree, I think it would be interesting to create a plugin that gives us a seamless full stack: Struts2/Spring/JPA or Struts2/Guice/JPA. However, one of the advantages of Groovy/Ruby is the fact that the classes can be updated just by reloading the page and new language features, such as closures and dynamic properties. This is where rails really shines, it takes advantage of those language features in the framework itself. Since we're currently restricted to Java, that limits what we can do. We can get close, but can we get close enough. One of the areas where I plan on exploring this question is with validation. The current validation in s2 is ok for the basic stuff, but falls short when you start getting complicated validation logic. There just isn't good support out-of-the-box for this type of thing, so I was hoping to integrate some Grails validation support into s2/webwork. Closures are a very elegant way to define validation for a domain object, the simplicity of a declarative XML type syntax with the power of a full language. Tom Ted Husted wrote: I would say that Rails is an excellent source of inspiration, but I don't think Ruby or Rails is magic. Rails incorporates a number of good ideas, and a take no prisoners perspective toward productivity, but that doesn't mean every idea is perfectly implemented. It's my belief that we can achieve the same level of productivity in Java by using tools like Eclipse, Maven, and JPA to their full extent. I'm especially impressed by the plugins now available with MyEclipse. With Tomcat and Derby bundled in, we can download Java and MyEclipse and start writing enterprise-grade applications out of the box. A key to the success of Rails has been ActiveRecord. Likewise, a key to creating a highly productive Java stack is adopting and exploiting JPA. For the type of applications that most people write, especially with something like Rails, JPA is an ideal technology. I'm finishing up a JPA/Struts training course now. I'm presenting it next week, and after I hope to do a series of companion tutorials. I'm not sure that everyone realizes how close the Java ecosystem may be to a productivy tipping point, where we might see 2x and 3x gains, just by aggressively integrating and exploiting the tools we already have at our fingertips. -Ted. - 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: REST Plugin and auto-generated XHTML Views
Personally, I !!HATE!! writing xsl. I try to avoid it at all costs, but maybe others might feel differently. Is the idea here that the action would output XML then let the xsl processor on the client convert it to html? If so, would you expect the domain model to be automatically serialized to xml, or would there need to be code to do that? Also, would we need a new xsl for each screen? I guess I'm having trouble understanding exactly how this would work. Where I work, they used to do XML + XSL - HTML, but they did it server-side. It was terrible from a performance perspective--although moving it to the client might work better. I would still be a little hesitant to go down this path just because of the war stories I heard. :) I think I would rather see something more along the lines of rails/grails. Have a default template that's automatically used for list/edit/delete screens. If you need to diverge from the default, then you could generate a real view from the template and start with that. Tom Matt Raible wrote: I just thought of something that might be an easy way to generate XHTML views for the REST Plugin. What if we used XSL on the client-side with the XML views? As far as browser capabilities, I think client-side XSL could be a hidden gem that hasn't been looked at in a while. Of course, it could also be something that doesn't work very well across browsers. Do you guys think it's worth looking into? If it works, .html (or .xhtml) could render HTML views and we could allow users to override the XSL stylesheet. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Googlecode Maven Repository for External Struts 2 Plugins
I think having separate googlecode projects for each plugin has worked well up to this point. Creating a googlecode project is quick and easy. Googlecode seems to be designed to have a lot of really small projects, rather than one big projects with many subprojects. The one thing that ties everything together is the plugin registry. If anything, I'd rather see that expanded. Maybe add a list of developers to the plugin registry. I think the apache developers would feel more obligated to maintain something hosted on Apache as opposed to something hosted on googlecode. As you may be able to tell, not a lot of the googlecode plugin sites have a ton of content. The only reason I created a common maven repository is so that end users only have to add one plugin repository to get access to most of the plugins. Ted Husted wrote: Very cool, Tom. Has anyone started a shared GoogleCode project for Struts 2 plugins yet? The notion being that instead of everyone starting up one-off projects, we could have one GC project that anyone with a Google ID could join and use to maintain a third-party Struts 2 plugin -- a Struts 2 Plugin Commons. Of course, the group could still have a select group of owners that could remove someone who joined and then turned out to be a troll. -Ted. On Nov 25, 2007 10:12 AM, Tom Schneider [EMAIL PROTECTED] wrote: Hey all, I finally figured out a way to host a maven repository on googlecode. This should greatly simplify using googlecode hosted plugins in Struts 2. For me, it's also much nicer to use maven to deploy than trying to get a jar manually uploaded into the central repository. Instructions on how to use this repo for Struts 2 projects are at: http://code.google.com/p/struts2plugin-maven-repo/ Anyone who has a plugin hosted at googlecode can use this maven repository to host their plugin. (I've already added several developers that I know of, if your not in the list let me know) I've also already added several of my more popular plugins. I plan on adding the rest as time permits. Please look at the scope plugin (on googlecode) for an example of how to configure maven to deploy to this repository. Tom - 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: Googlecode Maven Repository for External Struts 2 Plugins
Wendy, I'm all for syncing it with the central repository, it's just a question of how. Googlecode doesn't give shell access so I have no access to cron to sync things up. I could sync it up manually by checking it out and running the rsync on my local machine, but that seems less than ideal. Any suggestions would be greatly appreciated. Tom On Nov 27, 2007 11:04 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/25/07, Tom Schneider [EMAIL PROTECTED] wrote: Hey all, I finally figured out a way to host a maven repository on googlecode. This should greatly simplify using googlecode hosted plugins in Struts 2. For me, it's also much nicer to use maven to deploy than trying to get a jar manually uploaded into the central repository. Instructions on how to use this repo for Struts 2 projects are at: http://code.google.com/p/struts2plugin-maven-repo/ On behalf of Maven users everywhere, please consider getting this synced with the central Maven repository. (I think that mostly works via rsync right now, but hopefully something can be arranged to handle svn.) Having to add an additional repository to your settings is a pain, and causes things like archetypes to not Just Work like they're supposed to. -- 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]
Did I break bamboo or is bamboo broken?
I checked in a very minor change for WW-2328 and now the Struts2PortletTest is failing in both the java5 and java6 bamboo builds--but with different exceptions. I have a clean checkout of struts2 and everything builds fine locally with a mvn -Pall build. So is this a case of gremlins in the s2 build, or did I really break something and just can't reproduce it? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Googlecode Maven Repository for External Struts 2 Plugins
Hey all, I finally figured out a way to host a maven repository on googlecode. This should greatly simplify using googlecode hosted plugins in Struts 2. For me, it's also much nicer to use maven to deploy than trying to get a jar manually uploaded into the central repository. Instructions on how to use this repo for Struts 2 projects are at: http://code.google.com/p/struts2plugin-maven-repo/ Anyone who has a plugin hosted at googlecode can use this maven repository to host their plugin. (I've already added several developers that I know of, if your not in the list let me know) I've also already added several of my more popular plugins. I plan on adding the rest as time permits. Please look at the scope plugin (on googlecode) for an example of how to configure maven to deploy to this repository. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
Ted, I finally had a chance to look at your JPA mailreader. I know this was in the original, but I really don't like the way that they have most of the functionality for the actions is in a superclass. To me, that's hiding functionality. (Especially when the domain model is in the super class) And this become problematic on bigger projects. Do you have multiple superclasses to extend from with different domain models? What if you need functionality from 2 different superclasses. At a certain size of project this technique breaks down and it irritates me that the standard example shows it this way. I also don't like having a separate create vs. update action. My general rule of thumb is: if the domain model is the same and the use cases are closely related, it should be the same action. I don't generally combine list and edit actions, but the create/edit/save functionality will all be in one class as would be the list/paging/sort use cases. Why are the name queries on the domain object? I don't dislike it, I'm just curious about why you took that approach. I think the validation annotations are ugly and hard to read, but others may disagree. I do like how grails uses enclosures to capture that information, can you convert this example to grails? :) I'm not a fan of having a separate interface for the Manager classes, just for the sake of having an interface. If it's unlikely that there will ever be another implementation, then it should just be a class. One argument you could make is: Well what if you switch data storage technologies? Well, we just did that in this example and the interfaces had to be redesigned, so did they really buy you anything? Again I cringe at seeing a superclass for all domain objects. I think it makes sense for the managers to have a superclass though. In my experience with big projects, having a superclass for domain objects doesn't make a lot of sense. I hope I haven't been too brutal with my comments. :) I'm so glad we finally have a mailreader example that uses JPA. A lot of what you see here is my experience from working with webwork on a large (200+ action) project. There's lots of things that seem fine on a small scale, but when you have to scale up to that size, lots of things become problematic. I'd also be curious to find out how others have structured larger projects in webwork/struts. I think that's helpful because we spent a lot of time reinventing the wheel when it comes to large project best practices. Tom Ted Husted wrote: The work-in-progress is checked into the sandbox now. * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/ I'll track further work through https://issues.apache.org/struts/browse/WW-1399 This is still very much a prototype, and I would gladly receive any suggestions. -Ted. - 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 2 Plugin for Grails?
For those interested, Mark and I have been collaborating on a proof of concept for this idea. Details are here: http://cwiki.apache.org/confluence/display/S2PLUGINS/Grails+Plugin We have a simple precompiled groovy controller and GSP up and running. On Nov 13, 2007 10:38 PM, Vinny [EMAIL PROTECTED] wrote: My unsolicited 2 cents. The idea of integrating Grails scaffolding with Struts 2 has been bouncing in my head for few weeks now. The Grails CRUD is a true sweet spot for me but Struts still excels when it's time to move beyond a CRUD Action. Getting the 2 frameworks working together would be awesome. Looking forward to see where this goes. On Nov 13, 2007 9:00 AM, Tom Schneider [EMAIL PROTECTED] wrote: Just for completeness I'd think we'd want a GSPResult. Just because it's slow now, doesn't mean it will be slow in the future. (Look at how slow freemarker was before we tweaked it) Also, for those looking to migrate over, if GSP isn't supported, that might be a issue for existing grails apps. And who says that Struts 2 devs recommend Freemarker? I sure don't. :) Tom Matt Raible wrote: I don't know if we'd really need to support GSPResult in a Struts 2 Plugin. AFAIK, the slowest part of Grails is GSP. http://tinyurl.com/2298jh If we were to write a plugin, would it implement the same scaffolding that Grails has by default? If so, it might be better to use FreeMarker since that seems to be a recommended choice among Struts 2 developers. I don't believe there's a FreeMarker Plugin for Grails, but I'd be interested in creating one. A colleague of mine has been successful in making Grails work with JSP. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- The Street Programmer http://streetprogrammer.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
Are you worried about optimistic locking at all? (I'm guessing not for this simple example) Although I think your technique is clever, in a situation where optimistic locking is used, you should really be editing the object that was originally read from the database. Might I suggest the scope plugin. :) I'm not sure we'd want to introduce optimistic locking in a simple example--although it would be good to have one example that uses it. Tom On Nov 15, 2007 2:54 AM, Ted Husted [EMAIL PROTECTED] wrote: I'm starting to make some progress on this again. I having great fun re-discovering how some of the S2 features work together. For example, custom type converters and persistence URL parameters are a great tag team. Given a converter for user, and a parameter like ?user=husted, S2 can automatically restore the husted user from the database, and any other url tags on the result page are also automatically embellished with ?user=husted again. Though, there's more to do, since the JPA merging isn't working quite right yet. :( -Ted. - 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: Confluence Rate Plugin for the Plugin Registry
Thanks for doing this Don, I appreciate you taking the lead on this. Did you vote for all your own plugins? :) Tom On Nov 14, 2007 4:17 PM, Don Brown [EMAIL PROTECTED] wrote: Done. Unfortunately, the latest version requires a newer version of Confluence, so I installed an older version. I placed the macro on each plugin page, but found a couple of issues: * Anyone can reset the ratings * The table report doesn't seem to work right, so I didn't put that report on the home page * New votes won't kick off an export of the page, so users using the static page won't see the new votes Still, I think it is better than nothing, so vote away. Don On 11/11/07, Tom Schneider [EMAIL PROTECTED] wrote: I know I've mentioned this before, but I was wondering if we could use this plugin: http://www.atlassian.com/software/confluence/plugins/rate.jsp To provide user rating capabilities for the plugin registry. As more and more of the core functionality becomes plugins, I think it makes sense to let people vote on the plugins so new users have an idea of which plugins are the most popular. Tom - 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: Struts 2 Plugin for Grails?
Just for completeness I'd think we'd want a GSPResult. Just because it's slow now, doesn't mean it will be slow in the future. (Look at how slow freemarker was before we tweaked it) Also, for those looking to migrate over, if GSP isn't supported, that might be a issue for existing grails apps. And who says that Struts 2 devs recommend Freemarker? I sure don't. :) Tom Matt Raible wrote: I don't know if we'd really need to support GSPResult in a Struts 2 Plugin. AFAIK, the slowest part of Grails is GSP. http://tinyurl.com/2298jh If we were to write a plugin, would it implement the same scaffolding that Grails has by default? If so, it might be better to use FreeMarker since that seems to be a recommended choice among Struts 2 developers. I don't believe there's a FreeMarker Plugin for Grails, but I'd be interested in creating one. A colleague of mine has been successful in making Grails work with JSP. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
Yes, avoid JpaTemplate, just like HibernateTemplate should be avoided. Shouldn't be necessary with the latest versions of the respective frameworks. Tom On Nov 12, 2007 9:17 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: I can agree with that... I'm still thinking of avoiding JpaTemplate though because they indicate that it only exists to help people used to HibernateTemplate / JdoTemplate. -Wes On 11/12/07, Tom Schneider [EMAIL PROTECTED] wrote: My vote is to just use spring, for both EntityManagerFactory injection and Transaction Management. As Richard and I were discussing this weekend, Spring is a very common framework when used with Struts. It will also provide a full stack Struts/Spring/JPA example. Tom On Nov 12, 2007 9:05 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: Hello, I've been quietly learning JPA / implementing a JPA struts2-mailreader. I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - 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] -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - 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]
Confluence Rate Plugin for the Plugin Registry
I know I've mentioned this before, but I was wondering if we could use this plugin: http://www.atlassian.com/software/confluence/plugins/rate.jsp To provide user rating capabilities for the plugin registry. As more and more of the core functionality becomes plugins, I think it makes sense to let people vote on the plugins so new users have an idea of which plugins are the most popular. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 Plugin for Grails?
Mark, I was reading Getting Started With Grails this weekend and the more I look at Grails, the more I see your Groovy Works effort fitting into a Grails mini-porting effort to Struts 2. Much of what you describe is already in Grails and I think the last thing we need is yet another groovy web framework. :) Just to expand upon this, I think there are 3 main pieces we would need to make this work: 1. A new plugin based on Don's rest plugin that maps incoming request to grails controllers. 2. A grails controller engine that can take the grails request, provide the necessary context and execute a grails controller. 3. A GSPResult that can create the context for the GSP page and execute the GSP page. I did some work on this over the weekend and it didn't take too much effort to get a GSPResult going. (Although the templated executed, it didn't display any data because I didn't have a ModelAndView for the template to run against) Tom Mark Menard wrote: On 11/7/07 2:58 PM, Tom Schneider [EMAIL PROTECTED] wrote: They are very similar. The difference used to be that s2ss did not require Spring, or didn't support it. I don't exactly recall. Groovy Works requires and uses Spring to wire the dependencies of the objects it manufactures. Additionally I think the directions were different. It was my plan, if I had more time, to really build on the Groovy Works thing and make it more like a Groovy version of Struts 2 with an integrated stack. I really haven't had time to pursue that goal. The idea was download GW's and its maven template. Run the template and code without need for XML, with a well defined project structure, ORM in place, etc. Obviously I haven't gotten that far, and other things have come along in S2 that do some of those things, like SmartURLs, code behing, zero config, etc. Mark - 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 2 Plugin for Grails?
See my comments below: Mark Menard wrote: On 11/11/07 5:07 PM, Tom Schneider [EMAIL PROTECTED] wrote I will agree with you, and I've decided I'm done reinventing wheels. So, I'm game. I'm very pressed for time, but I'm definitely interested in this. I think a bridge from Java based Struts 2 development into Groovy is really exciting. We have realized some serious productivity gains using Groovy with Struts 2 in the simple way we've been using it in house for some time now. Good, I'm glad we're on the same page. I really liked some of the stuff I saw with Groovy/Grails. No rush here, I just wanted to throw this out there in case anyone else was interested in pursuing this. (Don expressed interest at one point) 3. A GSPResult that can create the context for the GSP page and execute the GSP page. I did some work on this over the weekend and it didn't take too much effort to get a GSPResult going. (Although the templated executed, it didn't display any data because I didn't have a ModelAndView for the template to run against) I think someone has done a GSP result. It might make some sense to look at that. Close, but not exactly a GSPResult: http://struts.apache.org/2.x/docs/groovyresult.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
Putting down my work would only motivate me more. :) That's exactly how this was started back in February--Chris Brock was bragging about how superior MVEL was and how slow OGNL was. Well, we'll show him! Tom On 11/7/07, Ian Roughley [EMAIL PROTECTED] wrote: It's great that Tom is doing this work, and it wasn't my intent to put down the effort. I guess I was just trying to preempt given some of the OGNL threads. /Ian Tom Schneider wrote: LOL, I didn't know my efforts were going to cause such a raucous. :) Ted is correct--I started this on Saturday on a whim. At this point it is completely experimental--we have a long ways to go before it is even close to usable. However, I was able to execute a simple expression using my value stack, which for me, was a worthwhile accomplishment. I didn't want Don's work to abstract away the value stack to be completely wasted, we needed at least one other value stack implementation to truly test his changes. Don did good work, but there is still a lot of OGNLisms that have crept into the code over time. It would be nice to find and eliminate these Ian brings up a good point in that we'll have to decide how to handle some things like I18N/type conversion/method invocation. Not all EL's are created equal and OGNL probably is a little more flexible and powerful than most. Then even if we get all that working, what's the migration strategy? Tom - 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 2 Plugin for Grails?
Interesting idea! Another plug-in idea would be to see if there was a way to integrate grails flow: http://www.jcatalog.com/oss/grailsflow/whygrailsflow.html I've been considering ways to make the Spring Webflow Plugin easier. (We all know how much you like that plugin, Matt) There's just too much overlap between what the SWF XML does and what the XWork XML does. Tom On 11/7/07, Matt Raible [EMAIL PROTECTED] wrote: Has anyone thought about creating a Struts 2 Plugin for Grails? There's one for Wicket - which proves you don't have to use the default web framework (Spring MVC). http://grails.org/Wicket+Plugin IMO, Grails Controllers look a lot more like Struts Actions than they do Spring MVC. I really like the productivity Groovy gives you and I'm impressed with Grails. I especially like it because it uses all the same underlying technologies as AppFuse - it just simplifies things. Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 Plugin for Grails?
How are http://code.google.com/p/s2ss/ and http://code.google.com/p/groovyworks/ different? Looking at the code they look very similar. I've been trying to make sure the Plugin Registry is up to date and has all the plugins that are available, so I'm wondering if these are 2 separate entries, or if they are essentially the same thing. Thanks, Tom On 11/7/07, Mark Menard [EMAIL PROTECTED] wrote: On 11/7/07 1:38 PM, Matt Raible [EMAIL PROTECTED] wrote: What I'd like is to use Grails to develop my application, but have it use Struts 2 under-the-covers instead of Spring MVC. As far as code differences between writing a Spring MVC Grails Controller and a Struts 2 Grails Controller - I don't think there needs to be any. Hmmm This sounds a lot like what I've been working with for the past year sort of. I'm not using Grails, but I have been using Groovy over Struts 2. I really haven't dug into Grails much, only picked over the transactions and proxy stuff deep in the framework at one point, but it seems to me that Grail is fairly closely wedded to Spring MVC under the covers. At least from outward appearances. I think swapping the underlying framework would be a lot of work, and would make the framework into something else, so to speak. I doubt it could be done without creating incompatibilities. Now, if it could be done that would be really cool and I'd probably migrate my current project to it to take advantage of the highly integrated stack of Grails. The problem I'm looking to solve is one where companies are using two web frameworks: a dynamic one (Grails) and a static one (Struts 2). Yup. Understood. Take a look at: http://code.google.com/p/groovyworks/ It's young, but it does allow development of pretty much everything in Groovy over Struts 2. It's really not hard. You just need an object factory that can manufacture objects from Groovy scripts. Then use Spring's scripting support for your service beans and DAO's. (The nice thing about this setup is you only need to restart if you change an interface or your domain model.) Now, with Groovy 1.1's support for annotations you can use all the neat stuff that's in S2 and can even do your domain objects in Groovy. Now, with all of that said I'm interested in what you find when you dig into Grails. If looks feasible let me know. I might be able to come up for air from this project I've been on and be able to lend a hand. Mark -- Mark Menard personal: http://www.vitarara.org/ business: http://www.vitarara.net/ - 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: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
I agree, there's many failure modes that aren't being handle well in
the value stack. Hopefully having more than one implementation will
point to areas that need improvement.
Another issue I ran into with regard to the ParametersInterceptor is
that we are currently filtering anything that has a '#' in it. This
mean we can never support deferred expressions such as
#{exampleBean.exampleProperty}. My fix for this was to all anything
that starts with '#{'.
On 11/7/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
Tom Schneider wrote:
On 11/6/07, Don Brown [EMAIL PROTECTED] wrote:
Type conversion isn't tied to OGNL in 2.1. XWork has a new API
(copied from OGNL) to abstract type conversion. Of course not all
EL's support type conversion in the same way, so there may be issues
down the road. i18N isn't tied at all to OGNL, so I agree with Chris
here as well.
That's good to hear, I haven't gotten far enough to fully implement
type conversion at this point, but that is one of the next things I'll
be working on.
It would definitely be nice to have a bit more robust type conversion
handling that can differentiate between failed conversion (i.e. 'fred'
isn't a number dude) and invalid type conversion configuration.
I did some work on support for attributes within the parameters
interceptor so that I could pass information like date format and
currency code to the type converters. The biggest issue I had with this
was that it was impossible to tell XWork that I had configured an
invalid date format and to explode nicely with a solid error message.
So, instead I just log a stack trace to the logs and thrown an
exception, which XWork interprets as a failed conversion. I'd like to
see the type converter interface have to well known and checked
exceptions thrown:
com.opensymphony.xwork2.conversion.FailedConversionException
com.opensymphony.xwork2.conversion.ConverterConfigurationException
These would be caught and handled appropriately by XWork.
It would also be nice to settle on a good handling for additional
information for each parameter similar to my attributes handling here:
http://vertigo-java.googlecode.com/svn/vertigo-core/trunk/src/java/main/org/inversoft/vertigo/struts/interceptor/VertigoParametersInterceptor.java
-bp
-
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: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
Well, Richard Burton is supposed to be working on an MVEL value stack, so hopefully we'll be able to pit them all against each other. :) Tom On 11/7/07, Chris Brock [EMAIL PROTECTED] wrote: For the record, I still maintain that it's better :) Tom Schneider wrote: Putting down my work would only motivate me more. :) That's exactly how this was started back in February--Chris Brock was bragging about how superior MVEL was and how slow OGNL was. Well, we'll show him! Tom On 11/7/07, Ian Roughley [EMAIL PROTECTED] wrote: It's great that Tom is doing this work, and it wasn't my intent to put down the effort. I guess I was just trying to preempt given some of the OGNL threads. /Ian Tom Schneider wrote: LOL, I didn't know my efforts were going to cause such a raucous. :) Ted is correct--I started this on Saturday on a whim. At this point it is completely experimental--we have a long ways to go before it is even close to usable. However, I was able to execute a simple expression using my value stack, which for me, was a worthwhile accomplishment. I didn't want Don's work to abstract away the value stack to be completely wasted, we needed at least one other value stack implementation to truly test his changes. Don did good work, but there is still a lot of OGNLisms that have crept into the code over time. It would be nice to find and eliminate these Ian brings up a good point in that we'll have to decide how to handle some things like I18N/type conversion/method invocation. Not all EL's are created equal and OGNL probably is a little more flexible and powerful than most. Then even if we get all that working, what's the migration strategy? Tom - 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] -- View this message in context: http://www.nabble.com/-s2--extras-lib-%28was-JUEL-plugin-%28was-Roadmap-for-the-core-taglib%29%29-tf4751589.html#a13635524 Sent from the Struts - Dev mailing list archive at Nabble.com. - 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: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
LOL, I didn't know my efforts were going to cause such a raucous. :) Ted is correct--I started this on Saturday on a whim. At this point it is completely experimental--we have a long ways to go before it is even close to usable. However, I was able to execute a simple expression using my value stack, which for me, was a worthwhile accomplishment. I didn't want Don's work to abstract away the value stack to be completely wasted, we needed at least one other value stack implementation to truly test his changes. Don did good work, but there is still a lot of OGNLisms that have crept into the code over time. It would be nice to find and eliminate these Ian brings up a good point in that we'll have to decide how to handle some things like I18N/type conversion/method invocation. Not all EL's are created equal and OGNL probably is a little more flexible and powerful than most. Then even if we get all that working, what's the migration strategy? Tom On 11/6/07, Ted Husted [EMAIL PROTECTED] wrote: On Nov 6, 2007 3:00 PM, Ian Roughley [EMAIL PROTECTED] wrote: For your comment, I am assuming you are saying the message is - changing the EL means changing everything the EL touches, and selecting an EL means making a choice on everything the EL touches, correct? At this point, JUEL is just something Tom committed to the sandbox, like yesterday (literally). We aren't sending any messages to anyone else, since I doubt that many of us have had a chance to look at it ourselves yet. If JUEL turns out to be too much work, then none of us will use it ourselves, and it will simply wither away. The general idea is that we are building the framework that we want to use, and then sharing the wealth with others. But, Job 1 is that it has to be the framework that *we* want to use. Evidentially, Tom thinks he might want to use a framework that supports JUEL. The next question is whether anyone else feels the same way. -Ted. - 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: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
On 11/6/07, Don Brown [EMAIL PROTECTED] wrote: Type conversion isn't tied to OGNL in 2.1. XWork has a new API (copied from OGNL) to abstract type conversion. Of course not all EL's support type conversion in the same way, so there may be issues down the road. i18N isn't tied at all to OGNL, so I agree with Chris here as well. That's good to hear, I haven't gotten far enough to fully implement type conversion at this point, but that is one of the next things I'll be working on. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Taglib Exercises Appilcation and ShowCase Expectations
I'm not sure it is practical for a junit test to test all the variations of the tags. Just setting up the expected output would be very tedious. I like the idea of having a taglib showcase to test all the tags--I looked at showcase the other day to see if it had this and it didn't. Also, being able to switch themes on the fly would be a good thing. Even in a taglib showcase, we couldn't possibly test every single tag variation, however, it would be a nice sanity check above the level of test case to verify we didn't totally mess something up. (That's always my fear with the ftl templates) Ted Husted wrote: Except that I'd have to learn to write them :) On Nov 4, 2007 7:51 AM, Don Brown [EMAIL PROTECTED] wrote: The junit tests actually have a pretty good set of functional, black box tests for the tags, although there are holes. Therefore, I don't think showing every single tag for the purposes of testing is necessary. Kudos for taking up showcase cleanup banner. - 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]
[s2] Roadmap for the core taglib
Speaking of the core taglib, what ARE we going to do with it. There's been talk of moving them to a separate plugin, reimplementing them in a java, etc. It would be nice to know from a roadmap prespective about where the core taglib is headed--I have several plugins that would be affected by it. At a minimum, if we're going to keep the ftl template at all, then I would recommend we bring in tabletags. (At least the paging and sorting tags) Looking at the downloads page for tabletags, there have been over 7000 downloads over the last year. That seems significant to me. The table tag itself probably needs a little TLC at the moment, but I think the other tags are pretty solid. I'm also open to looking at other tags that should be brought in--again this is contingent on what we decide to do with them pesky tags. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Roadmap for the core taglib
Ted Husted wrote: Don's also been doing some preliminary refactoring in XWork so that the expression language can be made pluggable, meaning we would also be able to plugin something else instead of OGNL. -Ted. You mean like JUEL? http://cwiki.apache.org/confluence/display/S2PLUGINS/JUEL+plugin :) Thanks for the info Ted, that helps me out. So looking down the road we might have: xml configuration or codebehind; new java taglib or current templating taglib; freemarker, velocity or JSP; OGNL, MVEL, or JUEL. I'm all for choice, but trying to support all those combinations might be challenging. I can just imagine the posts on the user list: Um.. I'm using Struts 2 with the code behind and rest plugin and the java taglib in velocity with MVEL and my page doesn't display I'm not saying we shouldn't persue these endeavors, but I think it's helpful to consider things from a new user perspective and decide if we're going to support every combination of technology. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] JUEL plugin (was Roadmap for the core taglib)
Isn't that what Ted wanted? A new plug-in a day for 60 days. :) I have one lined up for tomorrow. Tom Don Brown wrote: Whoa, where did that one come from? I was just begging for such a plugin yesterday on #struts from Richard Burton, who is working on an MVEL one. I could see Struts 3 == new taglib + JUEL + robust rest and codebehind. As for the problem of so many combinations of plugins, I'm all for the proliferation of plugins, but do think we need to not ship with two plugins that solve the same problem. For example, it would be confusing to ship with two codebehind plugins or two expression language plugins, especially since the latter could require its own taglib. The distribution we ship as official Struts 2 should stay coherent and focused. Do - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Looks good to me. I was going to suggest putting this on the wiki, but a googlecode project is even better. So would the code for this new struts2 plugin live here or in the struts codebase? On 11/1/07, Ted Husted [EMAIL PROTECTED] wrote: Just to followup, I setup a Google Code site as a place to describe and design cross-platform technologies that pertain to web application development and deployment. For some time now, I've spent half my time working in .NET, which probably won't change for another year or two, and so working on cross-platform technologies is of great interest to me. I've extended the initial draft posted here to include the action URI to Action Class mappings. While based on SmartURLs and CodeBehind, the description goes beyond what either can do right now. * http://code.google.com/p/web-alignment-group/wiki/WAG_RFC_001 Before doing any more work on the description, I'd be very interested on feedback as to whether I'm making any sense, or whether the draft has turned into opaque gibberish :) -Ted. On Oct 17, 2007 2:24 AM, Ted Husted [EMAIL PROTECTED] wrote: Following up on suggestions made by Don and Brian, I'd like to propose that we draft a formal specification describing the logic to be used by the (deep-breath) Able/Code Behind/Zero-Config/SmartURLs plugin for 2.1. The purpose of the specification would be to better define what backward compatibility means, and also to encourage implementation of this pattern by other frameworks. Following is the beginning of an early draft of a proposed view-behind specification. (In case anyone is interested, I'm using the JSON-RPC specification format as a model.) If there is interest in this proposal, I'd suggest we decide whether to complete the specification as part of our documentation, or at some other location. Of course, people working with other frameworks (coughstripes/cough) would be welcome to join in. - 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: [S2] Plugins gone wild!
On 10/22/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: I'm still not 100% convinced there's a ton of benefit to this plugin frankly, other than perhaps visibility, but it's there now in any case. That how I feel too with most of the plugins I've written. I wish we could add a plugin voting/ranking system so we could see the most popular ones and which ones get the most votes. This would allow users to see which ones are high quality and which ones are more beta plugins. Most of the eclipse plugin sites I've seen have this type of functionality. Might be useful for the struts2 plugin site. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A session value is overwrited by demanding a browser.
No because OGNL can access the private Session variable directly. (I noticed this behavior when I was fixing a race condition) It first tries to call the getproperty(), if that fails, then it will turn on reflection accessibility and access the variable directly. On 10/17/07, Jim Cushing [EMAIL PROTECTED] wrote: I haven't tested this, but is the problem solved by making your getSession() method protected, instead of public? The SessionAware interface only requires a public setSession() method. If you haven't defined a getSession() method, or if it's already protected, then I suggest you file a JIRA ticket (http://issues.apache.org/struts/), perhaps with some sample code. On Oct 17, 2007, at 9:12 AM, Hisato Killing wrote: Hello. I'm sorry. Information that I had sent seems to have been insufficient. 1.This problem is caused in struts 2.0.9 and others perhaps. In that case, it is assumed that it is as follows. i. SomeAction is implements SessionAware. ii. And It is defined in struts-default. iii. devMode is true or false. [someValue] of the name of someKey enters in SessionMap when the request shown in that URL is processed. It is meant that [someValue] is an array including someValue. This causes ClassCastException in case of almost. [EMAIL PROTECTED] It is thought that this only has to be my mistake ,setting etc. Thanks - 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] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
First of all, I think Ted did a good job of getting a start on this. His proposal is a great start that would unify several misc things that really needed to be unified. (Especially for 2.1.x where it would be nice to have a unified approach to these things) Secondly, our company does the exact same thing that Brian's in that we have standardized components and I would love to have an open source standard to use. However, is that part of what Ted created, or is this a separate proposal? I really like the idea of having one place for xml configuration, whether it be struts config overrides, JPA class definitions or what-not, but that seems like a separate issue from what Ted is proposing. Tom On 10/17/07, Brian Pontarelli [EMAIL PROTECTED] wrote: Looks good. I like the name and most of the concepts. Here's some additional thoughts: 1. If no code component exists and a default is not available, the code invocation can be completely by-passed and processing should proceed with the view component handling. The caveat here is that this will require adding a goal to support for messaging, localization and i18n, since this is something that is currently cumbersome. Also, the default handling should be spelled out with Index actions and all the URL nuances like trailing slashes and such. 1.1 I'd like to add in a componentization goal here. SmartURLs and Vertigo are leveraging a file named META-INF/component.xml (inside JAR files) to specify not only all the action packages and the result locations for actions and views bundled inside JAR files, but also to specify JPA domain classes and other configuration for the component. This is HUGE for companies that like to build components and then just drop them in to web applications. We have a number of these including user admin, CMS, blogs, news, todo, etc. I think that expanding this into the specification will help solidify that this architecture can be done on Struts2 and that it is a goal of the project. Ted Husted wrote: Following up on suggestions made by Don and Brian, I'd like to propose that we draft a formal specification describing the logic to be used by the (deep-breath) Able/Code Behind/Zero-Config/SmartURLs plugin for 2.1. The purpose of the specification would be to better define what backward compatibility means, and also to encourage implementation of this pattern by other frameworks. Following is the beginning of an early draft of a proposed view-behind specification. (In case anyone is interested, I'm using the JSON-RPC specification format as a model.) If there is interest in this proposal, I'd suggest we decide whether to complete the specification as part of our documentation, or at some other location. Of course, people working with other frameworks (coughstripes/cough) would be welcome to join in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source and test maven artifacts for struts2
My apologies, I've located https://issues.apache.org/struts/browse/WW-2028 which addresses this issue, please disregard my original email. I'll take a look at this issue today since I've setup builds that have included source. Tom On 10/7/07, Tom Schneider [EMAIL PROTECTED] wrote: Is there anyplace where the source and test jars are deployed as part of a release? Looking in the central maven repository and on http://people.apache.org/repo/m2-ibiblio-rsync-repository, I only see the bin artifact. I ran into an issue with needing the test artifact because I extend a JUnit test to test some custom tags I wrote. Deploying the test artifact I could see skipping, however, it seems like having the source artifacts available via maven would be a useful thing. (In fact, it is recommended in the Maven artifact upload guide) Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Goal - no experimental code in core for 2.1
+1 for anything that makes configuration easier Don Brown wrote: With the latest refactorings in XWork that allow plugins to provide code that load Packages, I'd like to suggest that we make it a key design feature of Struts 2.1 that Core includes no code labeled experimental. Here is what I imagine it would entail: 1. Move the zero conf code (annotations and code from ClasspathConfigurationProvider) into the codebehind plugin. 2. Move restful mapper into its own plugin There are two main general advantages of this from a user perspective: 1. Code from core can be fully trusted to be deemed of GA quality 2. Using zero conf and restful features become easier While the first one is pretty self-explanatory, the second makes sense when you think about how plugins work. Currently, to use the zero conf or restful code, you have to have the right jars, config settings, and follow poorly documented rules. If, for example, the restful code was its own plugin, you could drop the restful jar in and it would configure your application with the appropriate settings automatically - disable .action extension, enable slashes in action names, set the restful mapper, etc. Right now, it takes some voodoo magic to get restful and zero conf working right (especially together), even for me and I wrote most of it :( By moving the zero conf code into the codebehind plugin, we also make it easier to maintain, document, and use for developers. Also, it makes it easier for other plugins, like SmartURL, to provide an alternate zero conf implementation. A different, but related discussion, is how best to provide zero conf in Struts 2, and honestly, I don't see a clear solution yet. What is in core now is ok, SmartURL improves things, but other parts I don't like as much, so by putting them all on the same playing field, I'd hope we encourage innovation. Anyways, back to the main topic, I'd like to get all experimental code out of core. Any 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]
Source and test maven artifacts for struts2
Is there anyplace where the source and test jars are deployed as part of a release? Looking in the central maven repository and on http://people.apache.org/repo/m2-ibiblio-rsync-repository, I only see the bin artifact. I ran into an issue with needing the test artifact because I extend a JUnit test to test some custom tags I wrote. Deploying the test artifact I could see skipping, however, it seems like having the source artifacts available via maven would be a useful thing. (In fact, it is recommended in the Maven artifact upload guide) Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WW-1399 - converting mailreader to hsqldb
http://openjpa.apache.org/ is an option too. Seems logical since it is an apache project. On 10/5/07, Ted Husted [EMAIL PROTECTED] wrote: On 10/5/07, Wes Wannemacher [EMAIL PROTECTED] wrote: I am poking around for things I can help with. I came across WW-1399 and I remember some discussion before on struts-[dev|user] that hibernate's license is not compatible with apache's. So, assuming we want to use ORM, is there a particular mapper I should look at? I could give this a try with cayenne. It isn't as popular, but mostly similar. One issue though is that Spring and cayenne don't make much sense, so it probably would not include DI... Anyhow, what are your thoughts? I could be wrong about hibernate, if it can be distributed with mailreader, I'll use it. Today, I would go with JPA and TopLink (we can distribute TopLink as a binary.) See the end of Musachy's tutorial. * http://struts.apache.org/2.x/docs/struts-2-spring-2-jpa-ajax.html BTW, I have a refactored version of the people example here: * https://sq1-struts2.googlecode.com/svn/trunk/articles/people In the Shale repository, there is a JPA MailReader implementation, but I haven't had a chance to try it out. * http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-mailreader-jpa/ A good way to go would be to snag the Shale JPA Mailreader classes, try them under Toplink, and make whatever changes we need to the MailReader to make it work. When Cayenne 3 comes out, we can try switching providers, to prove that JPA can be a commodity :) As far as the MailReader in general goes, the implementation could use an overhaul. The original MailReader DAO is quirky, and so the MailReader implementation has to work around the quirks. With a streamlined DAO, the MailReader implementation could also be streamlined. -- HTH, Ted Attend Migrating to Ajax at ApacheCon US 2007: * http://us.apachecon.com/us2007/program/talk/1883 - 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: [s2] The death of the .action extension
What kind of strange new world will it be without .action? I've grown so used to it I can't imagine not using it. So you're saying you would have the same url without the .action part? Now that we have all these options for mapping url's to actions/parameters, is there a new recommended approach that developers should follow? Essentially you are getting rid of the old recommended webwork approach. Options are great, but if you can't make heads or tails of which way is 'recommended' I think it may lead to confusion. (Not to mention more issues when trying support less experienced developers) It would require updating all the docs/examples with the new approach. Tom Don Brown wrote: A long time coming, it is now possible (and practical) to get rid of extensions altogether, hence the subject, the death of the .action extension. With WW-2163 [1], Struts can make the distinction between a setting that has Struts match all URL's, and one that only matches URLs with no extension, and furthermore, extension and no extension URLs can co-exist. Accordingly, I changed the default 'struts.action.extension' setting from 'action' to 'action,,' This allows the default-action-ref element in struts.xml to do what you would expect - let you define an action to handle directory URLs such as http://example.com/myapp/mynamespace/ In a future release, maybe 2.2, I'd like to get rid of the .action extension altogether. I think one of the key strengths of Struts 2 is its closeness to the HTTP protocol, and therefore, I think it has great potential to be a solid REST platform, an architectural style that leverages the features of HTTP rather than fight them. Here's to the death of the .action extension! :) Don [1] https://issues.apache.org/struts/browse/WW-2163 - 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: [s2] The death of the .action extension
Don Brown wrote: Right, and that's why I didn't move to kill it off for 2.1. Give it some time, let the feature get some exercise, then if all agree, we could change the default later. As with any new feature, I'd put it in a sort of experimental category for at least one major release. So, do you have a final goal in mind for this or are you just working to open up options? I'd be very interested in hearing of the any options we have. Are we moving more towards Rails, or are there other better alternatives? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Painless migration with WebWork 2 plugin
Nice work Don!
I attempted this a while back, but ran into some issues that I couldn't
reconcile. I'll definitely be trying this on our app.
Tom
Don Brown wrote:
I've completed a spike on a Struts 2 plugin for WebWork 2, providing a
drop-in replacement with no code or configuration file changes. So
far, I've only tested it with simple Spring-based applications, so I'm
sure there are more areas it will need to wrap, but so far, you just
drop in Struts 2 with this plugin to replace WebWork 2.
Since we changed packages for XWork 2, this was actually pretty easy.
In the plugin, I extended relevant interfaces and classes like so:
package com.opensymphony.xwork;
public interface Action extends com.opensymphony.xwork2.Action {}
The plugin then
* provides a com.opensymphony.webwork.dispatcher.FilterDispatcher class
* adds support for xwork.xml files (stubbing webwork-default.xml correctly)
* translates webwork.properties files
* provides the tags with expected URI and prefix (JSP, Freemarker,
and Velocity).
I hope to try the plugin on more advanced WebWork 2 applications
(Atlassian, my employer, has a couple), so I'm hopeful it can save us
a good amount of work.
http://cwiki.apache.org/S2PLUGINS/webwork2-plugin.html
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]
Re: [S2] Struts tags for generating html, head and body
I already created a body tag on our webwork project at work (we needed the onload event hook) +1 from me. Tom Ted Husted wrote: Another good use for head or body tags might be to generate a JavaScript hook. A head tag could also inject the doctype redtape, that we might otherwise paste into every page. On 8/24/07, Nils-Helge Garli [EMAIL PROTECTED] wrote: It would be nice having struts tags that generate the html, head and body sections of the HTML page. These tags could have support for different renderers, as the url and form tags have, that could be overriden in plugins like the portlet plugin. So when the tag runs in a regular servlet container, the tags creates regular html, head and body tags, but when it runs in a portlet container, it could be overriden to skip rendering, since portlets should only generate page fragments. This would make it easier to migrate webapps to portlet apps, since you no longer need to remove content from your JSPs, and also make it easier if you want a Struts 2 application to be able to run in both a servlet container and a portlet container. Do you think this would be useful, or is it just unnecessary overhead? Should we for instance write guidelines/tutorials on how to use SiteMesh for this purpose instead? Nils-H - 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 2.0.10 versus 2.1.0
I could see 2 ways of handling this and you'll have to provide your input as to which makes more sense: 1. Treat the compressed javascript as a maven artifact and create a custom maven mojo and artifact type to handle it. 2. Use the maven antrun plugin or the assembly plugin to create the compressed file. (is it just a zip file?) Option 2 will be easier to implement, option 1 will be more work, but it makes more sense if we'll have to do this type of thing for more javascript libraries. I've done option 2 myself recently, so I can provide some tips there. Option 1 would require a bit more programming effort. Tom Musachy Barroso wrote: By the way I forgot to bring this up, the compressed javascript files(custom Dojo build) is not built using maven, currently I build them on my machine and commit them, does anybody know how to automate that? I added a text file with instructions to the dojo plugin along with the js file required to build them - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0.10 versus 2.1.0
Looks to me like the maven antrun plugin would be a good choice for implementing this: http://maven.apache.org/plugins/maven-antrun-plugin/run-mojo.html It would just be a matter of implementing the ant scripts for this in the plugin's pom. Tom On 8/22/07, Musachy Barroso [EMAIL PROTECTED] wrote: Here is how to do it: http://www.dojotoolkit.org/book/dojo-book-0-4/part-6-customizing-dojo-builds-better-performance/dojo-build-system/creating-cust The short version is: 1. checkout Dojo's code (we can probably just use the code that is already in the plugin and add the build scripts) 2. Create a profile (it is already done) 3. Execute Dojo's build script with some parameters (pointing to our profile) 4. Rename the 2 main js files and copy them into the plugin musachy On 8/22/07, Tom Schneider [EMAIL PROTECTED] wrote: I could see 2 ways of handling this and you'll have to provide your input as to which makes more sense: 1. Treat the compressed javascript as a maven artifact and create a custom maven mojo and artifact type to handle it. 2. Use the maven antrun plugin or the assembly plugin to create the compressed file. (is it just a zip file?) Option 2 will be easier to implement, option 1 will be more work, but it makes more sense if we'll have to do this type of thing for more javascript libraries. I've done option 2 myself recently, so I can provide some tips there. Option 1 would require a bit more programming effort. Tom Musachy Barroso wrote: By the way I forgot to bring this up, the compressed javascript files(custom Dojo build) is not built using maven, currently I build them on my machine and commit them, does anybody know how to automate that? I added a text file with instructions to the dojo plugin along with the js file required to build them - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - 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: [S2] [2.1.x] Bundled Plugins
I disagree with moving the Spring plugin outside of the core set of plugins. I think a lot of people use Spring and it would be a shame to not have it as a core feature. Keep in mind that I think we run a huge risk (IMO) of plugins being unmaintained if we set them free, however, I'm more than happy to do it for the more fringe plugins that not a lot of people use. I also think the JSF plugin is more of a fringe plugin--I'd be curious to know how many people are actually using it in production. There has been no interest whatsoever of anyone helping out on table tags. I knew I wouldn't have the time to work on it after I initially created it, but I was hoping other developers would take interest. That hasn't happened. (I may get some time if we upgrade to struts 2 at work) If we want to integrate it into core, we need developers to really run with it and make it real. Right now it isn't production ready--I just haven't spent enough time with it. Everything else in your list looks good to me. Tom Ted Husted wrote: On 8/18/07, Musachy Barroso [EMAIL PROTECTED] wrote: do you mean to move the plugin out of Struts? Because Dojo is already on its own plugin in trunk. My question was whether we wanted to keep Dojo as part of the project, or move it GoogleCode, along with the YUI plugin. I think some of the other questions misunderstood where we already are, in that for 2.1.x Dojo is one of our bundled plugins, like Spring and JasperReports. Right now the bundled plugin list for 2.1.x is * codebehind * config-browser * dojo * jasperreports * jfreechart * jsf * pell-multichart * plexus * spring * struts1 * tiles The underlying question is whether we have active committers who actually *want* to maintain all of these plugins as part of the trunk. Initially, we dragged most of these along because there were part of WebWork and 2.0 was the backward-compatibility series. Moving forward, we might want to be more careful about the plugins that we bundle. One idea would be to create a Struts Plugin project somewhere, where third-party plugins could be maintained jointly. My suggestion would be to retain * codebehind * config-browser * jsf * struts1 * tiles and add (with the permission of the owners) * JSON Plugin * Table Tags * Smart URLs And then encourage the remainder be adopted by an independant open source project (while we keep a snapshot of what we have now in the Archive). * dojo * jasperreports * jfreechart * pell-multichart * plexus * spring Ideally, some of the other plugin projects might merge into the independant Struts Plugin project, making it easier for people to gain access later if the original author drifts awqay. Thoughts? -Ted. - 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 1/2 and Logging
So what determines what should be an instance logger and what should be a static logger? From the original article, they recommend creating the loggers as needed when logging in a static context. To me, that implies only instance level loggers are allowed globally to a class. In static contexts, you should get the loggers on an as needed basis. Tom Paul Benedict wrote: It doesn't have to be an all or nothing game either. Obviously, even in a shared library, instance loggers are not always appropriate. So it's definitely on a class by class basis. Frank W. Zammetti wrote: FWIW, my opinion would be go ahead and change it... unless someone can show where it would cause trouble, I'm in the better safe than sorry camp. I know of a number of instances where I've seen Struts installed in a shared way, either at EAR-level or something like Tomcat's shared libs directory... I've never heard any trouble reported from those cases though to be fair. I think the performance/memory implications are the only thing that might stop you from wanting to do this... perhaps some benchmarking is in order? Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Heads Up: possible DOS problem
ww:property value=[EMAIL PROTECTED]@currentTimeMillis()}/ works for me, so I think a remote execution is definitely possible. (Something like Runtime.exec would probably cause a lot of problems) Do we need to filter certain classes/methods? I'm not sure how else we would solve this--this could allow someone to do some nasty stuff. Tom On 7/5/07, Bob Lee [EMAIL PROTECTED] wrote: On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote: The DoS is because you can trigger an infinite loop. My point is, can you execute arbitrary code on the server? If so, a DoS is the least of your worries. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Portlet plugin
Nils, This is a great start. I had wanted to do this myself, but I never found the time. I only took a brief look at the patch, but a few things jumped out at me: 1. I'm not sure the UrlRendererFactory is needed. I believe the whole purpose of guice is to not have anymore factories anymore, so guice should just inject the necessary UrlRenderer. (especially if they are stateless) 2. As a first step in separating out the url building logic I like how you have the form url building seperate from the typical url building. I tried to combine these and couldn't find a clean way to resolve the differences. HTH, Tom I have finally been able to extract the portlet code into a plugin, but it required some shortcuts due to couplings between the Components (URL, Form and it's super classes) and generating the URLs. But at least all tests pass, and there are no more dependencies to the portlet API in the core. I have attached the files as patches to the JIRA ticket (https://issues.apache.org/struts/browse/WW-1645), since it needs a review and probably some discussion. Nils-H On 4/11/07, Nils-Helge Garli [EMAIL PROTECTED] wrote: I have started the process of moving the portlet code to a plugin. But any further progress requires the url building abstraction discussed earlier. What is the status for this code? Also, I think the code in general would benefit from a common abstraction of the servlet- and portlet types (request, response, context etc). It would most certainly reduce the amount of almost duplicated code needed to operate Struts in a portlet. Nils-H On 3/26/07, Ted Husted [EMAIL PROTECTED] wrote: The trunk is the correct place (we branched for 2.0.x). On 3/25/07, Nils-Helge Garli [EMAIL PROTECTED] wrote: Hi! I want to start looking into moving the portlet support to a plugin, but need a little guidance to get started. - What is the status of refactoring the URL-building, as discussed in previous mail threads? - From what I understand, a hook for injecting a URL builder implementation from the plugin must be provided. How is that achieved? - Is trunk the correct place to work on, or will a 2.1.x branch be created? Nils-H - 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: Table Tag With Freemarker Templates
The current version of table tags does use freemarker templates when rendering a table. Tom On 5/31/07, André Faria [EMAIL PROTECTED] wrote: Hi All, I am interested in Table Tags Project to apply it resources in a project with Struts 2, but I'd like to know if you are planning to implement some functionality to add a freemarker template in the tags using the theme attribute like in old Struts 2 s:table tag. Thank's André Faria / / - 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: [S2] Where's Waldo?
I'm here, I've just been insanely busy with other things for the last 2 months. Can you believe they actually want me to write non-open-source business code at work? Absolutely ridiculous. :) I'm hoping things will slow down a bit now, but I can't make any promises. Tom Philip Luppens wrote: Hmm, same here. Too busy with the new job. I'm still working on various S2 plugins at nighttime. As for the rest of the old WW team I know about: - Rainer: too much work for clients atm - Rene: on vacation - Ian: writing book(s) - Toby: focused on bugfixes for WW atm (has some legacy apps to take care of) Personally, I'd like to know what Nils is doing (he is/was working on the portlet plugin, but waiting for the URLBuilder), and where Tom is atm (haven't heard from him in a long time). I suppose everyone is just a tad too busy or on vacation .. Cheers, Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jar to their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - 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: OGNL performance detrimental to Struts 2
Well, there is a small risk of things being cached and a developer relying on the behavior of not caching the templates. However, I think those cases will be rare and it would benefit many people. Tom Musachy Barroso wrote: Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - 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: Spring Web Flow Plugin in Maven Repo?
No, you're not missing anything. I never got around to creating an upload request. Feel free to submit it. :-) I should have some time this weekend to roll another release (with SWF 1.0.1) and upload it to maven. Tom mraible wrote: The Spring Web Flow plugin looks like it's in the form of a Maven bundle ready to upload, but I can't find it in Maven's central repository. Am I missing something? http://code.google.com/p/struts2webflow/downloads/list Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Enhancement to Zero Config: Default Success Result
See http://struts.apache.org/2.x/docs/codebehind-plugin.html The very first line from the docs are: * Default results* - The purpose of most Actions is to execute code to prepare the data for a specific page. The name of this page is often the same as the Action itself. Is this not what your looking for, or is there more to it? I've seen the Spring MVC support for this and this looks like exactly the same functionality to me. In fact the struts version is more flexible because it looks for /NAMESPACE/ACTION-RESULT.jsp as well as /NAMESPACE/ACTION.jsp. Tom mraible wrote: Is there a default success result when using Zero configuration? I'd like to see this feature added. Spring MVC has something similar, as does Tapestry. It's quite nice to simple create a controller, as well as a view without having to configure anything. http://www.springframework.org/docs/reference/mvc.html#mvc-coc-r2vnt Implementation ideas: specify the default directory on the filter, then name the JSP the same as the URL. For example, TestAction would expect a test.jsp page. Specify the default result type should be possible in struts.xml. Maybe this setting should go there as well. Does the actionPackages configuration belong in struts.xml instead of web.xml? Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Enhancement to Zero Config: Default Success Result
Guys, I think the codebehind plugin already supports all this. (The codebehind plugin consists of 1 whole java file!!) The property for default location of jsp's is: struts.codebehind.pathPrefix The docs just need to be updated. Looking at the code, it looks like it also supports all result types, not just success or input. Cheers to Don for covering all the bases. :-) Tom David H. DeWolf wrote: mraible wrote: Yes, this is what I'm looking for, and I was able to use it successfully. Strangely enough, I couldn't get the @Result annotation to work with zero config. Is there anything special I need to do for that? I use it and don't recall anything special. Do you have errors that are occurring? What happens when you try to use it? One change I'd like to see to the codebehind plugin is the ability to specify the default location of pages. For example WEB-INF/pages. Or is that what the struts.codebehind.defaultPackage constant is for? I'd also like to expand support so that all result values can be used as post fixes. Instead of supporting just page-success.jsp and page-input.jsp, why not support page-whatevertheresultis.jsp. Thoughts? I think it makes sense to combine Zero Config and Code Behind as they both seem to be doing the same thing. Zero config means no config, and if there's still an @Result required - that's configuration, no? ;-) I have a hard time envisioning someone using them separately as well. . . -D Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Guice 1.0rc2
There is no pico/nanocontainer support in struts2 at the moment. (I don't think it made it over in the merger) IMO this is best implemented as an external plugin anyhow. All external plugins thus far have used googlecode to host their projects. If you do create this plugin, please register your plugin in the plugin registry: http://cwiki.apache.org/S2PLUGINS/home.html It shouldn't be too difficult to convert the existing WW support to struts2, although ironically, you'll have to register it with Guice. :o) Tom On 2/26/07, Philip Luppens [EMAIL PROTECTED] wrote: On 2/26/07, Konstantin Priblouda [EMAIL PROTECTED] wrote: --- Bob Lee [EMAIL PROTECTED] wrote: [snip] Pico is also integated with WW2 and struts ( if not - I can contribute it if you like ) regards, Afaik, there's no Pico plugin available for Struts 2. So, yes, Konstantin, if you're willing to provide us with one and register it on the Plugin registry, that would certainly be welcome. Cheers, Phil -- iDTV System Engineer Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John F. Woods - 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: Guice 1.0rc2
The architecture between webwork and struts2 has changed. Every other project that provides the same functionality, (e.g. Plexus, Spring, etc.) was written as a plugin in Struts2. Technically it is possible to use the object factories, interceptors, etc. without using the plugin architecture but it makes it much more difficult for end users. With a plugin, you can just drop it in, do some very minimal config and go. On 2/26/07, Konstantin Priblouda [EMAIL PROTECTED] wrote: If S2 architecture is the same than WW2, then it is not necessary to register it as plugin - it's just an object factory and couple of filters ( which are independet of S2/WW ) regards, [ Konstantin Pribluda http://www.pribluda.de ] Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - 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: [s2] Struts 2.0.7 Status
Core Plugins This is more of a 2.1.x status item, but looking forward, do we want to bundle so many plugins with the core, or do we want to try and cut some of these loose somehow? Of course, there is also something to be said for letting sleeping dogs lie. I think we should cut some of them loose. The only question in my mind is: if we cut them loose, can we still include them in the core? There's probably quite a few plugins that should be included even if we cut them loose. Also, there's probably some projects, like tabletags, that is replacing core functionality that should be included in the struts distribution itself. (Once we feel it is of sufficient quality of course) I'm glad everyone is following my trend to use googlecode for external projects. :) It's actually a really good fit for this kind of stuff compared to sourceforge. I've been using the plugin registry for all my documentation since I like Confluence better than the google wiki. :) I hope no one minds. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Development Infrastructure (Re: [s2] Struts 2.0.7 Status)
There's a few parts of GoogleCode that are still quirky. I'm disappointed that the Subversion alerts do not include the DIFFs. We've had to resort to posting our own daily DIFFs. The immutable issue descriptions is also awkward. But, the other sites also have their own quirks too. It does seem like GC is on the right track, so it's going to remain my own independent open source host of choice for now. I'm no fan of moin-moin, but it will be interesting to see what happens with this notion of storing wiki pages under SVN. I agree that the issue tracking leaves much to be desired compared to JIRA, but since my projects aren't real active, I've only had to deal with 5 issues total so far. :-) Meanwhile, for our next battle, what do we need to do to get a JiveForum setup for the Struts list somewhere. In the past, the best way to get something into the ASF infrastructure is to vote with our feet and host it somewhere else first. Then, we can point and say Yet it moves!. For the dev list, there's already something setup at opensymphony: http://forums.opensymphony.com/forum.jspa?forumID=34 I think it would be trivial to setup the user list. Then it's just a matter of moving it over to an apache server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Nightly build script needs updating
The nightly scripts seem to be out of date for struts2. The 2.0.x build is currently building trunk and there is no nightly build for 2.0.x: http://svn.apache.org/repos/asf/struts/maven/trunk/scripts/nightly/nightly-2.0.x.sh I'd be happy to update the scripts if someone could enlighten me on the proper procedure. (Modifying the svn isn't the correct procedure according to the README.txt) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.4 2.1 sharing localization code
Actually I think the xwork2 i18n code is pretty good. I would probably look at that code as the basis--or at least make sure that we don't loose any functionality. Although there's some areas that need work--(hint validators), I thought webwork had pretty good i18n support. Far more flexible and straightforward than Strut1 from what I remember. :) Tom Don Brown wrote: Ah, that makes much more sense :) As for collaborating, I'm all for it, however in the case of Struts 2, it would happen probably at the XWork 2 layer. Since this code would be useful to non-Struts projects, perhaps it would be better to move it to Jakarta Commons, say commons-i18n? I believe that project is still in the sandbox and looking for developers so it may be ripe for new development. I thought there was another commons project that Struts 1 was always going to move to, commons-resources or something? Don On 2/21/07, Paul Benedict [EMAIL PROTECTED] wrote: Ah. Good email. I didn't realize that my sentence could be read as such, but now I can see that interpretation. Here's what I meant: I'd like to propose creating a sub-project (like the annotations) for localization. Not creating annotations for localization, but a subproject like you did for annotations. Is that clearer? Man, sounds confusing still. Paul Don Brown wrote: For the unaware like me, could you go more into the problem that exists in Struts 1 and 2, and the solution that involves these annotations? Just from this message, I'm a bit confused why we would use annotations for something like this. Don On 2/21/07, *Paul Benedict* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'd like to propose creating a sub-project like the annotations for localization. I am not at the point of committing my 1.4 changes, but real important classes are independent of s1 and could be used in s2. This is all theory. I haven't spent enough time looking at s2 to figure out in-depth its localization strategies are. But I think it's a worthwhile effort to look into. Is anyone interested? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I need struts2 documation wiki karma
Hi, my name is Earl...I need karma. I have some updates to the struts2 documentation--can someone grant me some karma to do so? Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] New Struts Committers: Musachy Barroso, Philip Luppens, Tom Schneider, Henri Yandell
I went to an engineering school, we didn't have a school song. :-) Musachy Barroso wrote: bring it on Tom :) musachy On 2/18/07, Paul Benedict [EMAIL PROTECTED] wrote: All new committers must sing their alma mater. Who wants to be first? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Users guide
Just to add my 2 cents... I agree with Ted that the wiki is a bad place to do long cohesive documents. Would a PDF format be a better choice? With webwork, what most users had was Jason's/Pat's 'Webwork in Action' in combination with the online documentation. This was a really good combination IMO. I'd love to see something similar for Struts2, but without having to buy a book. (i.e. as part of the core documentation, maybe not quite as extensive as the book was, only the first 5-6 chapters were really relevant in getting started) The other thing I'd like to see is some sort of Developer's/Plugin Developer's guide. This is the one area where webwork really didn't have anything. (and I mean nothing) I had to dig through the code to figure out most of this stuff. (Not a terrible thing, but something more would have been helpful) This is something that I'll be working on as time permits. Tom On 2/12/07, Philip Luppens [EMAIL PROTECTED] wrote: On 2/12/07, Musachy Barroso [EMAIL PROTECTED] wrote: It's also not clear whether the intention is to create new content or link to the old. I think the idea is just to organize the info in a way that a user new to struts 2 can understand. From my personal experience, when I started with S2, I couldn't make sense out of the wiki, I had to read WW in Action, and after that, the wiki was just great! Well, the first point is: what belongs in a user guide ? Is it just an 'easier' Developers Guide ? Does it contain examples ? Or rather tutorials ? Should it contain links to the reference pages ? Isn't the Developers Guide in fact our Reference Guide ? Should we split it up ? To be honest, I find it very hard to imagine what a newbie thinks or expects from a user guide. Does the User Guide take a new user to the point where he or she can create basic Actions, views (JSP, Freemarker, Velocity, ..), and set up a basic configuration (struts.xml) ? In that case, shouldn't a big tutorial be easier ? The Developers Guide is supposed to give insights into the inner workings of Struts 2, about extension points (Interceptors, Plugins, PreResultListeners, ..), but right now, it looks more like the reference guide. So, let's decide what guides we want (installation guide, user guide, developer guide, reference, tutorial, ..), and what the goal/outline for each guide is. I admit: the current guide and outline is not for newbies. Part of Struts success was its excellent Users Guide, something I really want to see in Struts 2 - because it would greatly impact the success of Struts 2 amongst new programmers. But, like we point out below: there are books going to be written (and being written), so we might leave the authors of those books something to tell ;-) All kidding aside: I really like the Hibernate documentation: a simple getting started example, and a user guide. Plus there's the Hibernate in action book that lists best practices and designs. Maybe that's a good example ? My suggestion would be to look at the existing content as an encyclopedia (or wikipedia), augmented by tutorials and FAQs. Personally, I'd suggest putting the effort into expanding the bootstrap tutorial, merging it with the CRUD tutorial, making sure all the FAQs on the list actually end up in the FAQ, and making the rest of the wiki the best encylopedia that it can be. There are also still many places where we don't use snippets hard enough, and so the content is out of date. Ideally, the content should indeed be put on one place. Otoh, esp. for the user guide, I do not expect it to change that much (or much at all). We aren't suddently going to drop Results, we aren't tossing away actions, ... etc. More advanced things belong in the Developers Guide or Reference Guide. Maybe it's a good idea to take a look at the Architecture Image [1], and decide what should be explained in what part ? eg. We can briefly explain what interceptors are, and what they do, but refer to the Reference Guide (which then contains the snippets) for specific information, and the Developers Guide for writing your own Interceptor. Good point. We could definitely consider that, because I think it would be good enough, to get the bootstrap edited and beefed up. The other problem would be duplicated documentation which would be hard to maintain. Besides, there's got to be a couple of S2 books on the make. Phil? Yes; afaik, Ian is working on both a book for the 3th quarter of the year, and a minibook (about 60 pages) is supposed to hit InfoQ nex month. But, we all have to scratch our own itches, and if a book-style user guide is your itch, more power to you :) Well, I don't like writing at all, but I worry about the newbies :) . Same here, a good user guide was something that was always postponed at WW, and something that can definitely make the difference between a good and a great framework (in terms of success). I don't mind writing at all, but like I pointed out before: I'm
Re: [s2] Pluggable URL building proposal
Ok, I've decided to prototype the urlbuilder in tabletags. (Getting s2 all converted over would've taken too much time) So I've checked in the basic servlet/portlet url builders here: http://tabletags.googlecode.com/svn/trunk/tags/src/main/java/com/googlecode/tabletags/urlbuilder/ I'd appreciate any feedback. Once we've worked out all the kinks, we can look at integrating into the full struts2 codebase. Tom Tom Schneider wrote: I am very ashamed to report that I didn't get very far. (too much snow to shovel last weekend) I was able to analyze what each type of url would need, i.e. portlet vs. normal url. I think our best best is to have a data bean that encapsulates non-stardard stuff for each url type along with a seperate bean that captures the standard stuff. Generic stuff: action namespace method scheme anchor includeParams Portlet specific data: portletMode portletUrlType This is just a start, but it gives you an idea of what I'm thinking. I also noticed how asymmetric the PortalURLHelper and the URLHelper are. Most of the refactoring would probably happen in these classes, so the final API would probably be something of a mix between the 2. Just some random thoughts for you to chew on. I'll post more if I find some time to look into this some more. I'd like to come up with a proposed API for everyone (mostly me and you Don) to review. Once we agree on that, the implementation should be pretty straightforward. Tom Don Brown wrote: I _love_ this idea as it is been something I've wanted to tackle myself for a while now. I'm very interested in your progress, so let us know what you find. Don Tom Schneider wrote: Based on the portlet plugin proposal and some work I've been doing with the table tags, I thought I would propose a refactor of the URL building for struts2. Right now, struts2 has great support for taking on incoming request and mapping it to the core elements of the framework (i.e. namespace, action, method, etc.) in the ActionMapper interface. It seems like we should be doing the same for building URL's. This would allow the url tag to be completely dumb about how url's are built up. Right now, the url tag has specific logic to determine if the request is a portlet request or not and uses PortletUrlHelper or UrlHelper respectively. If the url building was pluggable, we would have a default url builder that would be configured to build either portlet url's or regular url's. This would allow us to easily extract the portlet support out into a separate plugin. It would also allow 3rd part tags (like table tags) transparent, built-in portlet support with almost no effort. We could also support other types of url's like Restful urls. (Right now, I'm not sure how the url tag supports restful url's) I'll take a preliminary look at this later today, but I was curious if anyone thoughts, pro or con regarding this. Tom - 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 2.0.5 Quality
Umm, it looks like the spring plugin jar isn't included. Someone on #struts mentioned this and I confirmed it by downloading struts-2.0.5-all.zip from the website and it's not in the lib directory. (All the other plugins are there) Am I crazy or is it really missing? Tom Ted Husted wrote: The Struts 2.0.5 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-205.html Distribution: * http://people.apache.org/builds/struts/2.0.5/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/ If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a *binding* +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. The vote will remain open for at least 72 hours, longer upon request. -Ted. - 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 Annotations 1.0.1 Quality
Ted Husted wrote: [ ] Leave at test build [ ] Alpha [ ] Beta [ X ] General Availability (GA) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Branch 2.0.x and label head 2.1.0(was Re: Struts Release Process (again))
I would argue also that a lot of fixes going into struts 2.0.x haven't made it back into webwork. Several issues I resolved in Webwork this weekend were already fixed in Struts 2.0.x. Tom On 2/7/07, Don Brown [EMAIL PROTECTED] wrote: I'm fine with branching now, but it means that we need to be extra careful to port fixes to all applicable branches: WebWork 2.2.x (where applicable), Struts 2.0.x, and Struts 2.1.x. A lot of fixes have been going into WebWork 2.2.x that haven't been making it to Struts 2.0.x, so we need to be doubly careful with a new codebase in the mix. Don On 2/7/07, Musachy Barroso [EMAIL PROTECTED] wrote: There are a few ajax issues with their patches already on jira. They are all simple fixes and could be addressed on 2.0.6 instead of 2.1. regards musachy Ted Husted wrote: OK, I created a 2.0.x branch and I'm about to update the POMs. This stuff is trivial to do, so if anyone is deadset against a branch now, we can redo it easy enough later. Though, I'd be happy to ensure that we backport relevant 2.1.x changes to 2.0.x, until we hit a 2.1.x GA. I've silently bulk edited some 2.0.6 and 2.1.x issues into a lazy list for 2.1.0. I don't have my heart set on any of these, so if anyone wants to do some early or later, that's fine with me. I just wanted to have some type of starting point. * 2.0.6 TODO ** https://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=hiderequestId=10763 * 2.1.0 TODO ** https://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=hiderequestId=10766 As to 2.1.0 almost all of these deal with three key issues * Dojo/Ajax plugin * Portlet plugin * Performance tweaks Meanwhile, I would like to see an early 2.1.0 release, and a steady march to GA there too. Now that we have a stable XWork 2 release series, we should be rolling Struts GA releases too. From another thread, it sounds like XWork is about to roll another release. That being the case, I'd like to suggest 15 February for a Struts 2.0.6 build. We've had a few changes already, and a XWork release is cause enough unto itself. -Ted. - 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: Branch 2.0.x and label head 2.1.0(was Re: Struts Release Process (again))
On 2/7/07, Ted Husted [EMAIL PROTECTED] wrote: Phillip filed a number of tickets regarding WebWork fixes, so what we haven't applied may just be pending. I know there are a couple of WW patches slated for 2.0.6 (thanks Tom!). And as soon as my apache account is created, I'll be committing them to struts2. :-)
Re: [s2] Pluggable URL building proposal
Yes, I've already implemented that piece of it. The UrlBuilder implementation can automatically be injected via the @Inject annotation, just like the actionmapper. Right now my ServletUrlBuilder and PortletUrlBuilder use the static UrlHelper and PortletUrlHelper under the hood, but eventually we could move that logic into the builders themselves. Tom Don Brown wrote: Cool, but please, please, please find some way to avoid a static helper class :) BTW, it would be cool if the urlbuilder would be able to automatically discover any other objects that want a shot at the URL building process. See how the TagLibrary or TemplateEngine classes are discovered for examples. Don Tom Schneider wrote: Ok, I had a little time tonight to put together a preliminary design for the URLBuilder. Here's what I have so far for the interface: URLBuilder +buildURL(CustomAttributes, ActionMapping) // this method is for when an action, namespace, method, etc. is supplied +buildURL(CustomAttributes, String) // this method is for when the url value itself is provided My expectation is each builder would use the default ActionMapper under the hood. From an infrastructure standpoint, it would be configured and injected the same as the ActionMapper is. The custom attributes that I've come up with so far are: CustomPortletAttributes: RenderRequest, RenderResponse windowState portletUrlType portletMode CustomServletAttributes: HttpServletRequest, HttpServletResponse encodeParams includeContext scheme I'm not exactly sure how we'll build these up. Either the client code of the builder will have to know how to build each type or we'll need a static helper class that does most of the work. I'll probably be taking a stab at implementation this weekend. Tom Patrick Lightbody wrote: Tom, How is this coming along? I imagine that some of this work would also relate to the ActionMapper interface, since it does have some responsibilities for rendering out URLs. Keep us posted. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=59916messageID=119811#119811 - 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: [s2] Pluggable URL building proposal
Ok, I had a little time tonight to put together a preliminary design for the URLBuilder. Here's what I have so far for the interface: URLBuilder +buildURL(CustomAttributes, ActionMapping) // this method is for when an action, namespace, method, etc. is supplied +buildURL(CustomAttributes, String) // this method is for when the url value itself is provided My expectation is each builder would use the default ActionMapper under the hood. From an infrastructure standpoint, it would be configured and injected the same as the ActionMapper is. The custom attributes that I've come up with so far are: CustomPortletAttributes: RenderRequest, RenderResponse windowState portletUrlType portletMode CustomServletAttributes: HttpServletRequest, HttpServletResponse encodeParams includeContext scheme I'm not exactly sure how we'll build these up. Either the client code of the builder will have to know how to build each type or we'll need a static helper class that does most of the work. I'll probably be taking a stab at implementation this weekend. Tom Patrick Lightbody wrote: Tom, How is this coming along? I imagine that some of this work would also relate to the ActionMapper interface, since it does have some responsibilities for rendering out URLs. Keep us posted. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=59916messageID=119811#119811 - 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: [s2] Pluggable URL building proposal
Hey Patrick, Haven't had time to look at this any further. Yes, I definitely would build on top of the ActionMapper stuff--that's already abstracted out so nicely I didn't even mention it. :) I might have some time this weekend to dig into this further. (I was too busy releasing the first version of table tags this weekend to look at this) Tom On 1/31/07, Patrick Lightbody [EMAIL PROTECTED] wrote: Tom, How is this coming along? I imagine that some of this work would also relate to the ActionMapper interface, since it does have some responsibilities for rendering out URLs. Keep us posted. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=59916messageID=119811#119811 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.4 Quality
I agree with Phil--we need an updated version of OGNL. Last week I was able to reproduce the OGNL race condition under JBoss on windows with JDK 1.5. If it was strictly limited to Websphere 5.1 under Linux/Windows, I wouldn't be pushing so hard. However, it looks like it's more widespread than that. (Phil's patched version of OGNL resolved the issue) Tom Philip Luppens wrote: Can a problem in a dependency hold back a GA ? I'm talking about WW-1615 [1] (OGNL race condition). The bugfix is trivial, but we need a new release for that. Patrick should have set up Jesse by now (its new maintainer), so we can expect an official bugfix release rather soon. I guess I have some troubles with pushing a GA if such an important dependency is having a known bug. We're already aware of S2 being slower than S1, let's not kill whatever performance we have left with a race condition, even if it's caused by a dependency rather than the actual framework. Of course, if this has nothing to do with it, then just disregard this message. Cheers, Phil [1] https://issues.apache.org/struts/browse/WW-1615 On 1/30/07, Don Brown [EMAIL PROTECTED] wrote: +1 for GA. I've been pretty happy with this build and while there are certainly things to improve (aren't there always?), I don't see anything major that should prevent production applications from being built upon it. Even if the final result is beta, will this release finally be put into the public maven repository? Don Ted Husted wrote: Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven fixes, I thought we might as well start the vote. If after three days anyone needs more time, or we don't have a quorum, then we can just leave the vote open for as long as it takes. Release notes: * http://struts.apache.org/2.x/docs/release-notes-204.html * http://struts.apache.org/2.x/docs/release-notes-203.html Distribution: * http://people.apache.org/builds/struts/2.0.4/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote as to its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a binding +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. Unless we decide otherwise, a beta vote implies that we will announce the build to the user list, to encourage wider testing. -Ted. - 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: Fast ValueStack
Oops, the numbers aren't quite as bad as I thought. The original numbers included the cost of compiling the OGNL expression. If you exclude the OGNL compilation the numbers are: Using OGNL expression: 15 ms Explicitly calling getText: 0 ms I knew that compiling the OGNL expression took a long time, but I didn't realize it was that long. I still think there is a benefit to updating the way the UIBean does key lookup. At a minimum it will make the Text and other UIBeans more consistent and there is a slight performance benefit. I'm glad you resolved your issue. I knew about the other property, but I normally don't set that one explicitly--so I didn't think to mention it. :) That definitely explains the huge numbers. Tom David H. DeWolf wrote: Nice, that seems in line with what I'm seeing as well now. I still think this is worth improving, as those 5ms can add up on larger forms. Tom Schneider wrote: Well, I guess I was feeling more ambitious than I thought. I wrote a simple junit test (below) that tests the 2 techniques for retrieving I18N text. My numbers for 100 iterations were: Using OGNL expression: 476 ms Explicitly calling getText: 0 ms Yikes!!! There is quite a difference between the two. The OGNL version takes 5 ms/request compared to almost nothing for the explicit call. It looks like it would be very beneficial to reimplement the UIBean key lookup code based on the Text component-style of text lookup. Agreed. I've created: https://issues.apache.org/struts/browse/WW-1681 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fast ValueStack
David,
See https://issues.apache.org/struts/browse/WW-1661
and
http://wiki.opensymphony.com/display/WW/Performance+Tuning (particularly the
freemarker entries)
By just adding the freemarker.properties and copying all the templates to
the webapp directory we were able to resolve all of our freemarker
performance issues. (or at least get the page render times down to a point
where they weren't an issue for us)
We were using the simple theme, so most of our text output uses the ww:text
tag--we did not have to use %{getText(...)} at all in our JSP's. I'm not
sure if it's doing the same thing under the hood, but you might want to
experiment with that. I would say, make the freemarker changes, then see
what kind of times you are getting. We were able to get all our pages to
render in about 50-150 ms. (about 100-200 ms total page load time)
Originally we were seeing about 150-300+ ms render time for the pages.
(without the caching, the numbers were much more sporadic)
Tom
On 1/26/07, David H. DeWolf [EMAIL PROTECTED] wrote:
Well, I hope I'm wrong, and have only done some initial tests so far,
but it seems to me that there are two major issues causing our
slugishness. The first seems to be OGNL and the second seems to be
freemarker templates.
By simply replacing the default value stack with the version Bob posted,
I realized a gain of about 100-200ms per request on some fairly simple
pages. The real kicker is when I remove the method invocations
(%{getText('')}) - this results in a 1100-1200ms/request gain (an
average of about 100ms per method invocation) and drops my total request
time to well under a second.
That's why I'm thinking about looking at method processing.
What did you find to be your culprit? Anything ww/struts related?
David
Tom Schneider wrote:
Hey David,
Are you finding the existing ValueStack to be impacting performance? I
recently wrapped up a week of tweaking our webwork app and I did some
testing of the OGNL expressions and that was definitely not where our
performance issues were. If OGNL is an issue for you, I'd be curious to
know how you are using OGNL and maybe try and figure why it's not
performing
well for you. (Based on a conversation with Phil, I confirmed that OGNL
expressions where being cached at a JVM level in xwork--so most of the
expressions should be running as compiled expressions) For example, if
you
could come up with some example code that you can share with us that
performs poorly with the existing OGNL implementation.
As far as other options, Jesse (from Tapestry) has created some patches
for
OGNL that should definitely improve the performance. Checkout
http://forums.opensymphony.com/thread.jspa?threadID=59785tstart=-1 for
details. We're working on getting the OGNL project up and running again
so
at some point these should make it into a future release.
Tom
On 1/26/07, David H. DeWolf [EMAIL PROTECTED] wrote:
I'm going to be looking into optimizing the performance of the
ValueStack and because of the recent conversations regarding OGNL and
other options, I anticipate that others may have some ideas.
I've ripped off the custom stack that Bob posted to the list a couple
of
a weeks ago, and have realized significant gains using it, however,
because it only optimizes simple properties, I still think there's a
lot
of room for improvement. Specifically, method invocations are very
expensive and happen to be used often in processing the components -
especially if you use i18n features (getText()), etc...
I think I'm going to start by looking at MVEL, what other ideas do
people have?
David
-
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: Fast ValueStack
David H. DeWolf wrote:
Tom Schneider wrote:
David,
See https://issues.apache.org/struts/browse/WW-1661
and
http://wiki.opensymphony.com/display/WW/Performance+Tuning
(particularly the
freemarker entries)
By just adding the freemarker.properties and copying all the
templates to
the webapp directory we were able to resolve all of our freemarker
performance issues. (or at least get the page render times down to a
point
where they weren't an issue for us)
Unfortunately, I've tried both the props and copying the templates and
am still having the issues. I assume the big prop you're talking
about is template_update_delay. Any others you found useful for
performance?
The big thing for us was moving the freemarker templates to the war,
rather than letting them get loaded via the classpath. It seems that if
you let the templates get loaded via the classpath rather than the
filesystem, then freemarker has no last modified time to check to see if
it needs to reload it, so it reloads and reparses the template every
time. If the template is available via the filesystem, it has a last
modified time to check and then the caching can work as expected. The
template_update_delay is just a setting that controls how long
freemarker will go before it will explicitly reload the template
regardless of the last modified time. Setting this property helped, but
is was only an incremental increase to performance. You must do both to
realize the greatest benefits. (In fact the template_update_delay is
useless if the templates are being loaded from the classpath) Those are
the only 2 tweaks I made to the freemarker stuff to get it to perform well.
We were using the simple theme, so most of our text output uses the
ww:text
tag--we did not have to use %{getText(...)} at all in our JSP's. I'm
not
sure if it's doing the same thing under the hood, but you might want to
experiment with that. I would say, make the freemarker changes, then
see
what kind of times you are getting. We were able to get all our
pages to
render in about 50-150 ms. (about 100-200 ms total page load time)
Originally we were seeing about 150-300+ ms render time for the pages.
(without the caching, the numbers were much more sporadic)
Thanks for the tip. I'm using the xhtml theme and will do some
benchmarking between the two. I've looked further into the method
invocation/getText issue and I think it's real, though I'm wondering
why it hasn't been reported before considering how significant it is.
The 50-150/100-200 ms times are exactly what I'm looking for. I'm
currently seeing 1200-2400 when I have 15-20 form fields using
getText. As soon as I take out the method invocations and use the
optomized OGNL stack, I drop down to 300.
Yikes, that doesn't seem right at all. :) Unless you're rendering
a lot of UI tags, even the 300 seems high. If OGNL was truly the issue,
it should be relatively easy to generate a junit test that simulates
what is going on in OGNL when you make those getText calls. Once you
have that I don't think it would be too difficult to either use a
profiler or instrutment the code to figure out exactly where in OGNL all
that time is being spent. There might be a simple fix for this issue.
(Or at least we could try some of the performance patched code)
The other thing to check is to make sure devmode is off. With devmode
on, the resource bundles will be reloaded quite offend vs. not being
reload at all with devmode off. That could definitely be a culprit if
the getText calls are taking so long.
That's all I can think of at the moment. Let us know if you make any
progress--I've been in OGNL enough over the last month to be pretty
familiar with it. (There was a race condition that I discovered that
was a pain to track down--we finally reproduced this under JBoss so I
hope we get an official OGNL release with this patched soon)
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fast ValueStack
From UIBean.java:
if (this.key != null) {
if(this.name == null) {
this.name = key;
}
if(this.label == null) {
this.label = %{getText('+ key +')};
}
}
Looks like it's doing exactly the same thing. :(
Even more interesting, look what's going on in the Text.java UI component:
for (Iterator iterator = getStack().getRoot().iterator();
iterator.hasNext();) {
Object o = iterator.next();
if (o instanceof TextProvider) {
TextProvider tp = (TextProvider) o;
msg = tp.getText(actualName, defaultMessage, values, stack);
break;
}
}
No wonder I didn't see any performance issues here and David did--this
definitely looks like it would be faster. :) We should probably adopt
this model of looking up text in the UIBean class when a key is provided
as it might speed things up. I'd love to see some before/after
numbers. This might be a tweak you want to apply locally and see if
there's a performance gain. (I'll post some if I find some time this
weekend)
Tom
Ted Husted wrote:
On 1/26/07, David H. DeWolf [EMAIL PROTECTED] wrote:
pages. The real kicker is when I remove the method invocations
(%{getText('')}) - this results in a 1100-1200ms/request gain (an
average of about 100ms per method invocation) and drops my total request
time to well under a second.
The tags now have a key attribute that can be used in place of the
getText OGNL expression.
I'd be curious to know if
s:textfield key=lastName /
runs faster than
s:textfield label=%getText('lastName') name=lastName /
If so, I wonder if there other places where we could eliminate common
OGNL statements by adding functionality to the tags.
-Ted.
-
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: Fast ValueStack
Well, I guess I was feeling more ambitious than I thought.
I wrote a simple junit test (below) that tests the 2 techniques for
retrieving I18N text. My numbers for 100 iterations were:
Using OGNL expression: 476 ms
Explicitly calling getText: 0 ms
Yikes!!! There is quite a difference between the two. The OGNL version
takes 5 ms/request compared to almost nothing for the explicit call. It
looks like it would be very beneficial to reimplement the UIBean key
lookup code based on the Text component-style of text lookup. I think
the key attribute is a much cleaner way of specifying label text anyway
so it's good to give users an incentive to use it. :)
Tom
/ start source code **/
package example;
import java.util.Iterator;
import junit.framework.TestCase;
import com.opensymphony.xwork2.ActionSupport;
import com.opensymphony.xwork2.TextProvider;
import com.opensymphony.xwork2.util.OgnlValueStack;
public class TestOgnl extends TestCase {
public void testOgnl() {
TestAction action = new TestAction();
OgnlValueStack stack = new OgnlValueStack();
stack.push(action);
String value = null;
long start = System.currentTimeMillis();
for(int i = 0; i 100; i++) {
value = stack.findString(getText('key'));
}
long end = System.currentTimeMillis();
assertEquals(value, value);
System.out.println((end - start));
start = System.currentTimeMillis();
for(int i = 0; i 100; i++) {
value = findString(stack, key);
}
end = System.currentTimeMillis();
System.out.println((end - start));
assertEquals(value, value);
}
protected String findString(OgnlValueStack stack, String key) {
for(Iterator iterator = stack.getRoot().iterator(); iterator
.hasNext();) {
Object o = iterator.next();
if(o instanceof TextProvider) {
TextProvider tp = (TextProvider) o;
return tp.getText(key);
}
}
return null;
}
}
class TestAction extends ActionSupport {
@Override
public String getText(String arg0) {
if(key.equals(arg0)) {
return value;
}
return null;
}
}
/ end source code **/
Ted Husted wrote:
The tags now have a key attribute that can be used in place of the
getText OGNL expression.
I'd be curious to know if
s:textfield key=lastName /
runs faster than
s:textfield label=%getText('lastName') name=lastName /
If so, I wonder if there other places where we could eliminate common
OGNL statements by adding functionality to the tags.
-Ted.
-
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: [s2] Pluggable URL building proposal
I am very ashamed to report that I didn't get very far. (too much snow to shovel last weekend) I was able to analyze what each type of url would need, i.e. portlet vs. normal url. I think our best best is to have a data bean that encapsulates non-stardard stuff for each url type along with a seperate bean that captures the standard stuff. Generic stuff: action namespace method scheme anchor includeParams Portlet specific data: portletMode portletUrlType This is just a start, but it gives you an idea of what I'm thinking. I also noticed how asymmetric the PortalURLHelper and the URLHelper are. Most of the refactoring would probably happen in these classes, so the final API would probably be something of a mix between the 2. Just some random thoughts for you to chew on. I'll post more if I find some time to look into this some more. I'd like to come up with a proposed API for everyone (mostly me and you Don) to review. Once we agree on that, the implementation should be pretty straightforward. Tom Don Brown wrote: I _love_ this idea as it is been something I've wanted to tackle myself for a while now. I'm very interested in your progress, so let us know what you find. Don Tom Schneider wrote: Based on the portlet plugin proposal and some work I've been doing with the table tags, I thought I would propose a refactor of the URL building for struts2. Right now, struts2 has great support for taking on incoming request and mapping it to the core elements of the framework (i.e. namespace, action, method, etc.) in the ActionMapper interface. It seems like we should be doing the same for building URL's. This would allow the url tag to be completely dumb about how url's are built up. Right now, the url tag has specific logic to determine if the request is a portlet request or not and uses PortletUrlHelper or UrlHelper respectively. If the url building was pluggable, we would have a default url builder that would be configured to build either portlet url's or regular url's. This would allow us to easily extract the portlet support out into a separate plugin. It would also allow 3rd part tags (like table tags) transparent, built-in portlet support with almost no effort. We could also support other types of url's like Restful urls. (Right now, I'm not sure how the url tag supports restful url's) I'll take a preliminary look at this later today, but I was curious if anyone thoughts, pro or con regarding this. Tom - 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: Feature to manage conversational state
Actually http://cwiki.apache.org/S2PLUGINS/spring-webflow-plugin.html is the latest and greatest with regard to SWF integration. Also, if you're looking for session type managment, checkout the scope plugin: http://cwiki.apache.org/S2PLUGINS/scope-plugin.html. (This is in the sandbox, I haven't looked at the code yet so I'm not sure how far along it is) Tom On 1/22/07, Mark Menard [EMAIL PROTECTED] wrote: On 1/22/07 10:36 AM, Chris Wash [EMAIL PROTECTED] wrote: Hi, I was wondering if any features are on the horizon to help a user manage conversational state, a la Seam's conversational scope, or Beehive's stateful pageflow, or a Page session in NetDynamics. I found an implementation of one out there with a quick Google, (http://www.vitarara.org/cms/node/84) but I feel this is something that has been on the back-burner with traditional MVC frameworks for too long. It's too easy to get this wrong and is something that can be much easier to manage with some simple help at the framework level. Also, I find the natural caching mechanism and cleanliness of state that this approach provides are elegant solutions to tough state-management problems that are frequently the root of evil in web applications. Hi Chris, I agree that good conversation management is important. I am using the interceptor that you found above. I have submitted it as a patch to S2, but my thought lately have been just to publish it as a plugin for Struts 2. With the Struts 2 plugin system it is unnecessary to have everything be in the mainline distribution. Another thing you might want to look at for conversation management is Spring Web Flow. There is an open JIRA ticket for this. (https://issues.apache.org/struts/browse/WW-1525) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Pluggable URL building proposal
Based on the portlet plugin proposal and some work I've been doing with the table tags, I thought I would propose a refactor of the URL building for struts2. Right now, struts2 has great support for taking on incoming request and mapping it to the core elements of the framework (i.e. namespace, action, method, etc.) in the ActionMapper interface. It seems like we should be doing the same for building URL's. This would allow the url tag to be completely dumb about how url's are built up. Right now, the url tag has specific logic to determine if the request is a portlet request or not and uses PortletUrlHelper or UrlHelper respectively. If the url building was pluggable, we would have a default url builder that would be configured to build either portlet url's or regular url's. This would allow us to easily extract the portlet support out into a separate plugin. It would also allow 3rd part tags (like table tags) transparent, built-in portlet support with almost no effort. We could also support other types of url's like Restful urls. (Right now, I'm not sure how the url tag supports restful url's) I'll take a preliminary look at this later today, but I was curious if anyone thoughts, pro or con regarding this. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Freemarker Confusion
Joe,
${error} being null would imply that you have an item in the action
errors Collection that is null. (e.g. {Error1, Error2, null,
Error4}) It seems like that would be an issue that occurs as the
errors are being populated. (I can't think of a valid use case where
you would have a null error message.)
In spite of that, you could modify the template to handle this more
gracefully using the default function:
lispan class=errorMessage${error?default()}/span/li
In general, I think there is room for improvement in the UI tags error
handling/reporting. I've already submitted patches for null handling in
the select tags--this is just another instance were nulls slip through
the cracks.
Tom
Joe Germuska wrote:
I've ran into an odd problem of my own and while I'm troubleshooting
it, I'm
hitting some problems or confusion with Freemarker as it is used for
the S2
UI tags. Can anyone help me understand this better?
I was getting a big yellow and red Freemarker trace in my rendered page
because an ${error} expression yielded null when using s:actionerror.
I'm assuming this is the result of an uncaught NullPointerException being
caught by Struts2, as the message for NPEs is often itself null. I
actually
haven't yet figured out where this logic is, so question 1 is which
class
is actually catching my exception and routing to an 'error' page?
Then, it seems like our templates should be prepared for the
possibility of
a null message, especially if they are being invoked when an
unexpected NPE
is caught -- a not unlikely scenario.
So I found this page of Freemarker documentation explaining how to
deal with
empty values:
http://freemarker.sourceforge.net/docs/dgui_template_exp.html#dgui_template_exp_missing
except that it doesn't seem to apply to the version of Freemarker (2.3.4)
that we're using. They're only up to 2.3.8 and they make a big fuss
about
nulls -- can this be new just in those minor releases? Or is there
something I should understand about why those rules don't apply to
Freemarker as it is used in S2? I get an error when I try to use the
syntax
for handling missing values
${error!null}
and the syntax for testing for nulls
${error??}
What am I missing?
After I get all that cleared up, the last question is whether or not we
ought to make a change to template/simple/actionerror.ftl so that it
handles
this gracefully. I guess I already think the answer is yes, and I'd
do it
myself, except apparently I haven't found Freemarker syntax documentation
which is right for our environment.
Thanks
Joe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Freemarker Confusion
No, not overkill at all. I like that better than my empty string. (The
select tag should probably be updated to output something like that for
null keys and null values)
Tom
Joe Germuska wrote:
Tom:
Thanks for your help... I see now that the syntax I was trying to use
was
added in Freemarker 2.3.7
http://freemarker.sourceforge.net/docs/versions_2_3_7.html
Now... is an empty string the right result? maybe ${error?default(!--
null error --)} ?
is that overkill?
Joe
On 1/20/07, Tom Schneider [EMAIL PROTECTED] wrote:
Joe,
${error} being null would imply that you have an item in the action
errors Collection that is null. (e.g. {Error1, Error2, null,
Error4}) It seems like that would be an issue that occurs as the
errors are being populated. (I can't think of a valid use case where
you would have a null error message.)
In spite of that, you could modify the template to handle this more
gracefully using the default function:
lispan class=errorMessage${error?default()}/span/li
In general, I think there is room for improvement in the UI tags error
handling/reporting. I've already submitted patches for null handling in
the select tags--this is just another instance were nulls slip through
the cracks.
Tom
Joe Germuska wrote:
I've ran into an odd problem of my own and while I'm troubleshooting
it, I'm
hitting some problems or confusion with Freemarker as it is used for
the S2
UI tags. Can anyone help me understand this better?
I was getting a big yellow and red Freemarker trace in my rendered
page
because an ${error} expression yielded null when using
s:actionerror.
I'm assuming this is the result of an uncaught NullPointerException
being
caught by Struts2, as the message for NPEs is often itself null. I
actually
haven't yet figured out where this logic is, so question 1 is which
class
is actually catching my exception and routing to an 'error' page?
Then, it seems like our templates should be prepared for the
possibility of
a null message, especially if they are being invoked when an
unexpected NPE
is caught -- a not unlikely scenario.
So I found this page of Freemarker documentation explaining how to
deal with
empty values:
http://freemarker.sourceforge.net/docs/dgui_template_exp.html#dgui_template_exp_missing
except that it doesn't seem to apply to the version of Freemarker
(2.3.4
)
that we're using. They're only up to 2.3.8 and they make a big fuss
about
nulls -- can this be new just in those minor releases? Or is there
something I should understand about why those rules don't apply to
Freemarker as it is used in S2? I get an error when I try to use the
syntax
for handling missing values
${error!null}
and the syntax for testing for nulls
${error??}
What am I missing?
After I get all that cleared up, the last question is whether or
not we
ought to make a change to template/simple/actionerror.ftl so that it
handles
this gracefully. I guess I already think the answer is yes, and I'd
do it
myself, except apparently I haven't found Freemarker syntax
documentation
which is right for our environment.
Thanks
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: Struts 2.0 Performance
Obviously you picked up on my probing questions on the chat. :) Yes--we use JSP's with FTL templates for the tags. It only recently occurred to me that the caching would need to be different for the FTL tag templates vs. FTL results. I like this proposal--it would keep the user from having to worry about any of this. Thats a good thing. (And arguable this type of caching should have been in place already, IMO) The other thing I wanted to mention is that I think a missing template cache would also be a good idea. (Phil and I discussed this) The idea is that right now there is a penalty for looking for a template, only to find that it doesn't exist and falling back to the parent theme template. Instead, if we find that a template is missing, we'd put that template name into a cache of all the missing template. Next time we look for that template, we'd check the missing template cache and find it in there and avoid the cost of looking for a template that doesn't exist. These 2 things would completely eliminate the 3+ days I spent 'optimizing' our WW app--so I think it would be very worthwhile investment. (I'll gladly pitch in once we've wrapped up our performance testing) Tom Philip Luppens wrote: I'd like to pick in on this one :-) Basically, there are two sides: we have the 'internal' Freemarker rendering for UI components, and we have the Freemarker result, which both share the same caching/template loading/.. . Now, as Tom said, the defaults are not so good (for the internal UI rendering). Not only does Freemarker have a default delay of just 5 seconds, but it also doesn't use its strong reference cache. [2] We can choose to split up the configuration for internal (UI components) and external (results) rendering, where we have a infinite caching for the internal use, and freemarker.properties - adaptable settings for external use, with better default settings when not in development mode. In my opinion, users should not have to worry about the internal rendering when just using the framework, unless they set devMode on (in which case constant reloading is allowed, and even required), so we should set the default settings accordingly. Thoughts ? Phil [1] https://issues.apache.org/struts/browse/WW-1654 [2] http://fmpp.sourceforge.net/freemarker/pgui_config_templateloading.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Performance
Well, I went ahead and implemented this tonight: http://issues.apache.org/struts/browse/WW-1661 http://jira.opensymphony.com/browse/WW-1417 It turns out that FreemarkerTemplateEngine.java is only used by the UI tags. The freemarker result hooks into freemarker via the FreemarkerManager. I thought about implementing the redirect cache for the UI tags, but the missing template cache was so simple that trying to implement the redirect cache would have complicated the code. (I don't think there's much of a performance difference one way or the other) I will be testing this code more fully on Monday. Even though we only wanted to implement this caching on the UI tags side of things, it may be beneficial to implement a similar cache for the freemarker results. Especially if the freemarker templates are being loaded from the classpath--freemarker will reread and parse the templates for every request! (assuming it works the same as the UI tags) Tom Philip Luppens wrote: On 1/19/07, Tom Schneider [EMAIL PROTECTED] wrote: Obviously you picked up on my probing questions on the chat. :) Yes--we use JSP's with FTL templates for the tags. It only recently occurred to me that the caching would need to be different for the FTL tag templates vs. FTL results. I like this proposal--it would keep the user from having to worry about any of this. Thats a good thing. (And arguable this type of caching should have been in place already, IMO) The other thing I wanted to mention is that I think a missing template cache would also be a good idea. (Phil and I discussed this) The idea is that right now there is a penalty for looking for a template, only to find that it doesn't exist and falling back to the parent theme template. Instead, if we find that a template is missing, we'd put that template name into a cache of all the missing template. Next time we look for that template, we'd check the missing template cache and find it in there and avoid the cost of looking for a template that doesn't exist. Discuss ? You said it, I nodded and punched myself in the head for not thinking about it :-) However, allow me to ramble on a bit more - feel free to stop me at any time: About the cache-none cache: is there an obvious reason (I'm sure there is) why we cannot use some sort of 'redirect cache' - where an invalid template request would result in the correct template getting returned (eg. /template/custom-theme-which-overrides-parent/textfield.ftl would return the template for /template/parent-theme/textfield.ftl or even /template/base-theme/textfield.ftl) - multiple keys for the same cache value. It would reduce 3 cache requests to 1, but it might result in more work, or unnecessarely complicate things. These 2 things would completely eliminate the 3+ days I spent 'optimizing' our WW app--so I think it would be very worthwhile investment. (I'll gladly pitch in once we've wrapped up our performance testing) Tom Cheers, Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Performance
One of the possibilities I was discussing with Phil yesterday was to implement freemarker caching on the WW side of things--just like we do with OGNL. In WW if we're not in devMode, then I think its safe to say that we can read the template once and never reread it. This would eliminate the need to move the ftl files out of the jars and also eliminate the penalty of not having an ftl files in your own custom theme. This could (should) also be moved in struts2 as well. That way, in non-devMode we would get the best performance we can, out -of-the-box. (It certainly would have saved me a lot of effort--that was where all of our performance woos came from) Tom Ted Husted wrote: Even though this is for WW, almost all of it is applicable to Struts 2. This is a key phrase. There are a lot of very successful WW deployments out there, with the same performance levels. We really need to setup our own benchmarks, so that we can run them with the templates deployed. I'd love to do this myself, but I'm totally time-deprived right now. Eventually we'll move this to S2 and update it, but so few people are using Struts 2 right now, I think this is adequate. That's going to change quite quickly. Even though we're still in beta, people are already posting jobs for S2. Even though the benchmarks might not tell the whole story, narrowing the cycles would make it easier for more people to adopt S2 (And hopefully some of those will lend us a hand. Even with the merge, we still don't have more active committers than we had a year ago.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0.3 status
Someone wasn't paying attention. :) If we need to do bug fixes on 2.0.3, we'll branch off the tag--otherwise we won't create the branch. Trunk became 2.1.x after the 2.0.3 tag. Tom Don Brown wrote: I didn't see a branch for 2.0.x Are we going to create it right before we commit big 2.1.x features? I like not having the branch for now, as I'm mostly working on bug fixes that should go into 2.0.4 Don Ted Husted wrote: I'm still not setup to sign the Maven artifiacts. I'm preparing for a trip, and I can't be sure that I'll have time to look at it before I leave. If someone else could take care of it, that would be great. Otherwise I'll figure it out when I get back on the 28th. The major problem is that my SSL key is still broken, so I have to put in my password forty times during the upload, which makes posting the Maven stuff non-trivial for me. -Ted. On 1/17/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 1/17/07, Ted Husted [EMAIL PROTECTED] wrote: Thanks, Wendy. Seems to have worked like a charm. Great! Then it looks like the only thing missing is signatures for all the jars and poms in the repository. Let me know if you need help scripting that... or, I posted about gpg plugin config and personally wouldn't be opposed to a bit of revisionist history on the tag. :) - 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: Struts 2.0 Performance
The performance of OGNL is not nearly as bad as we had originally thought. I've been doing some performance testing in Webwork (which S2 is based on) this week and most of the OGNL calls are not measurable. (1ms) The biggest issue I've had is making sure freemarker templates are getting cached properly. See http://wiki.opensymphony.com/display/WW/Performance+Tuning for details. (I'll be adding some explanations to what phil wrote later this week) Even though this is for WW, almost all of it is applicable to Struts 2. Eventually we'll move this to S2 and update it, but so few people are using Struts 2 right now, I think this is adequate. Tom Shekhar Yadav wrote: Is there a plan on when the performance issues with Struts 2.0 will be resolved? In some thread I saw that struts community is trying to either create a replaceable EL engine or improve OGNL performance. But nowhere, I see a committed timeline on when this will be done or whether this is being done. If there is some work being done on it, I would be more then willing to do beta testing and give early feedbacks. I am sounding so stressed out because we have an application timed to go live in April and with the current performance we can not go live. So please give me concrete information on what is the status on this so that we can plan accordingly. Regards, Shekhar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL functions in *struts* JSP tags
+1 for having a seperate key attribute that automatically does a getText() lookup for the label. This was one thing that is annoying in WW since we tried to I18Nize our whole app. The url thing didn't bother me as much, but I'm all for a shorthand notation if it makes sense. (Url/Button links tend to be rather verbose no matter what) On a slightly related note, the other thing we did was change the default button-style submit to render as: input type=button... rather than button ... Since button doesn't work the same on all browsers. (type=button was what we used before switching to WW) I'm not sure if this is something that should be changed in the core tags, but I thought I'd throw it out there. Tom Ted Husted wrote: On 1/12/07, Joe Germuska [EMAIL PROTECTED] wrote: Anyway, am I the only one who finds this syntax tedious? No, you are not. * https://issues.apache.org/struts/browse/WW-1517 Just looking for a patch ... I don't see a problem with having one tag for the simplest (and most common case) of a single parameter, and then switching to the url/param idiom when there are multiple. -Ted. - 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: [S2] Experimental Features
Ted Husted wrote: It would be great if there were a portlet plugin. I have no idea how the support is implemented, but I expect it would not be that easy. :) Well, the PortletDispatcher (Jsr168Dispatcher.java) and related portlet request support classes would probably be easy to separate out. The trick would be the form and url tags which right now have specific portlet behavior for building portlet url's. The real question is do we want separate tags for portlet urls? If so it might be possible to have a subclass of the url and form tag for portlet environments. If not, then we'd either have to leave the portlet support in core and only use it with the portlet plugin--or find some way to override how urls are build in core via the plugin. These are the issues that I see based on my limited knowledge of the portlet code. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
