Re: [Stripes-users] URL bindings not always resolved
Grzegorz,
Years ago when I was actively developing with Stripes I saw a very similar
behavior with respect to initialization of bindings where the issue only
happened on initial server request. I think it has to do with lazy
initialization of URL bindings... that for some reason do not get initialized
properly the 1st time around.
I tried debugging it for quite some time however in the end I could not get to
the root of the problem.
I know I asked about it on these lists but do not think there was ever any
resolution. IIRC this was 1.5.4 or .3
I would:
1. Look to see if there are any prior cases fitting your issue... and either
create a new issue or extend an existing open with your notes...
2. See if you could make a bare bones project demonstrating the issue and
someone (like Remi ;-) could use to resolve the issue...
I think b/c it happens on initial server request and b/c people do things like
hit their main web page URL or fire a run a non-URL binding test that few
people notice the issue.
In our case after all the extended effort we simply decided to ensure we hit
the site at least once prior to release cutover b/c in our case IIRC wasn't as
easy to reproduce b/c we
But it would be great to resolve this issue once and for all.
--Nikolaos
Sent from my iPhone
On Mar 10, 2014, at 9:25 AM, Grzegorz Krugły g...@karko.net wrote:
The call stack is
FormTag.doEndTag: 241
FormTag.buildAction: 511
UrlBuilder.toString: 304
UrlBuilder.build: 406
UrlBuilder.getBaseUrl: 454
No idea where to go from here.
W dniu 10.03.2014 14:16, Grzegorz Krugły pisze:
I've tried debugging UrlBuilder now and have the direct cause of my problems
caught.
In UrlBuilder:472 there's a line
if (baseUrl.equals(binding.toString())) {
In my code baseUrl is /organization/{$event}/{schoolId}/{param1}
and binding.toString() is /organization/{$event=index}/{schoolId}/{param1}
Note the extra =index after {$event
It causes the line 473 (baseUrl = binding.getPath();) to be skipped and
after check at line 477 (if (binding.getPath().length() baseUrl.length())
{) the baseUrl with { and }s is returned.
But if I hit refresh in the browser, the next time I debug the same code
for the same page, baseUrl also has that $event=index part and everything
works ok.
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] encrypted parameter problem
You can encrypt or decrypt as you like as far as I recall:
http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/util/CryptoUtil.html
--Nikolaos
Sent from my iPhone
On Oct 3, 2013, at 1:16 PM, Chris Cheshire cheshira...@gmail.com wrote:
In case anyone else runs into this issue my solution was to rebuild a
duplicate parameter map and decrypt any parameter that was encrypted. I dug
through the stripes source to find out how the validations were handled and
came up with :
UrlBuilder builder = new UrlBuilder(req.getLocale(), urlBinding,
true);
// create a duplicate map of the parameters
HashMapString, String[] newMap = new
HashMap(req.getParameterMap());
// locate validations for this action
MapString, ValidationMetadata validations =
configuration.getValidationMetadataProvider().getValidationMetadata(getClass());
if (validations != null) {
// If a field is encrypted, decrypt it and replace its values
in the new parameter map
for (String property : validations.keySet()) {
if (validations.get(property).encrypted()) {
ListString newValues = new ArrayList();
for (String encValue : newMap.get(property)) {
newValues.add(CryptoUtil.decrypt(encValue));
}
newMap.put(property, newValues.toArray(new
String[newValues.size()]));
}
}
}
builder.addParameters(newMap);
On Tue, Sep 17, 2013 at 11:49 AM, Chris Cheshire cheshira...@gmail.com
wrote:
I have a login interceptor that redirects to a login page where necessary
with a next parameter set to the url that was just accessed, like so :
if (user == null LOGIN_NEEDED.contains(clazz)) {
resolution = new RedirectResolution(Login.class);
if (context.getRequest().getMethod().equalsIgnoreCase(GET)) {
((RedirectResolution)resolution).addParameter(next,
action.buildReturnUrl());
}
}
return resolution;
buildReturnUrl is defined in my base action class as :
public String buildReturnUrl() {
try {
HttpServletRequest req = getContext().getRequest();
ActionResolver resolver =
StripesFilter.getConfiguration().getActionResolver();
ActionBean bean = resolver.getActionBean(this.context,
req.getRequestURI());
String urlBinding = resolver.getUrlBinding(bean.getClass());
UrlBuilder builder = new UrlBuilder(req.getLocale(), urlBinding,
true);
builder.addParameters(req.getParameterMap());
return builder.toString();
}
catch (StripesServletException ex) {
throw new RuntimeException(failed to build url, ex);
}
}
(I resorted to this as opposed to the method shown in the Stripes book
because it does not handle clean urls properly. If you have a binding such
as /some/path/{id}, you end up with /some/path/foo?id=foo).
However, URLBuilder is encrypting the parameters as it builds so what is
already encrypted turns into a broken value. Since all the methods to modify
the request map in StripesRequestWrapper throw
UnsupportedOperationExceptions, I can't decrypt the encrypted parameters
(known parameter names) and then replace them so they get re-encrypted
properly by the URLBuilder.
How can I modify the request parameters to fix the double encoding issue?
Thanks
Chris
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] BeanFirstPopulationStrategy problem
Cheshire,
I agree with you that from a user experience perspective you should
distill/cleanup things as much as possible so that the user has less to sift
through in resolving the errors.
Sounds like you want to attempt your cleanup on error and on validation. It's
been a long time since I worked with Stripes so don't recall how to handle that
anymore.
The other YMMV alternative is to say consider splitting your form such that the
list of images occurs on a separate step that way the other errors can be dealt
with on say a prior step; again I have no idea if in your case this is good or
bad as it depends on how many other form elements you have, how many can have
errors, how is the user experience affected, etc...
--Nikolaos
Sent from my iPhone
On 2013-08-02, at 11:15 AM, Chris Cheshire cheshira...@gmail.com wrote:
The binding error issue dawned on me right after I sent the email.
Dealing with the empty entries isn't a problem in the event handler (just
check for null first), it's more of an issue on resubmission of the form.
Part of the validation is to make sure the images being uploaded aren't over
a specific size. So say 3 urls are entered, and the 2nd one comes back as too
large. The form gets rendered with the error under that url. The user decides
to delete the 2nd url and resubmit the form, but there are still validation
errors elsewhere. Now the form gets rendered with a blank entry in the url
list.
That's what I am trying to avoid. I'm just trying to clean up the user
experience.
Fixing one issue causes the other. I want to have my cake eat it too but that
doesn't look to be possible.
Chris
On Fri, Aug 2, 2013 at 11:04 AM, Freddy Daoud xf2...@fastmail.fm wrote:
Hi Chris,
I think the reason is, generally, if you submit a form with values and there
are validation errors, those values are blocked from being bound on the
action bean (validation is about disallowing invalid values, after all).
When redisplaying the form and telling the user about the errors, we want to
repopulate the form with the submitted values, but those are only available
in the request, not from the action bean.
Perhaps you could run your list compression only after validation has passed
(in the event handler)? In the case of errors, the form would be re-rendered
with the values (and error messages) in the same place as the user entered
them, but when all URLs are valid, you could then clean up the empty slots
before saving.
Hope that helps.
Cheers,
Freddy
On Fri, Aug 2, 2013, at 10:48 AM, Chris Cheshire wrote:
I have a form that allows users to enter a series of urls, backed by a list
of strings in the action bean. As a prevalidation method I am removing
empty elements :
@Before(stages={LifecycleStage.CustomValidation})
public void removeEmptyImages() {
this.log.trace(in removeEmptyImages());
if (this.images != null) {
// remove any non existant entries
ListIteratorString iter = this.images.listIterator();
while (iter.hasNext()) {
String img = iter.next();
if (img == null) {
iter.remove();
}
}
}
}
So if something was entered in element 0, 1 and 3, the list is compressed
down.
In a @ValidationMethod, the list has validity checks (making sure the urls
are actually valid etc) performed on it and I don't have to deal with null
values. However when one of those items has an error and the form is
rendered again, the validation errors are in the right place (given that
the list has been compressed), but the form values are not. They are
rendered (or attempting to be) where they originally were, despite using
the BFPS. So once elements are removed I get errors rendered by the wrong
inputs.
I took a dig into the code thinking there is a bug, and I find in BFPS
@Override
public Object getValue(InputTagSupport tag) throws StripesJspException {
// If the specific tag is in error, grab the values from the request
if (tag.hasErrors()) {
return super.getValue(tag);
}
else {
// Try getting from the ActionBean. If the bean is present and
the property
// is defined, then the value from the bean takes precedence
even if it's null
My question is why is it reverting to request values if the tag has errors?
My first reaction to a solution is to write my own subclass, copying the
code sans the first if block. However, there is probably a good reason for
the BFPS being coded like this, so maybe my solution will bugger something
else.
What am I missing here?
Thanks
Chris
--
Get your SQL database under version control now!
Version control is standard for application
Re: [Stripes-users] URL Binding with multiple URLs
Adam,
If you need to handle multiple URI's I would look at UrlRewriterFilter.
Once upon a time I too felt that Stripes should offer such a capability (in our
case it was multilingual support) and subclassing was not scalable (as you
point out as well) BUT after having built out the UrlRewriterFilter integration
I have to say I am glad I used it.
--Nikolaos
On 2013-07-24, at 11:18 AM, Adam Stokar ajsto...@gmail.com wrote:
That's not a very scalable solution. I have over 60 ActionBean classes that
would each need a subclass. I think this is a reasonable request to add to
the library.
On Wed, Jul 24, 2013 at 10:54 AM, Ben Gunter bgun...@cpons.com wrote:
A workaround is to subclass the ActionBean in question and put a different
@UrlBinding on the subclass.
-Ben
On Wed, Jul 24, 2013 at 9:59 AM, Adam Stokar ajsto...@gmail.com wrote:
Hi all,
It doesn't seem like it's possible to assign two URL's to the same action
bean. Does anyone have an easy workaround for this? I'm trying to do
something like:
@UrlBinding({/locations,/Locations})
Thanks,
Adam
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF-8 in forms problem
Daniil Sosonkin wrote:
Nikolaos - I think I was the one who started that thread. People were
very helpful and I did try then use all suggestions.
Yup... I remember now... though it sounded like you had a new problem
this time.
I do have custom LocalePicker for picking languages, it doesn't return
UTF, but we're always listing UTF encoding in web.xml (even for English).
Can you post the line in your web.xml for this and your full custom
Locale Picker? Perhaps its a syntax thing.
When dealing with many languages UTF is the way to go.
Totally agree... and that is one of the reasons we hard code it. The
other reason is because our custom Locale Picker can't readily use
languages defined in web.xml... our app is much more complex and the
same code serves a subset of languages to regional sites.
For some reason it wasn't working for properly for data submitted via
forms. Since I have SecurityFilter, I'm simply utilizing it for
setCharacterEncoding() on the request.
Right... and that too will work... and works well in your case as you
already have a filter (as you point out).
I'll do some digging later on to try figure why it doesn't work with
Stripes out of box, but as usual, its probably a mistake somewhere on
my end.
Perhaps it is... perhaps it isn't... maybe something is indeed broken...
that is why if you posted things I could compare it against what we have
and let you know. It's always nice to get a warm fuzzy feeling that the
code we depend on works well for others ;-)
In fact, Stripes itself is a filter and sets the character encoding on
the request so it is essentially doing the same thing you are doing...
so I wouldn't change what you are doing... I just don't see why it
wouldn't work with Stripes and if it is a Stripes issue then it should
be reported and fixed.
BTW what version of Stripes are you using?
Cheers,
--Nikolaos
Daniil
On 5/6/2011 1:07 AM, Nikolaos Giannopoulos wrote:
Daniil,
There was a thread in February IIRC on this and solutions were
mentioned. End-to-end UTF-8 support requires multiple layers.
If you are looking at simply posting data and having it encoded in
UTF-8 then AFAIK Stripes already performs
request.setCharacterEncoding(...) passing in the result of the call
to getCharacterEncoding() (if I recall the method name correctly) and
is easily subclassed in your own LocalePicker. I simply hard code
that method to return UTF-8 as I deal with many languages and only
care about enabling UTF-8.
The filter should be unnecessary and some have argued that the filter
provides a generic foundation for enabling UTF-8 support across
multiple frameworks and projects. I'd be curious to see why this
doesn't work with Stripes but would need to see your custom
LocalePicker and if necessary web.xml (if you set the character
encoding in web.xml vs. hard coding in your custom LocalePicker).
Cheers,
--Nikolaos
Daniil Sosonkin wrote:
After writing to the group, I've managed to fix the problem!
Solution was to add request.setCharacterEncoding(UTF-8); in my
filter. After that - it all works peaches.
On 5/3/2011 1:43 PM, Daniil Sosonkin wrote:
Hi all - I've been out of this for some time, but now back to UTF-8
issue with Stripes and mySQL. First and foremost, I'd like to
resolve Stripes on this topic. In my case, I'm interested in UTF-8
and only in UTF8. No other character sets will appear as we're are
international. I have partial success, not enough to proceed to
production. It seems as if I'm missing something.
Here's how I test it. There's MyLocalePicker which picks picks
appropriate Locale and ALWAYS returns encoding as UTF-8. I have no
problems outputting UTF-8 text because header is always set to:
Content-type: text/html;charset=UTF-8. Necessary JSPs that contain
UTF, have proper pageEncoding set on them as well.
Then I have very very simple test.jsp that takes the text.
s:form beanclass=com.orbis.web.actions.Test
s:text name=str /s:submit name=add /
/s:form
The action bean looks as following:
package com.orbis.web.actions;
import com.orbis.web.*;
import net.sourceforge.stripes.action.*;
@UrlBinding(/test.action)
public class Test extends MyActionBean
{
private String str;
public String getStr()
{
return str;
}
public void setStr(String str)
{
this.str = str;
}
public Resolution test() throws SQLException
{
return new ForwardResolution(/test2.jsp);
}
}
And test2.jsp looks as simple as the following:
%--@elvariable id=actionBean type=com.orbis.web.actions.Test--%
%@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %
%@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; %
%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
%@ taglib prefix=s
uri=http://stripes.sourceforge.net/stripes-dynattr.tld; %
%@ taglib prefix=o
Re: [Stripes-users] UTF-8 in forms problem
Daniil,
There was a thread in February IIRC on this and solutions were
mentioned. End-to-end UTF-8 support requires multiple layers.
If you are looking at simply posting data and having it encoded in
UTF-8 then AFAIK Stripes already performs
request.setCharacterEncoding(...) passing in the result of the call to
getCharacterEncoding() (if I recall the method name correctly) and is
easily subclassed in your own LocalePicker. I simply hard code that
method to return UTF-8 as I deal with many languages and only care
about enabling UTF-8.
The filter should be unnecessary and some have argued that the filter
provides a generic foundation for enabling UTF-8 support across
multiple frameworks and projects. I'd be curious to see why this
doesn't work with Stripes but would need to see your custom LocalePicker
and if necessary web.xml (if you set the character encoding in web.xml
vs. hard coding in your custom LocalePicker).
Cheers,
--Nikolaos
Daniil Sosonkin wrote:
After writing to the group, I've managed to fix the problem! Solution
was to add request.setCharacterEncoding(UTF-8); in my filter. After
that - it all works peaches.
On 5/3/2011 1:43 PM, Daniil Sosonkin wrote:
Hi all - I've been out of this for some time, but now back to UTF-8
issue with Stripes and mySQL. First and foremost, I'd like to resolve
Stripes on this topic. In my case, I'm interested in UTF-8 and only
in UTF8. No other character sets will appear as we're are
international. I have partial success, not enough to proceed to
production. It seems as if I'm missing something.
Here's how I test it. There's MyLocalePicker which picks picks
appropriate Locale and ALWAYS returns encoding as UTF-8. I have no
problems outputting UTF-8 text because header is always set to:
Content-type: text/html;charset=UTF-8. Necessary JSPs that contain
UTF, have proper pageEncoding set on them as well.
Then I have very very simple test.jsp that takes the text.
s:form beanclass=com.orbis.web.actions.Test
s:text name=str /s:submit name=add /
/s:form
The action bean looks as following:
package com.orbis.web.actions;
import com.orbis.web.*;
import net.sourceforge.stripes.action.*;
@UrlBinding(/test.action)
public class Test extends MyActionBean
{
private String str;
public String getStr()
{
return str;
}
public void setStr(String str)
{
this.str = str;
}
public Resolution test() throws SQLException
{
return new ForwardResolution(/test2.jsp);
}
}
And test2.jsp looks as simple as the following:
%--@elvariable id=actionBean type=com.orbis.web.actions.Test--%
%@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %
%@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; %
%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
%@ taglib prefix=s
uri=http://stripes.sourceforge.net/stripes-dynattr.tld; %
%@ taglib prefix=o uri=/TLDs/tags.tld %
%@ page isELIgnored=false %
Added: ${actionBean.str}
The problem is that resulting text is all grumbled. The success comes
when I change setStr to the following:
this.str = new String(str.getBytes(ISO-8859-1), UTF-8);
Then text becomes true UTF and result of action bean is all fine. The
problem with that solution is that I don't want to do it, I'd like to
have Stripes do that for me. I really think that its not problem with
Stripes, but I did something wrong and not utilizing Stripes
correctly. Will happily provide source to MyLocalePicker if needed.
BTW - tomcat 7.0.11 server.xml contains URIEncoding=UTF-8 for GET
requests.
We sort of need to resolve this as we have to start supporting
international input and not just output.
Thank you,
Daniil
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Nikolaos Giannopoulos
Director, Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold
Re: [Stripes-users] plugin strategies?
protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Morten Matras Consultant Blob Communication ApS Svendsagervej 42 DK-5240 Odense NØ P: (+45) 36 96 07 06 tel:%28%2B45%29%2036%2096%2007%2006 W: www.blobcom.com http://www.blobcom.com E: morten.mat...@gmail.com mailto:morten.mat...@gmail.com -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Morten Matras Consultant Blob Communication ApS Svendsagervej 42 DK-5240 Odense NØ P: (+45) 36 96 07 06 W: www.blobcom.com http://www.blobcom.com E: morten.mat...@gmail.com mailto:morten.mat...@gmail.com -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director, Information Technology BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server
Re: [Stripes-users] Stripes testing with MockServletContext and Stripersist
Sebastien,
You say:
Stripersist is supposed to do all the job for me to retreived and modify the
user.
Clearly there is something missing in this picture. By default Stripes
creates a new instance of an ActionBean on each invocation yet you are
only passing in the id and then your update resolution is merely doing
a save.
Do you have a custom converter or something that is loading the object
by id and making it available as the user attribute?
Please simply post your complete UserAdminBean code and any custom
converter that you may have.
I can't help you if I don't see the full picture.
--Nikolaos
Sebastien Belin wrote:
Hi,
@Frank:
I don't think I use any Open Session/EntityManager in View filter unless Stripersist/Stripes implements one.
The only filter 'm using are ShiroFilter for security and StripesFilter.
But I'm going to investigate this a bit more.
@Nikolaos.
Thanks for all your effort to help me.
I do understand what you mean about transaction and detached object could not
being persisted.
If I do a merge before saving or deleting an existing object my tests work with
great success indeed.
I want to clarify something in my test though, I never give a detached instance
to the mockRoundtrip. I just give the id and the name as parameters.
Stripersist is supposed to do all the job for me to retreived and modify the
user.
The update method does only the saving/commit.
The getUser() method is really simple too:
public class UserAdminBean {
private User user;
...
public User getUser() {
return user;
}
...
public Resolution update() {
getDao().save(getUser());
getDao().commit();
return new RedirectResolution(this.getClass(), view).addParameter(user,
getUser());
}
...
}
@Test
public void testUpdate() throws Exception {
User user = createUser();
MockRoundtrip mockRoundtrip = new MockRoundtrip(getServletContext(),
UserActionBean.class);
mockRoundtrip.addParameter(user, String.valueOf(user.getId()));
mockRoundtrip.addParameter(user.name, newName);
mockRoundtrip.execute(update);
RedirectResolution redirectResolution = new RedirectResolution(UserActionBean.class,
view).addParameter(user, user);
String redirectUrl = redirectResolution.getUrl(Locale.getDefault());
verifyDestination(mockRoundtrip, redirectUrl);
assertUserUpdated(user);
}
Thanks,
Sebastien
-Original Message-
From: Frank Pavageau [mailto:frank.pavag...@gmail.com]
Sent: 08 April 2011 16:38
To: Stripes Users List
Subject: Re: [Stripes-users] Stripes testing with MockServletContext and
Stripersist
On Fri, Apr 8, 2011 at 4:54 PM, Sebastien Belin sebastien.be...@adaptris.com
wrote:
I indeed don't do any merge to reattached the user object as I though
it's not really efficient and it was not needed as it was working in
not testing mode.
I also didn't think that with Stripersist the object was detached when
loaded in the ActionBean.
Aren't you by any chance using in your webapp a filter to implement the Open
Session/EntityManager in View pattern ? Like the one from Spring (OpenSessionInViewFilter) ?
That would be the reason why your entities are not detached in not testing mode.
Frank
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming smartphone on the nation's most
reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Nikolaos Giannopoulos
Director, Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Confusion on Stripes error
Melinda,
Could it be that in some not so common case you construct a URL to an
action bean and that by mistake it starts with: /reqs vs. /req?
Using your favourite IDE you should be able to scan all your project
files for /reqs or reqs and see what comes up.
Also looking for anything that redirects or forwards to
ApproveList.action as the incorrect URI is /reqs/ApproveList.action... .
Good Luck,
--Nikolaos
Savoy, Melinda wrote:
I think I may have found the issue but need to know where the actionBean
listed: [/reqs/ApproveList.action] is getting picked up from.
The actionBean is actually: [/req (not reqs as I indicated
above)/ApproveList.action].
How can I find this un-located ActionBean that is bound to the URL:
[/reqs/ApproveList.action]? I'm not sure where Stripes is picking this up
from?
Again, any help/direction is appreciated.
Regards.
-Original Message-
From: Savoy, Melinda
Sent: Sunday, April 10, 2011 5:41 PM
To: 'Stripes Users List'
Subject: [Stripes-users] Confusion on Stripes error
When stepping through the methods in the code of this action bean that is
called from the JSP page locally and correctly, I am getting no error as such
below but only sporadically (3x today only) on our PROD server. We just
moved the web app from a JBoss app server to Tomcat this morning and then we
started getting the error below.
We're on Stripes 1.5.5.
I'm not sure why this error is only happening sporadically and not
consistently.
Any help/direction on what is going on would be greatly appreciated.
Thank you.
-Original Message-
From: SCMIS Application [mailto:nore...@texashealth.org]
Sent: Sunday, April 10, 2011 3:25 PM
To: Savoy, Melinda; Burgoon, Ken
Subject: SCMWeb Runtime Exception - PHD - DEVASSS - PROD
The SCMWeb Inventory/Purchasing system has encountered an ERROR.
Login Account : DEVASSS
Region: PROD
Entity: PHD
Stack trace :
net.sourceforge.stripes.exception.ActionBeanNotFoundException: Could not
locate an ActionBean that is bound to the URL [/reqs/ApproveList.action].
Commons reasons for this include mis-matched URLs and forgetting to implement
ActionBean in your class. Registered ActionBeans are:
{/maint/CommonList.action=class
org.texashealth.scmis.stripes.action.maint.CommonListActionBean,
/req/StockRequisition.action/=class
org.texashealth.scmis.stripes.action.req.StockRequisitionActionBean,
/Contact.action/=class
org.texashealth.scmis.stripes.action.ContactActionBean,
/maint/CommonList.action/=class
org.texashealth.scmis.stripes.action.maint.CommonListActionBean,
/req/NonStock.action/=class
org.texashealth.scmis.stripes.action.req.NonStockActionBean,
/notes/Notes.action/=class
org.texashealth.scmis.stripes.action.notes.NotesActionBean,
/AjaxTags.action=class
org.texashealth.scmis.stripes.action.AjaxTagsActionBean,
/req/Search.action=class org.texashealth.scmis.stripes.actio!
n.req.SearchActionBean, /req/CreateStock.action/=class
org.texashealth.scmis.stripes.action.req.CreateStockActionBean,
/req/ApproveList.action=class
org.texashealth.scmis.stripes.action.req.ApproveListActionBean,
/po/StocklessRequisition.action/=class
org.texashealth.scmis.stripes.action.po.StocklessRequisitionActionBean,
/security/Entity.action/=class
org.texashealth.scmis.stripes.action.security.EntityActionBean,
/req/CreateStock.action=class
org.texashealth.scmis.stripes.action.req.CreateStockActionBean,
/common/SearchLookup.action=class
org.texashealth.scmis.stripes.action.common.SearchLookupActionBean,
/req/NonStock.action=class
org.texashealth.scmis.stripes.action.req.NonStockActionBean,
/Contact.action=class org.texashealth.scmis.stripes.action.ContactActionBean,
/req/Search.action/=class
org.texashealth.scmis.stripes.action.req.SearchActionBean,
/AjaxTags.action/=class
org.texashealth.scmis.stripes.action.AjaxTagsActionBean,
/ajax/AutoComplete.action=class org.texas!
health.scmis.stripes.action.ajax.AutoCompleteActionBean, /secu!
rity/Ent
ity.action=class
org.texashealth.scmis.stripes.action.security.EntityActionBean,
/notes/Notes.action=class
org.texashealth.scmis.stripes.action.notes.NotesActionBean,
/req/StockRequisition.action=class
org.texashealth.scmis.stripes.action.req.StockRequisitionActionBean,
/po/StocklessRequisition.action=class
org.texashealth.scmis.stripes.action.po.StocklessRequisitionActionBean,
/po/InventoryRequisition.action/=class
org.texashealth.scmis.stripes.action.po.InventoryRequisitionActionBean,
/common/SearchLookup.action/=class
org.texashealth.scmis.stripes.action.common.SearchLookupActionBean,
/controller/DefaultView.action/=class
net.sourceforge.stripes.controller.DefaultViewActionBean,
/ajax/AutoComplete.action/=class
org.texashealth.scmis.stripes.action.ajax.AutoCompleteActionBean,
/common/Lookup.action=class
Re: [Stripes-users] Stripes testing with MockServletContext and Stripersist
Sebastien,
Stripersist is a very thin layer on top of JPA. A very useful layer
mind you that integrates very well with Stripes.
If you say that your code is working then I suspect its how you are
dealing with things in your tests... not necessarily the
MockServletContext IMO.
If I look at your tests I see you call the following at the top of the
tests:
User user = createUser();
Without seeing your code I assume this creates a mock object OR loads a
canned object from the DB.
If you want to update it then you will need to do a merge on this
object vs. doing a persist (which is fine for a new object).
If you want to delete it then you will need to do a merge and then a
remove (of course this isn't very efficient and there are other ways
but that's what you get for using the basic capabilities of an ORM i.e.
you could write some native sql query or something to do a straight
delete by PK).
If you don't do the merge first then the object can not re-attach to a
persistent context.
If this doesn't help then please provide more code for:
- User user = createUser();
- getDao().save(getUser());
- getDao().delete(getUser ());
HTH.
--Nikolaos
Sebastien Belin wrote:
Thanks for your answer Nikolaos,
Yeah the actionBean is beend tested without the Mock/Test framwerok.
In fact the code I use for the ActionBean is re-used from another
application which is working perfectly but didn't have any action tests.
I understand what you're saying about the object being detached but I
thought that was one of the point of using Stripersist, and I can't
really see why it does work in normal mode and not in test mode.
I found a lot of article in google talking about ORM and detached
object with JPA/Hibernate but nothing for MockServletContext with
Stripersist that why I posted to the email list.
Anyway, thank you for your help.
Sebastien
*From:* Nikolaos Giannopoulos [mailto:nikol...@brightminds.org]
*Sent:* 07 April 2011 19:32
*To:* Stripes Users List
*Subject:* Re: [Stripes-users] Stripes testing with MockServletContext
and Stripersist
Sebastien,
Have you tested your ActionBean directly without using Mock / Test
framework? I'm going to guess that it won't work there either.
Because ORM's have the notion of persistence context... if you load an
object in one transaction and later try to persist it the object in
another transaction the object is considered detached and needs to be
re-attached to a persistence context... say for example using merge
vs. persist.
In any event, if you google your error you should find lots of
information on this topic.
This is a common issue for update or delete w/ JPA and / or Hibernate.
--Nikolaos
Sebastien Belin wrote:
Hi All,
I've started a new simple project using stripes and stripersist/hibernate.
As the basic development is finished I wanted to add some testing.
Folowing the example given in
http://www.stripesframework.org/display/stripes/Unit+Testing I've used
MockServletContext.
I want to test my UserActionBean. This class has simple handler method
such as list(), view(), cancel(), create(), edit(), save(), delete()
and update();
I also have a getter and setter for the User entity.
The update() method handler is as simple as:
public Resolution update() {
getDao().save(getUser());
getDao().commit();
return new RedirectResolution(this.getClass(),
view).addParameter(user, getUser());
}
The delete() method handler:
public Resolution delete() {
getDao().delete(getUser ());
getDao().commit();
return new RedirectResolution(this.getClass());
}
I've writen a test class UserActionBeanTest and all test run correctly
(list, view, create, save ...) but the update and delete one.
@Test
public void testDelete() throws Exception {
User user = createUser();
MockRoundtrip mockRoundtrip = new MockRoundtrip(getServletContext(),
UserActionBean.class);
mockRoundtrip.addParameter(user, String.valueOf(user.getId()));
mockRoundtrip.execute(delete);
String redirectUrl = (new
RedirectResolution(UserActionBean.class)).getUrl(Locale.getDefault());
verifyDestination(mockRoundtrip, redirectUrl);
}
@Test
public void testUpdate() throws Exception {
User user = createUser();
MockRoundtrip mockRoundtrip = new MockRoundtrip(getServletContext(),
UserActionBean.class);
mockRoundtrip.addParameter(user, String.valueOf(user.getId()));
mockRoundtrip.addParameter(user.name, newName);
mockRoundtrip.execute(update);
RedirectResolution redirectResolution = new
RedirectResolution(UserActionBean.class, view).addParameter(user,
user);
String redirectUrl = redirectResolution.getUrl(Locale.getDefault());
verifyDestination(mockRoundtrip, redirectUrl);
assertUserUpdated(user);
}
When I run them I received some error message saying that the object
user is detached.
For Update
Re: [Stripes-users] Stripes testing with MockServletContext and Stripersist
) at net.sourceforge.stripes.mock.MockFilterChain.doFilter(MockFilterChain.java:66) at net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:247) ... 31 more Caused by: org.hibernate.PersistentObjectException: detached entity passed to persist: com.package.model.User at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:127) at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61) at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:808) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:782) at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:786) at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:672) For Delete: java.lang.IllegalArgumentException: Removing a detached instance com.package.model.User#95 at org.hibernate.ejb.event.EJB3DeleteEventListener.performDetachedEntityDeletionCheck(EJB3DeleteEventListener.java:65) at org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:107) at org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:73) at org.hibernate.impl.SessionImpl.fireDelete(SessionImpl.java:956) at org.hibernate.impl.SessionImpl.delete(SessionImpl.java:934) at org.hibernate.ejb.AbstractEntityManagerImpl.remove(AbstractEntityManagerImpl.java:702) at com.package.dao.jpa.JpaBaseDao.delete(JpaBaseDao.java:70) at com.package.action.admin.EntityAdminBean.delete(EntityAdminBean.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at net.sourceforge.stripes.controller.DispatcherHelper$6.intercept(DispatcherHelper.java:467) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158) at net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155) at net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74) at net.sourceforge.stripes.controller.DispatcherHelper.invokeEventHandler(DispatcherHelper.java:465) at net.sourceforge.stripes.controller.DispatcherServlet.invokeEventHandler(DispatcherServlet.java:278) at net.sourceforge.stripes.controller.DispatcherServlet.service(DispatcherServlet.java:160) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at net.sourceforge.stripes.mock.MockFilterChain.doFilter(MockFilterChain.java:66) at net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:247) I really can't work out what's wrong and why the object is detached when using MockServletContext. If any one could help it would be much appreciated. Don't hesitate to ask if you need more info. Thanks. Seb -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director, Information Technology BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Character encoding of parameter values
Thomas, The reason this worked is b/c Stripes framework looks up the character encoding from the Locale Picker (which in your case gets initialized via the param character encoding part UTF-8 you specified in your web.xml) and invokes request.setCharacterEncoding using that value. Looks like you have dealt with part of the UI / Stripes aspect of this problem just fine BUT if you want full UTF-8 there are other moving parts such as setting the accept charset on all your JSPs to UTF-8... though in the end it depends how far you need to go... . As such... check out the thread entitled UTF8 from form to mySQL as it covers many areas. --Nikolaos Thomas Menke wrote: Hi @ll, I just noticed that in the application that I have just started parameter values did not end up correctly in my database if the parameter values contained non-ascii characters (tested with german umlauts). It looks like my browser (Opera) passed the parameter unicode encoded and stripes assumed that it is iso-8859-1 encoded and translated the value to unicode again which of course results in strange symbols ;-). I eventually found this: http://www.stripesframework.org/display/stripes/Localization#Localization-DeterminingtheCharacterEncodingtouse And added this: init-param param-nameLocalePicker.Locales/param-name param-valueen_US:UTF-8/param-value /init-param to my web.xml which resolved the problem in my browser. But I guess that there are plenty of ways to break this solution (such as setting my browser to a different locale). How can I deal with the problem? Thanks, Thomas -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Locale Picker and request interceptor
FosPat wrote: Oscar Westra van Holthe - Kind vient de nous annoncer : On 24-09-2009 at 16:45, Lionel wrote: Hi all ! I would like to set the user locale as a thread local variable from an interceptor (based on the user account) and get this value from a custom LocalePicker. But it seems that the LocalePicker.getLocale() is called before interceptors. Is there some way to configurer the execution order to have muy interceptor called before the LocalePicker ? No. But you can do the following: 1. Create a custom ActionBeanContext that retreives the user account information based on either request.getUserPrincipal(), other request data, or the session. Put your variable in a request attribute. Configure the StripesFilter to use this class directly or put it in an extension package. 2. Create a custom LocalePicker (subclass the DefaultLocalePicker for example). It get's the request, so you can access your variable to determine the locale to use. Configuration is analogous to point 1. Oscar Late answer, but I faced the same issue with a new application. The Locale is in dabatabse on the user, but I can't load the user as Stripersist is not initialized yet when MyLocalePicker is called... FosPat, I imagine you meant Late question. Correct? If so, let me offer a 3rd option on at least how we handle this which may or may not be useful to you or offer you other ideas when a DB is involved. Until the user logs in for the 1st time we need to determine the users locale in a way that does not involve the DB. We use UrlRewriteFilter for many of our requirements involving domains but one nice feature it has is to write a class that does anything. In our PreProcessFilter class we go through a series of checks to determine the users locale i.e. we start with is there a locale cookie, otherwise check the accept langs on the request, etc... and once its determined its added on the request and a cookie is created if it wasn't present. We then have a custom locale picker that simply looks for and pulls this locale from the request and provides it to Stripes. Once the user logs or is logged in their preferred or profile locale gets set as a locale cookie (unless it already exists and matches the existing locale cookie) and everything else behaves the same. Also if they ever clear their cookies the above process will reset it from their profile. HTH, --Nikolaos -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] re quest/response scoping
Totally agree with Christian that the Stripes version can be redefined
as Christian points out.
Moreover, when doing CRUD operations we typically need to display the
entity that the user wants to delete and ask for user confirmation i.e.
we don't just ask the user if they wants to delete id but
actually show them the record and ask: Do you really want to delete
it?. I might add that especially if you are dealing with a user record
you would want the admin to see the record before deleting it. No?
So in our case the object is loaded regardless... as Christian points out.
But the usage of an object over an id for delete goes beyond that... as
well... in CRUD for us... and for anyone using say JPA and an ORM.
In that if you use say JPA and Hibernate the OOB / least amount of code
approach (not necessarily the most efficient) to delete an object is to
use the object itself to do so. Of course that entails for us a 2 step
DB call (merge and delete) and clearly isn't the most efficient approach
but that is what you get OOB with an ORM. What we will do to improve
that later is use the id from the object to execute a simple delete SQL
statement and even then our BaseModel class heirarchy holds the ID so we
would simply pass in the object to delete and have its ID used to delete it.
So sorry... in the case of CRUD... including delete... we don't need to
define that separate id attribute in the action bean.
The only place an ID is defined in our case is in the URL binding... and
that is more so b/c of how we want to define clean URLs.
This is why I suggested you look at some more complete real world
examples to compare... b/c you might be surprised :-)
HTH,
--Nikolaos
Poitras Christian wrote:
Hi Tony,
Personally, I would code the action bean differently making it look almost
exactly like the Spring version.
// ANNOTATIONS, GETTERS AND SETTERS OMITTED FOR BREVITY
class MyActionBean extends BaseActionBean {
private User user;
Resolution deleteUser() {
userService.deleteUser(user);
return new RedirectResolution(/listUsers.jsp);
}
Resolution addUser() {
userService.addUser(user);
return new ForwardResolution(/showUser.jsp);
}
}
Is there anything wrong in getting the whole user object to delete it instead
of just the id?
That's even more trivial to do if your user converter takes the id.
Christian
-Message d'origine-
De : Tony Drago [mailto:do...@mailinator.com]
Envoyé : March-03-11 4:52 AM
À : stripes-users@lists.sourceforge.net
Objet : Re: [Stripes-users] re quest/response scoping
Nikolaos Giannopoulos wrote:
Encapsulation in OO IMHO pertains to the class as a whole not the method
level. If you want to encapsulate at the method level then your going
to have a hard time not allowing someone to access and affect other
attributes of the class (e.g. other attributes) as even if you mark
attributes as private any method of the class can alter it.
Perhaps you might be used to defining classes that should ideally be
further refactored into multiple classes. Not sure - but if you could
provide some more complex examples then we could examine specifics and
dispense with theory or generalized statements (from my side as well) ;-)
Thanks for the response. You asked for a specific example, so here you
go.
An action bean which creates and deletes users. IMO, these two actions
belong to the same bean, but in the case of add we need all the User
properties, but in the case of delete we only need the id. In Spring the
controller would look like this:
// ANNOTATIONS OMITTED FOR BREVITY
class MyController {
public String deleteUser(Integer userId) {
userService.deleteUser(userId);
return redirect:/listUsers;
}
public ModelAndView addUser(User user) {
userService.addUser(user);
return new ModelAndView(/showUser, user);
}
}
In Stripes the action would look like this:
// ANNOTATIONS, GETTERS AND SETTERS OMITTED FOR BREVITY
class MyActionBean extends BaseActionBean {
private Integer userId;
private User user;
Resolution deleteUser() {
userService.deleteUser(userId);
return new RedirectResolution(/listUsers.jsp);
}
Resolution addUser() {
userService.addUser(user);
return new ForwardResolution(/showUser.jsp);
}
}
From a readability point of view I much prefer the Spring MVC code because I
can tell without looking at the method body, what parameters are used by
each handler/event. In the case of Stripes, I have to read the body of each
method to figure out whether userId/User are used as request parameters or
view model by each event.
I feel like the Stripes approach is poorly encapsulated because
- public getters/setters must be defined for userId and User, but these
should only be accessible to the event
Re: [Stripes-users] re quest/response scoping
Tony, Comments in-line... Tony Drago wrote: Hi, First of all, I promise I'm not trolling. I'm going to say some critical things about Stripes here, but my intention is to understand whether I'm missing something, not to offend. If you don't like to read criticism of your favorite framework, you should probably not read any further. Constructive criticism is great... making people think makes everything / everyone hopefully evolve ;-) What bugs me about the Stripes approach is that the request parameters and the model (UserProfile) are not scoped to the relevant handler method. Sure... but nothing stops you from having a class that has only 1 event handler in it. But yes I see your point... . In most cases, a controller class has more than one handler, and I really dislike the fact that there's no way to tell just by looking at the code which request params and view model go with which handler method. On the surface your statement is totally valid and I have to agree. However... you could look at this from at least 2 different angles: 1) If the request params are so different then why put them in the same action bean in the 1st place? Nothing stops you from doing so... but is that good design... perhaps not i.e. any kind of class whether its an action bean or a POJO by definition encapsulates behaviour and attributes... if there are attributes in there that don't totally relate to the behaviour then refactoring might be warranted. 2) On the other hand if the request params are similar... as in cases like for example doing CRUD on a database entity... then I find it to be a non-issue as the action bean deals with the request params it has defined in it. In fact, I find it to be refreshing and clear and eliminates me having to define the params the same over and over again for multiple event handlers. I would suggest you try building some more real world examples / test cases to see if it suits you and in the end if it doesn't then so be it... but these examples are too simplistic to realize any significant pros or cons. I know you could put each handler in its own class, but that will create a whole other set of problems. As I mentioned if the attributes are really that different perhaps its warranted. But I'm sure you'll have cases it isn't. Test code and documentation is also not out of the question... Right? If you have say for example on a add event that the id should not be set or should be passed in as - or whatever then you could should test for that and document that in your add event handler. But what other issues are you alluding to? A proliferation of classes? Fundamentally, having variables which should be scoped to a single method scoped to a single class, feels like bad OO practice (poor encapsulation). Am I missing something, or is this just something that most Stripes users don't care about? Encapsulation in OO IMHO pertains to the class as a whole not the method level. If you want to encapsulate at the method level then your going to have a hard time not allowing someone to access and affect other attributes of the class (e.g. other attributes) as even if you mark attributes as private any method of the class can alter it. Perhaps you might be used to defining classes that should ideally be further refactored into multiple classes. Not sure - but if you could provide some more complex examples then we could examine specifics and dispense with theory or generalized statements (from my side as well) ;-) HTH, --Nikolaos -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripersist fails in long running JUnit test
Karen, I haven't seen this but then again our tests run under 60 seconds. Moreover, do you have a stack trace? Because if you did the Stripersist code is quite compact and might offer clues as to what is happening. Also are you accessing your DB in these tests via connection pooling? If so, perhaps there is something in there that gets reset after 90 seconds. HTH, --Nikolaos Karen wrote: Hi everybody, I have a few JUnit test that use net.sourceforge.stripes.mock.MockServletContext to test some persistent classes that use Stripersist, but when the unit test runs long then after about 90 seconds, the Hibernate EntityManagerFactory gets terminated (without any clear reason in the log that explains why). Anybody has experienced the same issue? -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Still seeing ConcurrentModificationException
Remi, Your assessment is quite detailed and appears to be very thorough on multiple levels. Yes. JRebel adds it own class and many months ago I had a wild time tracing an issue when the UrlBindingFactory singleton code was converted to using an instance variable. Indeed this class exists in the JRebel Stripes plug-in. In addition, you are also correct JRebel is not to be used in Production so this issue then becomes less critical and affects development environments (which doesn't mean it isn't huge it just means you won't be affected in production). And as far as multiple threads are concerned... that could explain why we don't see it as we use TestNG and disable parallel threads... not because we want to but because we had some issues with singletons in unit tests in the past. As such, making a change to Stripes to increase synchronization is NOT something that can be justified IMO. But that is my 2 cents ;-) Great assessment! --Nikolaos VANKEISBELCK Remi wrote: Hi folks, Just had a look, the stack seems to show some code that ain't in Stripes (at least not in the 1.5.x branch at the time I write this email). Found this in the stack trace : net.sourceforge.stripes.controller.NameBasedActionResolverHelper.rescanFor (NameBasedActionResolverHelper.java:217) My guess is that you're using a modified action resolver (probably from JRebel) which attempts to reload the beans while incoming requests trigger bean class lookups at the same time. Hence the concurrent modification exception : request handling thread is iterating over UrlBindingFactory's classCache map at the same time JRebel's action resolver changes the map content. Stripes is supposed to scan for action beans once and only once, before being ready to handle requests, so using unsynchronized maps interlally in UrlBindingFactory is good design. Otoh, it doesn't offer thread-safe action reload. To fix the problem, we could synchronize access to the maps, or use ConcurrentHashMap. Yee (or anybody willing to see this fixed), you can demo the problem by writing a unit test that accesses UrlBindingFactory concurrently (via several threads). Then, you can fix by synchronizing where appropriate. Last, we need to see what's the performance penalty. IMHO this ain't a critical bug at all : stop using your browser while JRebel does the reload and you won't have any exception, and anyway JRebel ain't no production software as far as I know, so it's only a minor hassle. Still, if you want to give it a shot : this would be a better design that allow to write really reloadable action resolvers :P Cheers Remi 2011/2/11 samuel baudouin osenseij...@gmail.com mailto:osenseij...@gmail.com Hi all, Yee From your stack and your code, it seems that the problem comes from one of the Stripes class... When this exception occurs is it always at the same point? Is the stack always the same? While I never encountered the problem, here is a way that could help you : You could use a load tester program such as JMeter (don't forget to make it share the session across the different virtual users). It would probably not reproduce the problem but would certainly make your life easy when testing with/without the different components. On your IDE, you could then set up an exception breakpoint on that ConcurrentModificationException and when raised pause the whole JVM (ie pause all the threads -- see breakpoint properties in Eclipse). From here, you can see where the different threads are at, and hopefully see where the double modifications is done. You would probably need to have the sources of Stripes and JRebel attached to your project (not in your project but just as a source lookup for Eclipse) in order to browse to the different classes. I know this is a bit of a bazooka to kill a fly, but this kind of random exception could be particularly tricky to pin point. If you have the time, the necessity, and most importantly not found a work around, this is how you could go... Regards, Sam On Fri, Feb 11, 2011 at 3:37 AM, Samuel Santos sama...@gmail.com mailto:sama...@gmail.com wrote: Hi Yee and Nikolaos, We do not use JRebel and have come across the same issue several times, so it's surely a Stripes issue. While we get the exception logged, it's transparent to the client, the application does not crash and the client never sees an error. This issue is very rare and only happens when you open multiple tabs at once as Yee pointed out. -- Samuel Santos http://www.samaxes.com/ On Thu, Feb 10, 2011 at 3:00 PM, Nikolaos Giannopoulos nikol...@brightminds.org mailto:nikol...@brightminds.org wrote: Yee, Well then... turn off JRebel and attempt to reproduce the bug... if you can't then it isn't
Re: [Stripes-users] Still seeing ConcurrentModificationException
Yee, Well then... turn off JRebel and attempt to reproduce the bug... if you can't then it isn't Stripes. Right? I know its tempting to keep JRebel engaged all the time and I recall the time I hit a bug in JRebel and thought it was one in Stripes... it took me a long time to consider simply turning off JRebel... but if you already suspect JRebel then flip it off and attempt to reproduce. --Nikolaos Yee wrote: Hi Nokolaos, The bug has already been reported to JRebel. Stripes plugin for JRebel was created by third party, so it could take a while for it to be fixed. My concern here is to ascertain whether ConcurrentModificationException error is a bug in Stripes - or caused by the bug in JRebel. Cheers, Yee -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Still seeing ConcurrentModificationException
Yee, If you want people to help you need to give as much information as possible to pin-point your problem. The full stack trace would be a great start. As well, the JSP code and if you could strip it down to a minimal case that reproduces the issue that would be even more ideal. You'll also need to specify the JRebel plugins you use. As far as JRebel and 1.5.5 is concerned I use both and have no issues. You'll need to go deeper if you expect any help. --Nikolaos Yee wrote: For one thing - jRebel's Stripes plugin was having working with Stripes 1.5.5. One particular jsp is causing jRebel to scan some resources 1000+ times, resulting in extremely slow load time. I am wondering that could be the cause of the ConcurrentModificationException as well. I only see the problem very occasionally so it is hard to pin it down. Is anybody seeing this problem? -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Still seeing ConcurrentModificationException
Yee, If you definitely suspect a bug in JRebel then post to their forums. I have had great results / turn around (no pun intended) by the support team and they have gone as far as tweaking JRebel to resolve issues I reported in the past. I am using JRebel 3.1.2a with MyEclipse 8.6 and I have no issues with Stripes 1.5.x (.3+). --Nikolaos Yee wrote: I figured out how to reproduce the error. With JRebel's Stripes plugin enabled test.jsp takes some 1 minute to load. While waiting for it to load, I open another browser tab and do a bit of browsing around. That would trigger the error about 50% of the time. Sometime the error will be with test.jsp, sometime the error will occur at the other page that I was browsing. There is a bug in JRebel definitely. But I am not sure whether the JRebel bug is causing the ConcurrentModificationException - or it is causing a bug in Stripes to surface. I am using the Eclipse Helios SR1. JRebel plugin was updated to the most recent version. Cheers, Yee Below is the stack trace (with test.jsp). Feb 10, 2011 2:00:21 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.util.ConcurrentModificationException at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100) at java.util.TreeMap$EntryIterator.next(TreeMap.java:1136) at java.util.TreeMap$EntryIterator.next(TreeMap.java:1131) at net.sourceforge.stripes.controller.UrlBindingFactory.getBindingPrototype(Url BindingFactory.java:132) at net.sourceforge.stripes.controller.AnnotatedClassActionResolver.getUrlBindin gFromPath(AnnotatedClassActionResolver.java:198) at net.sourceforge.stripes.tag.FormTag.getActionBeanUrlBinding(FormTag.java:100 ) at net.sourceforge.stripes.tag.FormTag.getActionBean(FormTag.java:376) at net.sourceforge.stripes.tag.InputTagSupport.getActionBean(InputTagSupport.ja va:392) at net.sourceforge.stripes.tag.InputTagSupport.loadErrors(InputTagSupport.java: 350) at net.sourceforge.stripes.tag.InputTagSupport.getFieldErrors(InputTagSupport.j ava:366) at net.sourceforge.stripes.tag.InputTagSupport.doStartTag(InputTagSupport.java: 409) at net.sourceforge.stripes.tag.InputOptionsCollectionTag.doEndTag(InputOptionsC ollectionTag.java:322) at org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspx_meth_stripes_005foptions _002dcollection_005f0(test_jsp.java:229) at org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspx_meth_stripes_005fselect_ 005f0(test_jsp.java:187) at org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspx_meth_stripes_005fform_00 5f0(test_jsp.java:136) at org.apache.jsp.WEB_002dINF.jsp.admin.test_jsp._jspService(test_jsp.java:94) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3 86) at org.apache.jasper.servlet.JspServlet._serviceJspFile(JspServlet.java:313) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher. java:646) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDis patcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch er.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher .java:302) at net.sourceforge.stripes.action.ForwardResolution.execute(ForwardResolution.j ava:110) at net.sourceforge.stripes.controller.DispatcherHelper$7.intercept(DispatcherHe lper.java:508) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext .java:158) at net.sourceforge.stripes.controller.HttpCacheInterceptor.intercept(HttpCacheI nterceptor.java:99) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext .java:155) at net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(Be foreAfterMethodInterceptor.java:113) at net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext .java:155) at net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.ja va:74) at net.sourceforge.stripes.controller.DispatcherHelper.executeResolution(Dispat cherHelper.java:502) at
Re: [Stripes-users] UTF8 from form to mySQL
Janne, Just curious why the need for the filter assuming all your requests go through Stripes. Do you have other non-Stripe traffic or perhaps the filter does other things as well. If not, the Stripes code is pretty clear... it effectively invokes exactly what your filter does... just curious what the benefit is... b/c I don't see the point and another filter... no matter how marginal the code is... is going to impact performance / scalability / resources unnecessarily... . No? Also, the OP wanted to know how to enable UTF-8 all the way to the DB... so it wasn't how many ways you could do this... so again I don't see the point about doing this in an interceptor... but sure if Stripes didn't have built-in support... I would consider a filter or interceptor but the case is moot IMO. Rather my point was about having missed including this in the list of things I did to enable UTF-8 support in reply to the OP. Cheers, --Nikolaos Janne Jalkanen wrote: Basically, in addition to the other things I mentioned there indeed is one Stripes configuration that I set... by creating a custom LocalePicker subclass that picks the character encoding UTF-8... and dropping it the configured Stripes extensions folder... the relevant code is as follows: Ah, ok, thanks for the tip. I still don't mind putting in the extra filter, since all my projects seem to have a ton of them anyway, and dropping in one extra line isn't much bother :-) I imagine one could also put in a custom Interceptor, if we're in the process of listing different ways of enabling UTF-8 :-D /Janne -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Janne and Samuel,
Ok... I think there are some things that need to be clarified... b/c it
was a while since I set this up in Stripes... I hadn't realized I even
set it up.
Technically speaking yes - you are both correct -
request.setCharacterEncoding(UTF-8) is required and should be
performed if you are doing UTF-8 with a simple Servlet. However, as
StripesFilter is already in place one would hope you wouldn't have to
wrap yet another Servlet filter around it and clearly you don't.
Basically, in addition to the other things I mentioned there indeed is
one Stripes configuration that I set... by creating a custom
LocalePicker subclass that picks the character encoding UTF-8... and
dropping it the configured Stripes extensions folder... the relevant
code is as follows:
public class MyLocalePicker implements LocalePicker {
...
@Override
public final String pickCharacterEncoding(HttpServletRequest
request, Locale locale) {
return (UTF-8);
}
}
And voila... all is well... and NO need for your additional Stripes
wrapper... why b/c the StripesFilter performs the following:
*String encoding =
this.configuration.getLocalePicker().pickCharacterEncoding(httpRequest,
locale);*
*if (encoding != null) {*
*httpRequest.setCharacterEncoding(encoding);*
log.debug(LocalePicker selected character encoding:
, encoding);
}
else {
log.debug(LocalePicker did not pick a character
encoding, using default: ,
httpRequest.getCharacterEncoding());
}
So, in fact we are golden via simple Stripes configuration vs. wrapping
a custom filter around the Stripes filter.
I had done this so long ago that I forgot I even did it. And yes,
technically the web browser should adhere to what its asked to use as
the encoding and sure older web browsers may have issues - problem is
what older means today is very unclear - so I agree this needs to be
done but let Stripes do it for you.
So the above should be added to my previous list :-)
Cheers,
--Nikolaos
Samuel Santos wrote:
Hi Daniil,
I've an old post about this topic at
http://www.samaxes.com/2006/12/java-and-utf-8-encoding/.
Hope it helps,
--
Samuel Santos
http://www.samaxes.com/
On Sat, Feb 5, 2011 at 8:16 AM, Janne Jalkanen
janne.jalka...@ecyrd.com mailto:janne.jalka...@ecyrd.com wrote:
Really??? A filter just to set character encoding??? Although I
imagine it would work isn't that a little sledge hammer-ish ;-)
I seem to recall it was the recommended practice.
Why not just put the following at the top of each of your JSPs
(or tweak as necessary):
%@ page language=java pageEncoding=UTF-8
contentType=text/html;charset=UTF-8 %
That will ensure your web page supports UTF-8.
No, it will just ensure that it outputs UTF-8; it does not say
anything about incoming request (which is what the
request.setCharacterEncoding() does.)
As far as Stripes is concerned you don't have to do anything for
it to support UTF-8... and Java retains all Strings in unicode so
no issue there either.
The problem stems from the fact that servlet spec says that the
default input encoding is ISO-8859-1. Especially older browsers do
not send the character encoding correctly, so you're better off
declaring the input encoding explicitly.
Please see Servlet specification version 2.5 Section SRV.3.9.
/Janne
--
The modern datacenter depends on network connectivity to access
resources
and provide services. The best practices for maximizing a physical
server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
mailto:Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] UTF8 from form to mySQL
Hey Samuel,
Samuel Santos wrote:
Hi Nikolaos,
My post was about Java EE in general and not about Stripes.
This mailing list is about Stripes not Java EE in general :-)
Sorry - couldn't resist - just joking with you :-)
But the OP was asking about UTF-8 with Stripes et al. and both Janne and
yourself made similar suggestions on writing custom filters which may
have been required once upon a time... and are definitely necessary if
you aren't using a web framework... but alas with Stripes are not required.
With Stripes, a custom LocalePicker implementation will correctly
encode POST parameters, but you still need to add the
URIEncoding=UTF-8 attribute to your connector configuration.
Two points here:
1) So... NOT everyone uses Tomcat... :-)
2) Incorrect on the POST comment. At least this is NOT an issue with
Glassfish v3 Final. Just tried the following and it worked fine:
http://www.local.ca:8080/ui-web/share/0/_?share.title=añadir un
título2share.brief=Increíble cómo las tortugas tienen un caparazón
brillante2share.modalityId=4001yes=tokenKeyTx=91db-25589690015563216-15nshrujm_sourcePage=vyJcD4BNJr9bCdvaD2RrnYpK04x6-Fot2_8vpBg6sVYHirKBhFKwog==__fp=vOPWJM_CB9-OCPxksbAYdekxq1M95vdE
Which resulted in this output:
We successfully added this new Share.
añadir un título2
Increíble cómo las tortugas tienen un caparazón brillante2
The output involves submitting Form via GET to add a share and persist
it in DB and then redirecting to the view handler that loads the share
and presents it from the DB.
Essentially demonstrating UTF-8 support through all the layers
Again, this doesn't mean that Tomcat doesn't have the issue that you
suggest it has with GET data but it clearly isn't something one needs to
add if they are using GlassFish v3 Final... who knows about other web
containers... .
--Nikolaos
Cheers,
--
Samuel Santos
http://www.samaxes.com/
On Sun, Feb 6, 2011 at 3:11 AM, Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org wrote:
Janne and Samuel,
Ok... I think there are some things that need to be clarified...
b/c it was a while since I set this up in Stripes... I hadn't
realized I even set it up.
Technically speaking yes - you are both correct -
request.setCharacterEncoding(UTF-8) is required and should be
performed if you are doing UTF-8 with a simple Servlet. However,
as StripesFilter is already in place one would hope you wouldn't
have to wrap yet another Servlet filter around it and clearly you
don't.
Basically, in addition to the other things I mentioned there
indeed is one Stripes configuration that I set... by creating a
custom LocalePicker subclass that picks the character encoding
UTF-8... and dropping it the configured Stripes extensions
folder... the relevant code is as follows:
public class MyLocalePicker implements LocalePicker {
...
@Override
public final String pickCharacterEncoding(HttpServletRequest
request, Locale locale) {
return (UTF-8);
}
}
And voila... all is well... and NO need for your additional
Stripes wrapper... why b/c the StripesFilter performs the following:
*String encoding =
this.configuration.getLocalePicker().pickCharacterEncoding(httpRequest,
locale);*
*if (encoding != null) {*
*httpRequest.setCharacterEncoding(encoding);*
log.debug(LocalePicker selected character
encoding: , encoding);
}
else {
log.debug(LocalePicker did not pick a
character encoding, using default: ,
httpRequest.getCharacterEncoding());
}
So, in fact we are golden via simple Stripes configuration vs.
wrapping a custom filter around the Stripes filter.
I had done this so long ago that I forgot I even did it. And yes,
technically the web browser should adhere to what its asked to use
as the encoding and sure older web browsers may have issues -
problem is what older means today is very unclear - so I agree
this needs to be done but let Stripes do it for you.
So the above should be added to my previous list :-)
Cheers,
--Nikolaos
Samuel Santos wrote:
Hi Daniil,
I've an old post about this topic at
http://www.samaxes.com/2006/12/java-and-utf-8-encoding/.
Hope it helps,
--
Samuel Santos
http://www.samaxes.com/
On Sat, Feb 5, 2011 at 8:16 AM, Janne Jalkanen
janne.jalka...@ecyrd.com mailto:janne.jalka...@ecyrd.com wrote:
Really??? A filter just to set character encoding???
Although I imagine it would work isn't that a little sledge
hammer-ish ;-)
I seem to recall it was the recommended practice.
Why not just put the following at the top
Re: [Stripes-users] UTF8 from form to mySQL
Janne,
Really??? A filter just to set character encoding??? Although I
imagine it would work isn't that a little sledge hammer-ish ;-)
Why not just put the following at the top of each of your JSPs (or tweak
as necessary):
%@ page language=java pageEncoding=UTF-8
contentType=text/html;charset=UTF-8 %
That will ensure your web page supports UTF-8.
As far as Stripes is concerned you don't have to do anything for it to
support UTF-8... and Java retains all Strings in unicode so no issue
there either.
That leaves your MySQL database... and here I have found that I have
done multiple things and I'm sure I could trim this down but after
spending days on particular issues I just got fed up and set everything
I need to that I know will ensure things stay UTF-8... so be forewarned
this list should be able to be slimmed down and if you have the time to
test multiple scenarios then power to you ;-)
MySQL configuration (UTF-8 relevant pieces only...):
[mysqld]
skip-character-set-client-handshake
character-set-server=utf8
collation-server=utf8_general_ci
character_set_results=utf8
Starting MySQL (UTF-8 relevant pieces only...):
./bin/mysqld_safe --user=mysql --character-set-server=utf8
--collation-server=utf8_general_ci
And last but not least instead of trying to set the connection to UTF-8
we simply create a sub-classed dialect and set the table type AND
dialect in our Persistence.xml (we use JPA) as we really don't use
anything but InnoDB and UTF-8 in our databases:
public class UTF8MySQL5InnoDBDialect extends MySQL5InnoDBDialect {
public UTF8MySQL5InnoDBDialect() {
super();
}
public final String getTableTypeString() {
return ENGINE=InnoDB DEFAULT CHARSET=utf8;
}
}
Oh... and as a last warning if you are using an xterm then you'll be
able to see the characters in your DB properly but if you set the
encoding to UTF-8 (from its ASCII default) your going to see only
Latin-1 characters i.e. the spanish n is shown but not other non-Latin-1
characters. Screwy I know but caused a lot of grief.
So you have many suggestions... and feel free to pull the pieces from
other people's solutions that resonate better with you... but UTF-8
isn't really a Stripes problem per se because Java's unicode support
really makes localization within the webapp transparent... .
--Nikolaos
Janne Jalkanen wrote:
Simple solution: declare the accept-charset value on all your forms to be UTF-8 (and *only*
UTF-8), then put up a simple Filter in front of your chain which says
request.setCharacterEncoding(UTF-8). This should ensure that you get full unicodes to
the ActionBean, and then you only have to deal with your DB encodings.
Works for me well.
/Janne
On 4 Feb 2011, at 22:45, Daniil Sosonkin wrote:
Hi there,
So I'm sure there's someone out there who has met this problem and has found a
solution, therefore, let me ask the source. We are dealing with an
international web platform - many many languages. People submit forms in
different languages and it all stored in a mySQL database. Basically, I'm
having troubles getting UTF8 to work with said database. I have troubles at all
levels - stripes and database.
Here's my set up:
- mySQL 5.1
- mysql-jdbc 5.1 (driver)
- tables - utf8
- LocalePicker is always forcing charset to UTF-8 in stripes
Here's the problem:
- User enters some characters into the form (chinese, russian, hebrew)
- ActionBean sticks it into the database and sends email.
- Fields are declared as Strings and nothing is done to the values
- When sticking to the database it will contain - as values
- The output from the database obviously doesn't work
- When printing submitted value on page from ${actionBean.field} it displays
junk
I know that browsers send all forms to the servers in ISO-8859-1 encoding. In the good old days, or
with plain servlets, I would always have to convert submitted values to UTF-8 with the following:
new String(rs.getString(1).getBytes(ISO-8859-1), UTF-8); From then on the
value is in UTF-8
In Stripes, I think that the values come to ActionBeans in ISO-8859-1 since
StringTypeConverter doesn't do anything. That's fine, I wrote my own converter
for UTF using the logic from above. This solves the problem with printing
submitted value on the page ${actionBean.field}; but if the value is still
displayed in the form it is all grumbled as if it was ISO-8859-1 representation
of UTF-8. That I don't understand.
As for storing UTF8 into mySQL - well, if someone can help me out it would be
great since I can't get UTF8 string stored in the database without doing the
UTF8 to ISO-8859-1 and back conversion while keeping tables at latin1 I would
really appreciate it. The main question is Stripes.
I hope this whole rambling makes sense and someone has had this problem
previously. Hopefully there was a solution.
Sincerely,
Daniil
Re: [Stripes-users] Clean URLs failing on form post
William,
Sure, you could definitely come up with many ways to hit this particular
issue... and I won't refute that... . In fact, I wasn't even aware of it
in the 1st place and I Thank You for sharing it with the community.
But, again I would never see it because any web app I build
essentially has WebRoot that looks like this:
/css
/img
/js
/WEB-INF
Not sure if this is explicit best practice but if it isn't it sure might
be implicit best practice as many a web app are built this way.
ASIDE: I say essentially b/c we in fact have a structure that starts
with /static/__ID/[css|img|js] and when we release __ID is the release
version and we set the expires for everything under /static to 1 year
and we will run it through a CDN... but that is all another story
altogether and I guess the only worry I could have is if I had a URL
binding that started with /static/ so thanks for the heads up... .
So in your case I would have:
/images
/jobs
/add-icon.png
/del-icon.png
/css
/edit.css
/WEB-INF
/jsp
/jobs
/edit.jsp
/list.jsp
And there are NUMEROUS intrinsic design benefits here as:
- you get fewer top level folders... easier to manage... yes you could
make the argument that having things dissected by business area /
ActionBean is easier to manage but I think if you try this you might see
what I am talking about... .
- all your images, css and js are rooted under 1 respective folder and
easily zipped, replaced, scanned, etc...
- do you really have a different edit.css file for different business
areas / ActionBeans?
- when / if you add JS do you really have a different JS file for
different business areas / ActionBeans?
- having fewer css / JS files takes advantage of web browser caching,
limits the cost of the network trip hit, etc...
- and I can go on and on... but now we are talking about Application
Design... and grey areas... and are off topic... .
Does this not address your problem / the bug you found?
--Nikolaos
Rose William wrote:
Hi Nikolaos,
It probably is!
In my case, the only thing in my folder structure was JSPs, so moving
them to some other folder structure would fix the issue.
More generally, though, I thought that part of the magic of
DynamicMappingFilter was supposed to be that one could have one's action
beans appearing to share the same folders as their resources (e.g. CSS,
JS, images) and so it ought not matter that the JSPs were there too.
Let's say I rearranged my JSPs, but also added some extra graphics and
stylesheets:
/jobs
/images
/add-icon.png
/del-icon.png
/css
/edit.css
/WEB-INF
/jsp
/jobs
/edit.jsp
/list.jsp
I still have the same problem with Tomcat adding a / to
/contextPath/jobs, despite following best practice for placement of
JSPs.
Kind regards,
William Rose
Business Intelligence Team Leader
Information Management
+61 3 9656 5231 | Level 8, St Andrews Place, East Melbourne VIC 3002
-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org]
Sent: Thursday, 3 February 2011 2:11 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post
William,
Isn't it best practice to place ones JSPs rooted under /WEB-INF. This
ensures that your JSPs are never directly accessible from the outside
while still allowing your ActionBean's to forward to them.
If you followed this then Tomcat nor any other Web Container would
succeed in placing a slash and matching your JSP structure.
Or am I missing something...?
--Nikoloas
Rose William wrote:
Hi there,
I found the recent discussion on the mailing list about clean URLs
seemingly failing to find the right event handler when a form is
POSTed, and saw a variety of solutions to creating the URL oneself.
After trying to debug the same issue myself, I think the reason for
this behaviour is tied up in Tomcat bug 32424 (see
https://issues.apache.org/bugzilla/show_bug.cgi?id=32424).
My web app is set up with DynamicMappingFilter applied to /*.
I have a WEB directory structure like this:
/jobs
/edit.jsp
/list.jsp
I have an action bean annotated like this:
@UrlBinding(/jobs/{$event}/{fullName})
There is a list event, new event and save event:
//@DefaultHandler
@DontBind
@HandlesEvent(list)
public Resolution list() throws SchedulerException {
s_log.debug(in list());
return new ForwardResolution(/jobs/list.jsp);
}
@HandlesEvent(new)
@DontValidate
public Resolution newJob() throws SchedulerException {
s_log.debug(in newJob());
return new ForwardResolution(/jobs/edit.jsp);
}
@HandlesEvent(save)
public Resolution saveJob() throws SchedulerException
Re: [Stripes-users] HTTPS to HTTP switching
really agree that if you secure the site with a login that everything should be secure. Digg, for example, doesn't need to encrypt its news feed after you login because the information is not sensitive.Many sites I've seen have non-secure content after logging in. Was hoping there was an easy way to do it in Stripes but I guess not. On Mon, Jan 31, 2011 at 10:19 AM, Stone, Timothy tst...@barclaycardus.com mailto:tst...@barclaycardus.com wrote: Couldn't this use case also be addressed with OAuth? Where the Auth is performed over OAuth, but the site remains over HTTP (non-secure). I do agree 100% with Janne though, HTTPS is cheap. If the username/password, and the services provided by the webapp should be secure, make it secure 100% of the time, e.g., redirect to HTTPS immediately on hitting the site. Regards, Tim -Original Message- From: Janne Jalkanen [mailto:janne.jalka...@ecyrd.com mailto:janne.jalka...@ecyrd.com] Sent: Monday, January 31, 2011 9:48 AM To: Stripes Users List Subject: Re: [Stripes-users] HTTPS to HTTP switching 1) Logging in. The login action should be https so username and password are encrypted, but once i pass the login, the first page the user sees does not need to be secure, hence switching from https to http And that's exactly when your site stops being secure, and the user session can be hijacked, and your site is compromised. Facebook does login over https, yet the sessions can be hijacked. That's why they're rolling out the change... Please *do* seriously consider using https all the way after the user has logged in. You have very few real reasons why you shouldn't - https is very cheap these days with SSL-terminating loadbalancers and plenty-of-CPU power for decryption anyway. You're otherwise creating a fairly easy-to-exploit security hole in your system... (unless, of course, you can ensure that nobody ever uses your system over WiFi.) /Janne -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users Barclays www.barclaycardus.com http://www.barclaycardus.com This e-mail and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director of Information Technology BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free
Re: [Stripes-users] MockRoundtrip:: 2-Round Trips / Conversation:: How???
Never mind... I simply used 2 back-to-back MockRountrip's... and re-used
the context and session created from the 1st trip in the 2nd trip.
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
Perhaps I am pushing the envelope with MockRoundtrip however what I
would like to be able to do is the following integration tests:
(1) Execute a request based on URL and have MockRoundtrip invoke the
appropriate event handler and do whatever bean logic
e.g. @UrlBinding(/share/{uuidRadix}/{titleUrlified}/{$event})
In my test I do the following:
session = new MockHttpSession(context);
trip = new MockRoundtrip(context, /share/3gi/_/edit, session);
trip.execute();
actionBean = (BaseActionBean) trip.getActionBean(actionBeanClass);
And all is well... in that the ActionBean has a Share loaded from the DB
(2) I want to now simulate a form post to this ActionBean to say make
changes to the Share and then verify they were committed to the DB.
The problem is if I do MockRoundtrip again with the appropriate URL or
even ActionBean class it will create a NEW ActionBean and process the
request. That is obviously pointless. But if I try to re-use the
MockRoundtrip attempting to try execute(save) results in an error
(understandable).
So how does one use MockRoundtrip to do:
(A) Execute initial request... get a bean, state, etc...
(B) Execute say a Save request... using the previously loaded bean,
state, etc...
I looked at extending MockRoundtrip but am unsure where to hook in to
supply my ActionBean created in (A) when invoking execute(save) is
done in (B).
I would imagine someone has done this before.
Thanks,
--Nikolaos
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Nikolaos Giannopoulos
Director of Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] MockRoundtrip:: 2-Round Trips / Conversation:: How???
Hi,
Perhaps I am pushing the envelope with MockRoundtrip however what I
would like to be able to do is the following integration tests:
(1) Execute a request based on URL and have MockRoundtrip invoke the
appropriate event handler and do whatever bean logic
e.g. @UrlBinding(/share/{uuidRadix}/{titleUrlified}/{$event})
In my test I do the following:
session = new MockHttpSession(context);
trip = new MockRoundtrip(context, /share/3gi/_/edit, session);
trip.execute();
actionBean = (BaseActionBean) trip.getActionBean(actionBeanClass);
And all is well... in that the ActionBean has a Share loaded from the DB
(2) I want to now simulate a form post to this ActionBean to say make
changes to the Share and then verify they were committed to the DB.
The problem is if I do MockRoundtrip again with the appropriate URL or
even ActionBean class it will create a NEW ActionBean and process the
request. That is obviously pointless. But if I try to re-use the
MockRoundtrip attempting to try execute(save) results in an error
(understandable).
So how does one use MockRoundtrip to do:
(A) Execute initial request... get a bean, state, etc...
(B) Execute say a Save request... using the previously loaded bean,
state, etc...
I looked at extending MockRoundtrip but am unsure where to hook in to
supply my ActionBean created in (A) when invoking execute(save) is
done in (B).
I would imagine someone has done this before.
Thanks,
--Nikolaos
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes forms and Clean Url binding?
Karen,
Then yes you appear to have an issue with the generated Action value...
but I'm reaching here and curious as to why you have:
@URLBinding(/user/{username*=*}/profile.html
and not:
@URLBinding(/user/{username}/profile.html
That = would at least make me think the default value for username is
blank... perhaps its causing a weird side effect.
Not sure if this is your issue and if it isn't I still have the solution
I adopted which I can tell you about (I actually posted the solution but
under a slightly different subject heading Re: [Stripes-users] s:form
Localization Issue (SOLUTION) but I can explain it better).
Cheers,
--Nikolaos
Karen wrote:
Nikolaos,
The problem I have is that I have parameterized pages that need to be both
SEO Friendly and updatable.
Action Bean:
@URLBinding(/user/{username=}/profile.html)
Example URL:
/user/jane/profile.html
But stripes:form will generate this URL for it:
/user//profile.html
But it needs to be:
/user/jane/profile.html
This might be due to legacy code based on the fact that mixing GET
parameters in the URL with a POST parameters is not allowed. But this
limitation should not apply to the URL's we generate with @URLBindings.
-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org]
Sent: Wednesday, 26 January, 2011 21:02
To: Karen
Cc: 'Stripes Users List'
Subject: Re: [Stripes-users] Stripes forms and Clean Url binding?
Karen,
My issue was with localization in that I needed a localized URI binding but
Stripes forced me to have one that it could resolve the URI to an
ActionBean.
But if I understand you correctly I'm not sure your case is an issue.
You don't want Stripes trying to plug in parameters like event for example
which may have multiple submit buttons e.g. Cancel and Continue.
And as far as the other parameters are concerned hidden form fields could
readily supply values back on form submit.
I for one am glad that Stripes puts little effort into determining this URL
because it offers full freedom within my form. Again my issue was w.r.t. to
localization which is another animal altogether.
Perhaps this is not what you are talking about... if so... then an example
might help ;-)
--Nikolaos
Karen wrote:
I like to follow-up on Nikolaos remarks about clean URLS and forms not
working as expected.
When using the stripes:form tag for action beans that have an
@URLBinding annotation with parameters, the stripes:form tag ignores
those parameters and thus generates an unexpected and incorrect form
action URL.
I'm under the impression that this could be fixed by altering the
'setBeanclass' and 'doStartTag' method on the
net.sourceforge.stripes.tag.FormTag class. If these methods became
aware of the parameter defined in the @URLBinding of the ActionBean it
would be possible to generate a complete URL. The parameter values
themselves could be 'get' from the current action bean by using the Java
reflection API.
This would of course only work when the action bean handling the form
forwards to the JSP with the form (MVC pattern). So we might want to
make this behavior optional.
Would this be a good solution to this problem?
-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org]
Sent: Saturday, 20 November, 2010 23:37
To: Stripes Users List
Subject: Re: [Stripes-users] Stripes forms and Clean Url binding?
Oops... was playing around with a number of solutions. This one won't
work because it didn't solve the fact that form action=/article is
unable to hit the @UrlBinding for the ArticleActionBean.
So far what appears to work is doing the following:
s:form action=${actionBean.formUrlBinding} method=POST
And then having on the action bean:
public String getFormUrlBinding() {
StringBuilder sb = new StringBuilder();
sb.append(/article/).append(this.authorId).append('/').append(this.i
d).app
end('/').append(this.titleUrlified);
return (sb.toString());
}
Still appears to be a hack as I am duplicating the @UrlBinding but at
least its encapsulated in the ActionBean... if that is any solace ;-)
Cheers,
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
So I figured out a solution to the problem:
s:hidden name=authorId/s:hidden s:hidden name=id/s:hidden
s:hidden name=titleUrlified/s:hidden
At first I thought it would be nice to force Stripes to build the
complete @UrlBinding i.e. it is already obviously consulting the
@UrlBinding to produce /article but understand why it isn't so.
Even in my case above I didn't want event to be the same so I guess
this offers the most flexibility... because how far do you go in
binding parameters is not black white.
Cheers,
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
We have the following Url binding:
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{$event})
And when we direct to the following url:
/web/articleadd
It does a ForwardResolution
Re: [Stripes-users] A question about the Stripes form variable int
Andres, IN general I find it is quite useful to avoid primitives for attributes exposed in Stripes forms... and instead use their object versions as Samuel pointed out... which has the nice effect of a blank form field converting to a null value vs. being set to a primitive default value like 0. IN this way by leveraging Objects null acts as if the user didn't supply a value which is very valuable... ;-) --Nikolaos Samuel Santos wrote: Hi Andres, Define your field type as integer instead of int. -- Samuel Santos http://www.samaxes.com/ On Wed, Jan 26, 2011 at 2:22 PM, andres ispanand...@yahoo.es mailto:ispanand...@yahoo.es wrote: A question about the Stripes form variable. I have declared price variable as a int in the class. In the jsp form stripes assigned to this field 0. My question is how to avoid it then appears 0 in the field? Thank you very much for answers. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director of Information Technology BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes forms and Clean Url binding?
Karen,
My issue was with localization in that I needed a localized URI binding
but Stripes forced me to have one that it could resolve the URI to an
ActionBean.
But if I understand you correctly I'm not sure your case is an issue.
You don't want Stripes trying to plug in parameters like event for
example which may have multiple submit buttons e.g. Cancel and Continue.
And as far as the other parameters are concerned hidden form fields
could readily supply values back on form submit.
I for one am glad that Stripes puts little effort into determining this
URL because it offers full freedom within my form. Again my issue was
w.r.t. to localization which is another animal altogether.
Perhaps this is not what you are talking about... if so... then an
example might help ;-)
--Nikolaos
Karen wrote:
I like to follow-up on Nikolaos remarks about clean URLS and forms not
working as expected.
When using the stripes:form tag for action beans that have an @URLBinding
annotation with parameters, the stripes:form tag ignores those parameters
and thus generates an unexpected and incorrect form action URL.
I'm under the impression that this could be fixed by altering the
'setBeanclass' and 'doStartTag' method on the
net.sourceforge.stripes.tag.FormTag class. If these methods became aware of
the parameter defined in the @URLBinding of the ActionBean it would be
possible to generate a complete URL. The parameter values themselves could
be 'get' from the current action bean by using the Java reflection API.
This would of course only work when the action bean handling the form
forwards to the JSP with the form (MVC pattern). So we might want to make
this behavior optional.
Would this be a good solution to this problem?
-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org]
Sent: Saturday, 20 November, 2010 23:37
To: Stripes Users List
Subject: Re: [Stripes-users] Stripes forms and Clean Url binding?
Oops... was playing around with a number of solutions. This one won't work
because it didn't solve the fact that form action=/article is unable to
hit the @UrlBinding for the ArticleActionBean.
So far what appears to work is doing the following:
s:form action=${actionBean.formUrlBinding} method=POST
And then having on the action bean:
public String getFormUrlBinding() {
StringBuilder sb = new StringBuilder();
sb.append(/article/).append(this.authorId).append('/').append(this.id).app
end('/').append(this.titleUrlified);
return (sb.toString());
}
Still appears to be a hack as I am duplicating the @UrlBinding but at least
its encapsulated in the ActionBean... if that is any solace ;-)
Cheers,
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
So I figured out a solution to the problem:
s:hidden name=authorId/s:hidden
s:hidden name=id/s:hidden
s:hidden name=titleUrlified/s:hidden
At first I thought it would be nice to force Stripes to build the
complete @UrlBinding i.e. it is already obviously consulting the
@UrlBinding to produce /article but understand why it isn't so. Even
in my case above I didn't want event to be the same so I guess this
offers the most flexibility... because how far do you go in binding
parameters is not black white.
Cheers,
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
We have the following Url binding:
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{$event})
And when we direct to the following url:
/web/articleadd
It does a ForwardResolution to a form which contains:
s:form
beanclass=org.test.ui.web.action.content.ArticleActionBean
method=POST
...
s:submit name=save /
s:submit name=cancel /
/s:form
However the HTML output is as follows:
form action=/web/article method=POST
...
input name=save value=Save type=submit /
input name=cancel value=Cancel type=submit /
/form
But the action =/web/article isn't sufficient to hit our Url
binding... when we click on the save or cancel buttons???
Am I missing something obvious like in the case of addParameter on
RedirectResolution?
Anyone?
--Nikolaos
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] MockRoundtrip:: trip.getActionBean() REALLY Odd Stripes Behaviour AND Worrisome
All,
This issue is very bizarre and VERY interesting indeed.
I run 2 identical TestNG tests in a unit test - back to back - and the
1st fails and the 2nd succeeds:
@DataProvider(name = userIssueRequests)
public Object[][] userIssueRequests() {
return new Object[][] {
*{ ShareActionBean.class, en_US, /share/3gi/_/edit,
/share/3gi/_/view },
{ ShareActionBean.class, en_US, /share/3gi/_/edit,
/share/3gi/_/view },*
};
}
ShareActionBean has the following URL binding:
@UrlBinding(/share/{uuidRadix}/{titleUrlified}/{$event})
And the following default handler:
@DefaultHandler
@DontValidate
public final Resolution view() {
return (super.view(VIEW));
}
The test involves the following (relevant) code:
MockRoundtrip trip = new MockRoundtrip(context, actionBeanUrl,
new MockHttpSession(context));
trip.execute();
ShareActionBean bean = *trip.getActionBean(ShareActionBean.class);*
In BOTH cases the ShareActionBean is created and the edit handler (as
per URL) is invoked. All is well... so far...
However, In the 1st run *bean* is NULL and in the 2nd run *bean*
returns the action bean that handled the request... HUH
So, I did some debugging... if we drill down into
trip.getActionBean(...) we find the following method:
public A extends ActionBean A getActionBean(ClassA type) {
*A bean = (A) this.request.getAttribute(getUrlBinding(type,
this.context));*
if (bean == null) {
bean = (A)
this.request.getSession().getAttribute(getUrlBinding(type, this.context));
}
return bean;
}
Here is where it gets REALLY interesting - if we simply focus on the 1st
line of the method call:
*A bean = (A) this.request.getAttribute(getUrlBinding(type,
this.context));*
We find that *getUrlBinding(type, this.context)* returns the
following as the key to the outer method call:
/share/{uuidRadix}/{titleUrlified}/{$event=view}
And in the 1st run *this.request.getAttribute(...) * has a map that
contains:
__stripes_resolved_action=*/share/{uuidRadix}/{titleUrlified}/{$event}*,
*/share/{uuidRadix}/{titleUrlified}/{$event}*=org.lightagents.ui.web.action.content.ShareActionBean@10fd9d27,
actionBean=org.lightagents.ui.web.action.content.ShareActionBean@10fd9d27,
__current_flash_scope=-1806527276,
_stripes_defaultMessages=[org.lightagents.ui.stripes.extended.LocalizableMessageWarning@779dc644]}
whereas in the 2nd run * this.request.getAttribute(...) * has a map
that contains:
__stripes_resolved_action=*/share/{uuidRadix}/{titleUrlified}/{$event=view}*,
*/share/{uuidRadix}/{titleUrlified}/{$event=view}*=org.lightagents.ui.web.action.content.ShareActionBean@44dd7637,
actionBean=org.lightagents.ui.web.action.content.ShareActionBean@44dd7637,
__current_flash_scope=-624278302,
_stripes_defaultMessages=[org.lightagents.ui.stripes.extended.LocalizableMessageWarning@779dc644]}
How can Stripes produce 2 different URL bindings for the same ActionBean
in the same run
This behaviour is not only odd but worrisome if there is a bug at work
here that may affect non-Test code.
Now what is more interesting is that the ShareActionBean is setup with
the Application logic such that if user is trying to change a Share that
they do not have access to that they are redirected to the default
handler with a message i.e.:
/share/3gi/_/view?__fsk=-1806527276
So we have the following things happening:
(A) Stripes UrlBinding's are determined when Stripes fires up and
receives an initial request. At this point the ShareActionBean is
referenced to have cached UrlBinding of:
/share/{uuidRadix}/{titleUrlified}/{$event}
(B) Run #1 - we test the request to */share/3gi/_/edit *and the
ShareActionBean edit event handler redirects to* /share* with
params *3gi* and *_* and as such no explicitly specified event
handler so the default one should be determined by Stripes.
But that causes UrlBindingParameter.getDefaultValue() to execute to
determine that the event value for this action bean is the
@DefaultHandler method view
At this point though this changes the UrlBinding component for
ShareActionBean to have event with defaultValue = view and moreover
the ShareActionBean cached UrlBinding from this point forward is:
/share/{uuidRadix}/{titleUrlified}/{$event=view}
(C) However when the trip.getActionBean(...) method fires a lookup for
the request attribute the key it got initially is used:
/share/{uuidRadix}/{titleUrlified}/{$event}
And of course this fails and no ActionBean is returned b/c this no
longer maps to any cached UrlBinding.
(D) When Run #2 comes along and does the same thing the same thing
occurs as in Run #1 except from the start this time though the cached
UrlBinding is:
/share/{uuidRadix}/{titleUrlified}/{$event=view}
And nothing changes and all is well in that the
trip.getActionBean(...) method return the ShareActionBean
Re: [Stripes-users] MockRoundTrip:: ActionBean Testing UrlBinding and ActionBeanContext
Thanks Janne! I wasn't readily aware of this option (think I need to
look closely at what other gifts are already in Stripes params :-)
stripesParams.put(
ActionBeanContext.Class,com.thinglink.site.util.web.TLActionBeanContext
);
BTW I'm curious... with your setup below your util package is a
sub-package of Extension.packages... does that mean that the above
ActionBeanContext.class param will override any possible
ActionBeanContext context subclass found when Stripes scans
Extension.packages?
i.e. say you had defined the following classes (1st one being Test and
the other being main non-Test):
com.thinglink.site.util.web.TLActionBeanContextTest
com.thinglink.site.util.web.TLActionBeanContext
And you had your setup below which specifically included:
stripesParams.put(
ActionBeanContext.Class,com.thinglink.site.util.web.TLActionBeanContextTest
);
...
stripesParams.put( Extension.Packages,com.thinglink.site );
Would Stripes favor TLActionBeanContextTest over TLActionBeanContext
for the ActionBeanContext???
I would assume it would the former but am curious if you OR anyone else
already knows... .
--Nikolaos
Janne Jalkanen wrote:
I'm using something like this to set up Stripes (JUnit 4, then use
standard MockRoundtrip()). You should be able to replace the
ActionBeanContext here
with whatever you like.
@BeforeClass
public static void mockUp()
{
MockServletContext context = new MockServletContext(test);
// Add the Stripes Filter
MapString,String stripesParams = new HashMapString,String();
stripesParams.put( ActionResolver.Packages, com.thinglink );
stripesParams.put(
ActionResolver.Class,com.thinglink.site.util.web.WebInfNameBasedActionResolver
);
stripesParams.put(
ActionBeanContext.Class,com.thinglink.site.util.web.TLActionBeanContext
);
stripesParams.put(
ExceptionHandler.Class,com.thinglink.site.util.web.TLExceptionHandler
);
stripesParams.put( Extension.Packages,com.thinglink.site );
stripesParams.put( LocalePicker.Locales,en,fi );
context.addFilter(StripesFilter.class, StripesFilter,
stripesParams);
// Add the Stripes Dispatcher
context.setServlet(DispatcherServlet.class,
StripesDispatcher, null);
m_context = context;
}
/Janne
On Jan 25, 2011, at 07:05 , Nikolaos Giannopoulos wrote:
Hi,
We have a typical superclass for our ActionBeans:
public abstract class BaseActionBean implements ActionBean {
...
protected MyActionBeanContext context;
public final MyActionBeanContext getContext() { return context; }
public final void setContext(ActionBeanContext context) {
this.context = (MyActionBeanContext) context;
}
Now, when we write our TestNG tests we do:
...
MockRoundtrip trip = new MockRoundtrip(context, /share/add/0/-/,
new MockHttpSession(context));
MockHttpServletRequest request = trip.getRequest();
trip.execute();
And everything works great... except I would like to set some values
on the ActionBean that Stripes finds and instantiates however it is
unclear how I would access the ActionBean context as trip.execute()
creates the ActionBean, sets the default context, and processes the
event handler. We obviously would need to set values on the
ActionBeanContext AFTER bean creation BUT BEFORE event handler is
processed e.g. set the logged in user on the ActionBeanContext.
Also it would be nice at times to replace the ActionBeanContext with
a test version as depicted in the Stripes Best Practices.
Sure its trivial if you don't care about UrlBinding to simply create
the appropriate bean, set the custom context and pass it to
MockRoundTrip however that bypasses an important stage that we need
to test and that is incoming localized / canonical urls (in essence
we are doing more end-to-end tests for our action beans i.e. start
with this URL and after execution end up with these messages, errors,
and destination URL).
Has anyone done this before? If not, anyone up to the challenge on
how to solve this?
Thanks,
--Nikolaos
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better
price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using
Re: [Stripes-users] MockRoundTrip:: ActionBean Testing UrlBinding and ActionBeanContext
Ben Gunter wrote: If I'm not mistaken, the question was if the ActionBeanContext.Class configuration parameter takes precedence over classpath scanning. The answer to that question is yes. This is true for all the various *.Class init-params. Yes - that was the question - and until your reply I thought wow Stripes should be smarter. Turns out it already is ;-) As Freddy pointed out, if more than one ActionBeanContext implementation is found in your extensions package(s) and you do not configure ActionBeanContext.Class in web.xml, then Stripes will throw an exception. That's quite understandable indeed. Thanks Ben and Freddy for that clarification and useful details. Cheers, --Nikolaos See BootstrapPropertyResolver.getClassProperty(String, Class) for the code: http://stripes.svn.sourceforge.net/viewvc/stripes/trunk/stripes/src/net/sourceforge/stripes/config/BootstrapPropertyResolver.java?revision=1336view=markup http://stripes.svn.sourceforge.net/viewvc/stripes/trunk/stripes/src/net/sourceforge/stripes/config/BootstrapPropertyResolver.java?revision=1336view=markup -Ben On Tue, Jan 25, 2011 at 9:22 AM, Freddy Daoud xf2...@fastmail.fm mailto:xf2...@fastmail.fm wrote: Nikolaos Giannopoulos nikolaos@... writes: Would Stripes favor TLActionBeanContextTest over TLActionBeanContext for the ActionBeanContext??? Hi Nikolaos, There is no favoring of one custom action bean context class over another. There should only be one, otherwise, Stripes will throw an exception on startup: Found too many classes implementing/extending ActionBeanContext Cheers, Freddy -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] MockRoundTrip:: ActionBean Testing UrlBinding and ActionBeanContext
Hi,
We have a typical superclass for our ActionBeans:
public abstract class BaseActionBean implements ActionBean {
...
protected MyActionBeanContext context;
public final MyActionBeanContext getContext() { return context; }
public final void setContext(ActionBeanContext context) {
this.context = (MyActionBeanContext) context;
}
Now, when we write our TestNG tests we do:
...
MockRoundtrip trip = new MockRoundtrip(context, /share/add/0/-/,
new MockHttpSession(context));
MockHttpServletRequest request = trip.getRequest();
trip.execute();
And everything works great... except I would like to set some values on
the ActionBean that Stripes finds and instantiates however it is unclear
how I would access the ActionBean context as trip.execute() creates the
ActionBean, sets the default context, and processes the event handler.
We obviously would need to set values on the ActionBeanContext AFTER
bean creation BUT BEFORE event handler is processed e.g. set the logged
in user on the ActionBeanContext.
Also it would be nice at times to replace the ActionBeanContext with a
test version as depicted in the Stripes Best Practices.
Sure its trivial if you don't care about UrlBinding to simply create the
appropriate bean, set the custom context and pass it to MockRoundTrip
however that bypasses an important stage that we need to test and that
is incoming localized / canonical urls (in essence we are doing more
end-to-end tests for our action beans i.e. start with this URL and after
execution end up with these messages, errors, and destination URL).
Has anyone done this before? If not, anyone up to the challenge on how
to solve this?
Thanks,
--Nikolaos
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] MockRoundTrip:: ActionBean Testing UrlBinding and ActionBeanContext
Partially solved... obvious that if MyActionBeanContext interacts with
session then one can set directly on MockHttpSession e.g.
request.getSession().setAttribute(MyActionBeanContext.SESSION_USER, user);
However, still curious on how to replace MyActionBeanContext with a test
one...
Perhaps as I setup my own Stripes extensions packages path in a Test
Fixture I could prefix the paths with a package specifically for testing.
Q: Does Stripes use classes it finds in the Stripes extensions packages
path in first come first serve basis? i.e. if we have say 6 classes in
our extensions package which includes MyActionBeanContext... if I prefix
the extensions path with the package that has MyActionBeanContextTest...
will Stripes happily only pick up and use MyActionBeanContextTest and
ignore MyActionBeanContext which is found in a later package path segment???
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
We have a typical superclass for our ActionBeans:
public abstract class BaseActionBean implements ActionBean {
...
protected MyActionBeanContext context;
public final MyActionBeanContext getContext() { return context; }
public final void setContext(ActionBeanContext context) {
this.context = (MyActionBeanContext) context;
}
Now, when we write our TestNG tests we do:
...
MockRoundtrip trip = new MockRoundtrip(context, /share/add/0/-/,
new MockHttpSession(context));
MockHttpServletRequest request = trip.getRequest();
trip.execute();
And everything works great... except I would like to set some values
on the ActionBean that Stripes finds and instantiates however it is
unclear how I would access the ActionBean context as trip.execute()
creates the ActionBean, sets the default context, and processes the
event handler. We obviously would need to set values on the
ActionBeanContext AFTER bean creation BUT BEFORE event handler is
processed e.g. set the logged in user on the ActionBeanContext.
Also it would be nice at times to replace the ActionBeanContext with a
test version as depicted in the Stripes Best Practices.
Sure its trivial if you don't care about UrlBinding to simply create
the appropriate bean, set the custom context and pass it to
MockRoundTrip however that bypasses an important stage that we need to
test and that is incoming localized / canonical urls (in essence we
are doing more end-to-end tests for our action beans i.e. start with
this URL and after execution end up with these messages, errors, and
destination URL).
Has anyone done this before? If not, anyone up to the challenge on
how to solve this?
Thanks,
--Nikolaos
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Question about Stripes form
Andres,
That is exactly what we do... i.e. a skeleton class subclass of
BeanFirstPopulationStrategy
However, I wasn't previously aware of the web.xml init parameter:
init-param
param-namePopulationStrategy.Class/param-name
param-valuenet.sourceforge.stripes.tag.BeanFirstPopulationStrategy/param-value
/init-param
... that appears to accomplishes the same thing and for me at least is
MUCH more explicit.
i.e. I really like the way Stripes picks up everything in an extensions
folder but the above option for me at least makes it clear to new
programmers that this option is explicitly different from its default.
Thanks Ben.
--Nikolaos
andres wrote:
I know how to do it. For those who find the same problem the solution is.
You have to create (on stripes package extensions) class
your package ...
public class MyPopulationStrategy extends BeanFirstPopulationStrategy{
}
As it stands, empty...
And it work perfect, Stripes is a very good framework!
Thanks to Ben Gunter suggested to me.
Greetings to everyone.
--- El *sáb, 22/1/11, andres /ispanand...@yahoo.es/* escribió:
De: andres ispanand...@yahoo.es
Asunto: Re: [Stripes-users] Question about Stripes form
Para: Stripes Users List stripes-users@lists.sourceforge.net
Fecha: sábado, 22 de enero, 2011 21:27
Thank you very much my friend for the answer, I'll see it.
--- El *sáb, 22/1/11, Ben Gunter /gunter...@gmail.com/* escribió:
De: Ben Gunter gunter...@gmail.com
Asunto: Re: [Stripes-users] Question about Stripes form
Para: Stripes Users List stripes-users@lists.sourceforge.net
Fecha: sábado, 22 de enero, 2011 17:34
Form inputs are populated by the PopulationStrategy.
DefaultPopulationStrategy, which you are probably using right
now, populates an input's value first from a request parameter
having the same name as the input, if any, then from the
(nested) property of the form's ActionBean, and finally from
the value attribute.
You can change to BeanFirstPopulationStrategy to reverse the
first two. That is, the value will be pulled first from the
ActionBean property then from the request parameter then from
the value attribute. To switch the whole application to
bean-first, add the following to your StripesFilter configuration:
init-param
param-namePopulationStrategy.Class/param-name
param-valuenet.sourceforge.stripes.tag.BeanFirstPopulationStrategy/param-value
/init-param
In my opinion, the default strategy is the better one.
Bean-first can be useful sometimes, as in this case. Ideally,
one would be able to switch between the two as needed. Such a
strategy is described here
http://www.stripesframework.org/display/stripes/Overriding+PopulationStrategy+per+ActionBean
-Ben
On Sat, Jan 22, 2011 at 2:54 AM, andres ispanand...@yahoo.es
wrote:
Hello everyone.
I have a question about Stripes form.
I want to change hidden value in the form from action, but
Stripes do not want to do it.
My form
action=/Test/newSearch s:form method=post
name=item s:hidden value=${item}/
name=item.filterText s:text
value=${actionBean.item.filterText} / s: text
! - not does change the value (my problem here) -
name=item.filterPageIndex s:hidden
value=${actionBean.item.filterPageIndex}
id=filterPageIndex / s: hidden
! - value was changed and Can Be viewed with c: out -
c:out value=${actionBean.item.filterPageIndex} / c: out
class=buttons s:submit title=Search name=
value=Search/
/ s: form
ActionBean
.
ItemVO private item;
ItemVO public getItem () {
return item;
}
public void setItem (ItemVO item) {
this.item = item;
}
Resolution newSearch public () {
/ / print form input values
log.debug (filterText text + getItem (). getFilterText ());
log.debug (filterPageIndex value + getItem ().
getFilterPageIndex ());
/ / change form hidden value (I want to change hidden value)
getItem().setFilterPageIndex (1);
return new ForwardResolution (/ jsp / test.jsp);
}
Value received from action was changed, my question is why
Stripes did not change hidden field? I've done something
wrong?
Thank you very much.
--
Special Offer-- Download ArcSight Logger for FREE (a $49
USD value)!
Re: [Stripes-users] s:form Localization Issue (SOLUTION)
Turns out that what I set out to do in solution #3 in fact was quite
simple and appears to work well.
For anyone interested here is what it involves:
1) Create a class that extends the Stripes FormTag... and when building
the action simply uses the overrideUrl attribute - if set - and still
does all the normal Action Bean binding...
public class *FormTag* extends *net.sourceforge.stripes.tag.FormTag *{
private String overrideUrl = null;
public void setOverrideUrl(String overrideUrl) { this.overrideUrl =
overrideUrl; }
public String getOverrideUrl() { return overrideUrl; }
@Override
protected String buildAction() {
String action = null;
if ((this.overrideUrl != null) (this.overrideUrl.length() 0)) {
action = this.overrideUrl;
HttpServletResponse response = (HttpServletResponse)
getPageContext().getResponse();
return response.encodeURL(action);
}
else {
action = super.buildAction();
return action;
}
}
}
2) Copy FormTag TLD definition to your projects TLD definition AND add
an optional overrideUrl attribute definition
3) Switch from using the stripes Form tag to your projects Form tag AND
add the beanclass and overrideUrl attributes e.g.:
*a:form*
beanclass=org.test.ui.web.action.content.ShareActionBean*
overrideUrl=${actionBean.formPostUrlBinding}* method=POST
...
*/a:form*
Enjoy.
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi all,
I explored work around *Solution #1* (see e-mail below) which
essentially is the simplified code:
s:form class=x-form
action=*${actionBean.formPostUrlBinding}* method=POST
...
s:hidden name=*toUrl* /
...
/s:form
Such that it produces the following simplified snippet:
form action=*/ui-web/share/0/_* class=x-form
method=POST
...
input name=toUrl
value=*/ui-web/compartir/0/_/anadir* type=hidden /
...
/form
And Stripes is happy with the binding HOWEVER upon massaging the
source page / resolution it became obvious that as the user posts to:
/ui-web/share/0/_
if a validation error occurs I would need to do a
*RedirectResolution* vs. Stripes current *ForwardResolution* to
get the user back to:
/ui-web/compartir/0/_
This NOW produces other grief... such as the fact that on Redirect
Stripes does not maintain the errors (but does maintain messages) so
now I would have to augment the redirect mechanism to use the flash
scope to maintain errors on top of having the user POST a
non-localized URL and do redirects... this is getting uglier by the
minute... .
So it appears I am damned if I do and damned if I don't... damned if I
appease Stripes... i.e. damned if I don't appease Stripes as it works
against the Stripes grain... .
*Solution #2 *outlined in the e-mail below - while it would work and
is in Freddy's book is simply totally backwards as it hard codes
localization back into the classes of the app which defeats the
abstraction / separation of localization from code and defeats the
entire purpose of all the localization that was built with
UrlRewriterFilter and resource bundles... .
*Solution #3* (just thought of) is something I am going to try next...
HACK Stripes form tag to accept an overrideUri attribute such that
it can do all the lovely binding stuff it wants to but the URI that
gets populated in the action will be the contents of overrideUri
IFF specified (thus keeping things backwards compatible). I would
also use beanclass to help Stripes point to the ActionBean. So in
the end, let Stripes do its magic just point the user back to some
other URI for the purposes of the action of the form. Fingers
crossed... .
Stay tuned... .
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
*/_Setup:_/
*
- ShareActionBean with
@UrlBinding(*/share/*{uuidRadix}/{titleUrlified}/{$event})
- UrlRewriteFilter that pre-processes requests and maps say the
Spanish URL:
*/compartir/0/_/anadir* == */share/0/_/add*
/_*Flow:*_/
- User request: */compartir/0/_/anadir*
- UrlRewriteFilter forwards to: */share/0/_/add*
- ShareActionBean event handler simply does:
return (new*
ForwardResolution*(/WEB-INF/jsp/content/*share_form.jsp*));
- *share_form.jsp* relevant snippet contains:
*s:form* *action=${actionBean.formUrlBinding}* method=POST
s:text name=share.title /
s:hidden name=*tokenKeyTx* /
s:submit name=yes /s:submit name=no /
*/s:form*
- *${actionBean.formUrlBinding}* resolves to */compartir/0/_ *so
the form tag ends up looking like:
form action= */compartir/0/_* method=POST
input type=text name=share.title value= /
input type=hidden name=*tokenKeyTx* value= /
input type=submit name=yes value=yes /input
type=submit name=no value
[Stripes-users] Thoughts on Robust URL Localization in Stripes
Hi,
We essentially have tried very hard to abstract URL localization out of
Stripes and make it a veneer by using all of the following:
- UrlRewriteFilter w/ java class re-writers and hot reloadable resource
bundles
- An enhanced RedirectResolution (to support redirection to a localized URL)
- An enhanced Link tag (to produce a localized URL)
- An enhanced Form tag (to produce a localized action URL)
All of this appears to work but one more thing is missing. Say my
locale is en_CA and someone sends me a link to a Spanish URL. I click
on the link and go to the site and the system says ohhh... your locale
is en_CA therefore the canonical form of the URL is the same as the
incoming URL... ummm 404. Not good.
Solution #1: Add shell subclasses of existing Action Beans to support
all the localized @UrlBinding variants for each Action Bean ala Freddy's
book. As I mentioned before this approach did not bode well for the
fact that now localized strings were hardcoded into the code and not
entirely encapsulated in something external and reloadable like resource
bundles.
Solution #2: Add a mechanism that if Action Bean resolution fails
progress through each locale (other than the current) and attempt to
find a match to a URL binding and if so then forward to that Action
Bean... . I think this is the solution we are going to follow for now
as we have built all of the above already... BUT...
All this re-opens that can of worms of should the Stripes framework
know about localization or should it simply be a veneer?
And I am thinking that the recent Form tag issues it seems that Stripes
isn't happy if we try to blindly impose that veneer AND there is a lot
of hard work around Stripes to make that veneer work but it does require
a lot of plaster / filler.
So what to do... .
Solution #3: Augment Stripes to become more URL localization aware...
a) Come up with a new localization binding or possibly even an enhanced
version of the existing URL binding that say might have a binding
expressed as follows for example:
@UrlBinding(/[share]/{uuidRadix}/{titleUrlified}/[{$event}])
Where the [ and ] signal a localized key or variable that is looked up
in a property file and cached for each of the available locales:
localize.url.properties: locales=en,es
localize.url_en.properties:share=share
$event=view,add,edit,remove
localize.url_es.properties:share=compartir
$event=ver,anadir,editar,eliminar
So in this manner when Stripes processes the annotation it produces
multiple bindings, 1 per locale, per action bean and prioritized
according the list of locales. Also it would be necessary to provide a
mechanism that can purge and hot reload these caches.
Thus... now we have the following:
- UrlRewriteFilter w/ java class re-writers and hot reloadable resource
bundles DOING MUCH LESS e.g. mapping urls /shares == /share/all
- An implicitly enhanced RedirectResolution that simply utilizes the
current context locale to produce an appropriate URL
- An implicitly enhanced Link tag that simply utilizes the current
context locale to produce an appropriate URL
- An implicitly enhanced Form tag that simply utilizes the current
context locale to produce an appropriate URL
- An implicit ability to still catch URLs whose localization does not
match the users current context locale
So essentially instead of having the current One-to-One mapping of URL
binding to Action Bean we would have a Many-to-One mapping of URL
bindings to Action Beans however the association key is the current
locale and if that fails then each of the localized URL bindings could
be used until one fully matches. This could also offer the side benefit
that if 2 Action Beans have localized URI conflicts then a URL cache
process time error could be generated where as currently this is simply
a run time bug.
Because as much as I would like to see localization as a veneer as we
have done now unfortunately it permeates through other areas and now
ends up requiring front end rewriter mapping logic coupled on top of Tag
and Resolution enhancements and finally Action Beans needed to maintain
and support localization... .
And I think that this becomes somewhat of a tipping point where the
veneer solution appears to need just way too much plaster to maintain
and instead could be something the framework can gracefully abstract
away and support.
What are peoples thoughts on this Solution #3? Any holes in the logic?
Opinions (yes I did ask for that ;-) ? Any suggestions, tweaks, etc...?
Cheers,
--Nikolaos
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company
[Stripes-users] Thoughts on Robust URL Localization in Stripes
Hi,
We essentially have tried very hard to abstract URL localization out of
Stripes and make it a veneer by using all of the following:
- UrlRewriteFilter w/ java class re-writers and hot reloadable resource
bundles
- An enhanced RedirectResolution (to support redirection to a localized URL)
- An enhanced Link tag (to produce a localized URL)
- An enhanced Form tag (to produce a localized action URL)
All of this appears to work but one more thing is missing. Say my
locale is en_CA and someone sends me a link to a Spanish URL. I click
on the link and go to the site and the system says ohhh... your locale
is en_CA therefore the canonical form of the URL is the same as the
incoming URL... ummm 404. Not good.
*Solution #1*: Add shell subclasses of existing Action Beans to support
all the localized @UrlBinding variants for each Action Bean ala Freddy's
book. As I mentioned before this approach did not bode well for the
fact that now localized strings were hardcoded into the code and not
entirely encapsulated in something external and reloadable like resource
bundles.
*Solution #2*: Add a mechanism that if Action Bean resolution fails
progress through each locale (other than the current) and attempt to
find a match to a URL binding and if so then forward to that Action
Bean... . I think this is the solution we are going to follow for now
as we have built all of the above already... BUT...
All this re-opens that can of worms of should the Stripes framework
know about localization or should it simply be a veneer?
And I am thinking that the recent Form tag issues it seems that Stripes
isn't happy if we try to blindly impose that veneer AND there is a lot
of hard work around Stripes to make that veneer work but it does require
a lot of plaster / filler.
So what to do... .
*Solution #3*: Augment Stripes to become more URL localization aware...
a) Come up with a new localization binding or possibly even an enhanced
version of the existing URL binding that say might have a binding
expressed as follows for example:
@UrlBinding(/*[share]*/{uuidRadix}/{titleUrlified}/*[{$event}]*)
Where the [ and ] signal a localized key or variable that is looked up
in a property file and cached for each of the available locales:
localize.url.properties: locales=en,es
localize.url_en.properties:share=share
$event=view,add,edit,remove
localize.url_es.properties:share=compartir
$event=ver,anadir,editar,eliminar
So in this manner when Stripes processes the annotation it produces
multiple bindings, 1 per locale, per action bean and prioritized
according the list of locales. Also it would be necessary to provide a
mechanism that can purge and hot reload these caches.
Thus... now we have the following:
- UrlRewriteFilter w/ java class re-writers and hot reloadable resource
bundles DOING MUCH LESS e.g. mapping urls /shares == /share/all
- An implicitly enhanced RedirectResolution that simply utilizes the
current context locale to produce an appropriate URL
- An implicitly enhanced Link tag that simply utilizes the current
context locale to produce an appropriate URL
- An implicitly enhanced Form tag that simply utilizes the current
context locale to produce an appropriate URL
- An implicit ability to still catch URLs whose localization does not
match the users current context locale
So essentially instead of having the current One-to-One mapping of URL
binding to Action Bean we would have a Many-to-One mapping of URL
bindings to Action Beans however the association key is the current
locale and if that fails then each of the localized URL bindings could
be used until one fully matches. This could also offer the side benefit
that if 2 Action Beans have localized URI conflicts then a URL cache
process time error could be generated where as currently this is simply
a run time bug.
Because as much as I would like to see localization as a veneer as we
have done now unfortunately it permeates through other areas and now
ends up requiring front end rewriter mapping logic coupled on top of Tag
and Resolution enhancements and finally Action Beans needed to maintain
and support localization... .
And I think that this becomes somewhat of a tipping point where the
veneer solution appears to need just way too much plaster to maintain
and instead could be something the framework can gracefully abstract
away and support.
What are peoples thoughts on this Solution #3? Any holes in the logic?
Opinions (yes I did ask for that ;-) ? Any suggestions, tweaks,
enhancements, mods, etc...?
Cheers,
--Nikolaos
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business,
Re: [Stripes-users] s:form Localization Issue (UPDATE #1)
Hi all,
I explored work around *Solution #1* (see e-mail below) which
essentially is the simplified code:
s:form class=x-form
action=*${actionBean.formPostUrlBinding}* method=POST
...
s:hidden name=*toUrl* /
...
/s:form
Such that it produces the following simplified snippet:
form action=*/ui-web/share/0/_* class=x-form method=POST
...
input name=toUrl
value=*/ui-web/compartir/0/_/anadir* type=hidden /
...
/form
And Stripes is happy with the binding HOWEVER upon massaging the source
page / resolution it became obvious that as the user posts to:
/ui-web/share/0/_
if a validation error occurs I would need to do a *RedirectResolution*
vs. Stripes current *ForwardResolution* to get the user back to:
/ui-web/compartir/0/_
This NOW produces other grief... such as the fact that on Redirect
Stripes does not maintain the errors (but does maintain messages) so now
I would have to augment the redirect mechanism to use the flash scope to
maintain errors on top of having the user POST a non-localized URL and
do redirects... this is getting uglier by the minute... .
So it appears I am damned if I do and damned if I don't... damned if I
appease Stripes... i.e. damned if I don't appease Stripes as it works
against the Stripes grain... .
*Solution #2 *outlined in the e-mail below - while it would work and is
in Freddy's book is simply totally backwards as it hard codes
localization back into the classes of the app which defeats the
abstraction / separation of localization from code and defeats the
entire purpose of all the localization that was built with
UrlRewriterFilter and resource bundles... .
*Solution #3* (just thought of) is something I am going to try next...
HACK Stripes form tag to accept an overrideUri attribute such that it
can do all the lovely binding stuff it wants to but the URI that gets
populated in the action will be the contents of overrideUri IFF
specified (thus keeping things backwards compatible). I would also use
beanclass to help Stripes point to the ActionBean. So in the end, let
Stripes do its magic just point the user back to some other URI for the
purposes of the action of the form. Fingers crossed... .
Stay tuned... .
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
*/_Setup:_/
*
- ShareActionBean with
@UrlBinding(*/share/*{uuidRadix}/{titleUrlified}/{$event})
- UrlRewriteFilter that pre-processes requests and maps say the
Spanish URL:
*/compartir/0/_/anadir* == */share/0/_/add*
/_*Flow:*_/
- User request: */compartir/0/_/anadir*
- UrlRewriteFilter forwards to: */share/0/_/add*
- ShareActionBean event handler simply does:
return (new*
ForwardResolution*(/WEB-INF/jsp/content/*share_form.jsp*));
- *share_form.jsp* relevant snippet contains:
*s:form* *action=${actionBean.formUrlBinding}* method=POST
s:text name=share.title /
s:hidden name=*tokenKeyTx* /
s:submit name=yes /s:submit name=no /
*/s:form*
- *${actionBean.formUrlBinding}* resolves to */compartir/0/_ *so
the form tag ends up looking like:
form action= */compartir/0/_* method=POST
input type=text name=share.title value= /
input type=hidden name=*tokenKeyTx* value= /
input type=submit name=yes value=yes /input
type=submit name=no value=no /
* /form
*- Now, what happens next was somewhat unexpected... as soon as the
form tag is processed the following error comes up:
ERROR net.sourceforge.stripes.tag.FormTag.error - Could not locate an
ActionBean that was bound to the URL [/compartir/0/_]. Without an
ActionBean class Stripes cannot determine whether the ActionBean is a
wizard or not. As a result wizard behaviour will be disabled.
- While I understand that Stripes is trying to make a 1-to-1
association between the form action and an existing URL binding the
problem is that the error appears to affect the binding of the
tokenKeyTx hidden field in the form in that it ends up with a value
of instead of its true value 83e32-32435254-sjfi-asbsdrwq.
I could probably live with an error being logged but why does Stripes
make this such a serious offence AND in light of localization isn't
this a problem???
I see 2 immediate workarounds to this problem though both aren't great:
1) Use non-localized action URL in the form but then I would need to
override Source page resolution b/c if there is an error in say user
input the user must be redirected to the localized version of the URL
and not the non-localized version. As well in order to maintain the
localized URL which could contain an id for example (say doing edit)
we would need to add a hidden form field for the localized URI... this
smells in that the URL in the action is non-localized and although not
directly visible to the user still appears silly to be part
[Stripes-users] s:form Localization Issue
Hi,
*/_Setup:_/
*
- ShareActionBean with
@UrlBinding(*/share/*{uuidRadix}/{titleUrlified}/{$event})
- UrlRewriteFilter that pre-processes requests and maps say the Spanish URL:
*/compartir/0/_/anadir* == */share/0/_/add*
/_*Flow:*_/
- User request: */compartir/0/_/anadir*
- UrlRewriteFilter forwards to: */share/0/_/add*
- ShareActionBean event handler simply does:
return (new*
ForwardResolution*(/WEB-INF/jsp/content/*share_form.jsp*));
- *share_form.jsp* relevant snippet contains:
*s:form* *action=${actionBean.formUrlBinding}* method=POST
s:text name=share.title /
s:hidden name=*tokenKeyTx* /
s:submit name=yes /s:submit name=no /
*/s:form*
- *${actionBean.formUrlBinding}* resolves to */compartir/0/_ *so the
form tag ends up looking like:
form action= */compartir/0/_* method=POST
input type=text name=share.title value= /
input type=hidden name=*tokenKeyTx* value= /
input type=submit name=yes value=yes /input
type=submit name=no value=no /
* /form
*- Now, what happens next was somewhat unexpected... as soon as the form
tag is processed the following error comes up:
ERROR net.sourceforge.stripes.tag.FormTag.error - Could not locate an
ActionBean that was bound to the URL [/compartir/0/_]. Without an
ActionBean class Stripes cannot determine whether the ActionBean is a
wizard or not. As a result wizard behaviour will be disabled.
- While I understand that Stripes is trying to make a 1-to-1 association
between the form action and an existing URL binding the problem is that
the error appears to affect the binding of the tokenKeyTx hidden field
in the form in that it ends up with a value of instead of its true
value 83e32-32435254-sjfi-asbsdrwq.
I could probably live with an error being logged but why does Stripes
make this such a serious offence AND in light of localization isn't this
a problem???
I see 2 immediate workarounds to this problem though both aren't great:
1) Use non-localized action URL in the form but then I would need to
override Source page resolution b/c if there is an error in say user
input the user must be redirected to the localized version of the URL
and not the non-localized version. As well in order to maintain the
localized URL which could contain an id for example (say doing edit) we
would need to add a hidden form field for the localized URI... this
smells in that the URL in the action is non-localized and although not
directly visible to the user still appears silly to be part of a fully
localized web app and then we pack a hidden localized URI. Uuuggghhh...
2) Add URL bindings for localized versions. This is not viable as we
are using UrlRewriteFilter to abstract localization from our components
and have invested heavily to abstract as much of that away from Stripes
as possible.
Thoughts? Other Solutions? Is this a flaw? Bug (in light of
localization)?
Thanks,
--Nikolaos
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] s:form Localization Issue
Actually the form tag fails even more spectacularly than I suspected...
as things like s:label tags nested in the form are not even localized.
Looks like Stripes wants to be smart and ensure that URLs map directly
to ActionBean's but that would make sense if Stripes offered full
fledged Localization support on UrlBindings (sure one could make shell
nested subclasses but that is ugly as it hard codes localization vs.
having it in re-loadable property files).
Perhaps what we need is an option on the form tag that signals to
Stripes to ignore the fact that there is no match to an ActionBean and
don't worry about it b/c the developer knows what they are doing.
Because although the default error behaviour is nice it doesn't make
sense with URI localization... .
In any event, would be interested in other people's thoughts /
solutions... .
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
*/_Setup:_/
*
- ShareActionBean with
@UrlBinding(*/share/*{uuidRadix}/{titleUrlified}/{$event})
- UrlRewriteFilter that pre-processes requests and maps say the
Spanish URL:
*/compartir/0/_/anadir* == */share/0/_/add*
/_*Flow:*_/
- User request: */compartir/0/_/anadir*
- UrlRewriteFilter forwards to: */share/0/_/add*
- ShareActionBean event handler simply does:
return (new*
ForwardResolution*(/WEB-INF/jsp/content/*share_form.jsp*));
- *share_form.jsp* relevant snippet contains:
*s:form* *action=${actionBean.formUrlBinding}* method=POST
s:text name=share.title /
s:hidden name=*tokenKeyTx* /
s:submit name=yes /s:submit name=no /
*/s:form*
- *${actionBean.formUrlBinding}* resolves to */compartir/0/_ *so
the form tag ends up looking like:
form action= */compartir/0/_* method=POST
input type=text name=share.title value= /
input type=hidden name=*tokenKeyTx* value= /
input type=submit name=yes value=yes /input
type=submit name=no value=no /
* /form
*- Now, what happens next was somewhat unexpected... as soon as the
form tag is processed the following error comes up:
ERROR net.sourceforge.stripes.tag.FormTag.error - Could not locate an
ActionBean that was bound to the URL [/compartir/0/_]. Without an
ActionBean class Stripes cannot determine whether the ActionBean is a
wizard or not. As a result wizard behaviour will be disabled.
- While I understand that Stripes is trying to make a 1-to-1
association between the form action and an existing URL binding the
problem is that the error appears to affect the binding of the
tokenKeyTx hidden field in the form in that it ends up with a value
of instead of its true value 83e32-32435254-sjfi-asbsdrwq.
I could probably live with an error being logged but why does Stripes
make this such a serious offence AND in light of localization isn't
this a problem???
I see 2 immediate workarounds to this problem though both aren't great:
1) Use non-localized action URL in the form but then I would need to
override Source page resolution b/c if there is an error in say user
input the user must be redirected to the localized version of the URL
and not the non-localized version. As well in order to maintain the
localized URL which could contain an id for example (say doing edit)
we would need to add a hidden form field for the localized URI... this
smells in that the URL in the action is non-localized and although not
directly visible to the user still appears silly to be part of a fully
localized web app and then we pack a hidden localized URI. Uuuggghhh...
2) Add URL bindings for localized versions. This is not viable as we
are using UrlRewriteFilter to abstract localization from our
components and have invested heavily to abstract as much of that away
from Stripes as possible.
Thoughts? Other Solutions? Is this a flaw? Bug (in light of
localization)?
Thanks,
--Nikolaos
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] What notebook would you recommend for working with Stripes and whole JavaEE stack?
I run a MacBook Pro 17 early 2008... Core2 Duo CPU with a 7200RPM Seagate HDD but the primary and secondary SATA controllers are held back to 1.5 and 1.0 Gb/s respectively from 3.0 Gb/s on later models. The stock system is OK but not great for development so I supercharged it :-) About a month ago I found out that I could theoretically get 6GB of RAM in this thing (Apple still only supports 4GB) and I picked up a stick of 4GB (adding it to my 2GB) of RAM from Other World Computing and it REALLY makes a difference. Running w/ Eclipse, GlassFish, MySQL (not so hungry), Firefox and it really helps not to have to swap anymore. I wouldn't run a dev box with anything less than 6GB today. The 2nd major performance improvement is getting a SSD. True - compilation is CPU intensive not disk intensive - but starting up Apps almost instantaneously (in comparison to an HDD) is something to behold. Firefox pops open. Eclipse launches in around 5 seconds. The system launches so fast. But you do need to get a TOP end SSD in my opinion - preferably SLC over MLC though the new rave is eMLC - and although prices are coming down I wanted to get one of the best SLC SSD's I could find so I picked up an Intel X-25E 64GB (I know you said cheap and at $800 you could pick up another laptop but reliability is huge for me). I then swapped out my HDD for the SSD and then picked up an Optibay replacement for my DVD drive and put my HDD in the DVD drive bay; i.e. SSD is primary drive; HDD is secondary; and DVD drive ends up in a DVD enclosure (came with the kit). One needs a DVD less and less these days so getting an SSD and an HDD in a system is ideal IMHO. The system CPU and SATA controllers are now my bottle neck but when I upgrade to a newer Mac the SSD is going into the next system and CPU will be better :-) Personally I like to get at least 2 if not 3 years out of any given laptop. Bottom line: - 6GB+ memory - Great SSD - Decent CPU and you'll be rocking --Nikolaos gshegosh wrote: W dniu 07.01.2011 18:11, Richard Hauswald pisze: Backup on a daily basis(!). I promise you: If you ever developed webapps on a SSD you will never develop using a HDD again. If you have to switch back... ...it will be hard! Yep, I'm using RAID 0 for my system partition and I'm not complaining, too. Substantially cheaper than getting top of the line SSD (tried some cheaper ones and they were worse than HDDs) and performance is on par. Any Dual Core CPU should suite your needs, I never ever ran out CPU power when developing software. Memory is something you can't get enough of. 4GB is ok but I'd like to have 6GB, cause Firefox, Eclipse, Tomcat, Windows 7, Windowx XP Mode and a Linux VM running in parallel is not so uncommon for a developer. But nearly to much for 4GB RAM. Damn, perhaps I should be asking about _software_ stack, not hardware one. Eclipse and Tomcat seem to be better for a PC than Netbeans and Glassfish are. As I'm writing these words, Netbeans and Glassfish running for some 3 or 4 hours take 2,5GB of my memory and it grows with each redeploy, max I've seen was almost 8GB. killall -9 java became a kind of routine for me since NB+GF will become unstable well before the take up those 12GBs I have. I guess memory is not a problem these days, since it's cheap and easy to get 8GB or more even in a laptop. Perhaps one can't run out of CPU, but when I compare compilation time of the same project on my machine which is 4-5s to my friend's Mac where it's about 20-30s, I believe my productivity _can_ hurt because of a slow CPU. Especially on my old laptop which compiles the same project in 3 minutes. And compilation is not all, frequent redeployments, switching between IDE and browser and Photoshop and Virtualbox, using Firebug, all this is much more acceptable on a fast, multi-core CPU. That's why I'm asking about i5 and i7 laptops -- I can read benchmarks all day, but I'd love to hear what development on these machines feels like, especially from folks who use Netbeans and Glassfish combo. The only other option is to find a shop that will let me play with a laptop for an hour before I buy it :-D -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director of Information Technology BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c
Re: [Stripes-users] What notebook would you recommend for working with Stripes and whole JavaEE stack?
Yes. Speed is about the same and they are cheaper. They are MLC... NO... AND if so, how about reliability? Fast and cheap and having to backup your SSD every day are fine if your into that... not me... ;-) I have read too many negative stories on MLC drives and the premium on the Intel X-25E is definitely VERY high but I am extremely happy with it. IIRC you can write something ridiculous like 100GB per day for 5 years and the Intel X-25E should hold up. In any event the new trend is towards eMLC which is so new that I'm not sure I want to step right into that without waiting a little while. Hence the choice of an SLC drive. IN any event... just check out the SSD you are getting and don't just go with fast and cheap ONLY is my advice... reliability is huge for SSD... and whatever works for your pocket book and tolerance is great... I'm NOT going to get into this SSD is better vs. another as they all have PRO's and CON's. ASIDE: We are considering launching w/ servers with these SSDs (w/ SoftLayer) so there's slightly more to why it was selected. Cheers, --Nikolaos Richard Hauswald wrote: Sandforce Controller based SSD's are a fast and cheap alternative to expensive models using SLC: 50-240GB Max Performance Max Read: up to 285MB/s Max Write: up to 275MB/s Sustained Write: up to 250MB/s Random Write 4KB (Aligned): 50,000 IOPS You get 120GB for $220 and 240GB for $450. On Fri, Jan 7, 2011 at 6:56 PM, Nikolaos Giannopoulos nikol...@brightminds.org wrote: I run a MacBook Pro 17 early 2008... Core2 Duo CPU with a 7200RPM Seagate HDD but the primary and secondary SATA controllers are held back to 1.5 and 1.0 Gb/s respectively from 3.0 Gb/s on later models. The stock system is OK but not great for development so I supercharged it :-) About a month ago I found out that I could theoretically get 6GB of RAM in this thing (Apple still only supports 4GB) and I picked up a stick of 4GB (adding it to my 2GB) of RAM from Other World Computing and it REALLY makes a difference. Running w/ Eclipse, GlassFish, MySQL (not so hungry), Firefox and it really helps not to have to swap anymore. I wouldn't run a dev box with anything less than 6GB today. The 2nd major performance improvement is getting a SSD. True - compilation is CPU intensive not disk intensive - but starting up Apps almost instantaneously (in comparison to an HDD) is something to behold. Firefox pops open. Eclipse launches in around 5 seconds. The system launches so fast. But you do need to get a TOP end SSD in my opinion - preferably SLC over MLC though the new rave is eMLC - and although prices are coming down I wanted to get one of the best SLC SSD's I could find so I picked up an Intel X-25E 64GB (I know you said cheap and at $800 you could pick up another laptop but reliability is huge for me). I then swapped out my HDD for the SSD and then picked up an Optibay replacement for my DVD drive and put my HDD in the DVD drive bay; i.e. SSD is primary drive; HDD is secondary; and DVD drive ends up in a DVD enclosure (came with the kit). One needs a DVD less and less these days so getting an SSD and an HDD in a system is ideal IMHO. The system CPU and SATA controllers are now my bottle neck but when I upgrade to a newer Mac the SSD is going into the next system and CPU will be better :-) Personally I like to get at least 2 if not 3 years out of any given laptop. Bottom line: - 6GB+ memory - Great SSD - Decent CPU and you'll be rocking --Nikolaos gshegosh wrote: W dniu 07.01.2011 18:11, Richard Hauswald pisze: Backup on a daily basis(!). I promise you: If you ever developed webapps on a SSD you will never develop using a HDD again. If you have to switch back... ...it will be hard! Yep, I'm using RAID 0 for my system partition and I'm not complaining, too. Substantially cheaper than getting top of the line SSD (tried some cheaper ones and they were worse than HDDs) and performance is on par. Any Dual Core CPU should suite your needs, I never ever ran out CPU power when developing software. Memory is something you can't get enough of. 4GB is ok but I'd like to have 6GB, cause Firefox, Eclipse, Tomcat, Windows 7, Windowx XP Mode and a Linux VM running in parallel is not so uncommon for a developer. But nearly to much for 4GB RAM. Damn, perhaps I should be asking about _software_ stack, not hardware one. Eclipse and Tomcat seem to be better for a PC than Netbeans and Glassfish are. As I'm writing these words, Netbeans and Glassfish running for some 3 or 4 hours take 2,5GB of my memory and it grows with each redeploy, max I've seen was almost 8GB. killall -9 java became a kind of routine for me since NB+GF will become unstable well before the take up those 12GBs I have. I guess memory is not a problem these days, since it's cheap and easy to get 8GB or more even in a laptop. Perhaps one can't run out of CPU, but when I compare compilation time of the same project on my machine which
Re: [Stripes-users] What notebook would you recommend for working with Stripes and whole JavaEE stack?
gshegosh wrote: That's actually quite strange with Netbeans. I can see it's using Xmx 512M and MaxPermSize 200M but it still takes up almost 800M in mem and I've seen more than 1,5G occasionally. JVM Heap + Perm Gen (most JVMs except JRockit have it sit outside Java Heap) + C Heap, Thread stacks, etc... = Process Memory So... 512M + 200M + ?... should at least be 712M+ and 800M isn't a surprise. What are you doing when you see it go up to 1.5G? Does it happen over a protracted period of time? Perhaps a NetBeans memory leak? If its nothing special then I would look at bug reports and consider switching to another IDE as 1.5GB is ridiculous. As to Glassfish - I have plenty of RAM so I upped Xmx and permsize because otherwise it would give me outofmemory exceptions every 2 or 3 redeploys. I guess it's some serious leak in Glassfish itself, because it happens for more than one apps and at the production, where redeploys are rare, the problem is nonexistent. What exact version of GlassFish and what JDK? v3 Final? 1.6_? I have not seen any such memory leaks... . Do you happen to have a .hs_err_BLAH (IIRC the name) file when the OOM occured... b/c if you do then you should be able to easily see what filled up... if it indeed was perm gen space or something else? It's quite common practice to have on production app servers the min and max of memory settings the same and maxed so that things don't grow i.e. set permSize AND maxPermSize to your max perm size... set -Xms AND -Xmx to your max JVM heap size... otherwise new blocks of memory will need to be allocated, copying, etc... . In development I set the min to at least 1/2 my max for the heap and set min and max perm gen to the max value as there is a lot of class re-compilation / re-loading... 256MB is usually sufficient and if that fills up its probably best to restart the app server in any event. Then there are other JVM settings to tune as well... like GC algorithm, GC threads, etc... setup your gc to print out periodically and review the data. What OS are you running on and what is your -Xss JVM setting? On Solaris for example 1MB is allocated to the stack for each thread which is overkill for almost any production app... 128k is typically more than sufficient. Performance tuning is a big area in itself and there are many things to adjust / tweak. It amazes me how many times I have seen client production app's fall over on a 32bit JVM with say 2.5GB of allocated heap... yes... if you get enough load and your app server is worked hard enough... it will fall over at 3.5 - 3.8GB (at least on Solaris). But honestly you can't compare any app server in development vs. production as the load characteristics and most often even the OS aren't even the same. You wont note a difference betwenn i5 and i7 when developing webapps. If you do care about build time differences of a half second then use a i7. Probably true because I don't see all cores of my i7 busy too much on my desktop (video and mass image processing is amazingly fast though). So, a laptop with i5, 8G of RAM and an SSD drive perhaps should be good for my needs. I haven't been really following _all_ tech changes in PCs recently, is there anything else I should look at when hunting for a perfect machine? :-) I think that pretty much covers the hardware side... save of course a big screen and / or external display. --Nikolaos -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] View component inclusion
Jonothan, Without sufficient code its really hard to figure out what you are looking for and then you say this and that won't work. Why don't you provide the actual code you have - as complete as possible - and then I imagine people can help you. Because as it stands Farouk, Remi, Ben and anyone else could keep guessing... apparently incorrectly... . --Nikolaos Jonathan wrote: This seems to be the solution to first order, but Stripes keeps some informations in the request (the action bean, the name of the event) that prevents this method to function (event name conflict in some cases, impossible to make multiple inclusions of same action bean since it's cached). Based on feedback from the mailing list I think there is no right way to do that. I think the use of the JSTL tag c:import/ is the closest answer to what I'm looking to do. An other solution : implementing a special include tag that wrap request to avoid conflicts between parameters and attributes of the main request and those of the include request. Thank you all for your help -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes' new streaming layout
What I think also needs to be said is that Ben single handedly re-wrote the Stripes Layouts and from what I gather spent a huge amount of his personal time doing so. In addition, the re-write apparently was no easy task and Ben had to move away from the re-write on at least one occasion for quite some time. And in the end, when some issues remained and pressure surfaced from people in the community (myself especially) to resolve issues in the Stripes Layouts Ben once again came threw and resolved the issues completely. Ben could have easily thrown up his hands, and passed the baton, but didn't, and that in itself demonstrates great dedication and love for the Stripes project. Thank You Ben for all you have done and continue to do for Stripes. Your dedication and contributions are extremely appreciated! Sincerely, --Nikolaos P.S. Thanks Daniil for reminding us that we can use this forum to complement the actions of those that put great effort into this project. It's not often that positive e-mails surface on a mailing list - in fact its typically quite the opposite - and its quite refreshing to see your e-mail. Thank You. Ben Gunter wrote: Thank you so much for the positive feedback. I worked really hard to get that done, and it's nice to know people are benefiting from it. The switch to streaming hasn't been without its hiccups, but I think the benefits far outweigh the problems that have been encountered. -Ben On Wed, Dec 22, 2010 at 9:24 AM, Daniil Sosonkin dan...@orbisfn.com mailto:dan...@orbisfn.com wrote: To Stripes Developers, I'd like to take a moment to leave my warmest regards to the Stripes' new streaming layout tags. The rewrite is truly something that had to be done from the beginning. It makes web app behave like no other. I had no complaints about Stripes before, but since the release of 1.5.3 its been simple wonder running the framework. Our site is relatively small. We get about 200 concurrent users. Nonetheless, performance gains are clearly visible. Just some bullet points below: * Faster perceived response time * Memory usage has been stabilized without jumping up and down * Reduced CPU usage (unexpected) The most important improvement is the perceived response time. I'm tracking page load for every single JSP request all the time (my own pet peeve) and there have been no changes there, but users get first bytes in the response faster. I guess buffering is not always desired. Don't know if anyone has felt the changes, but I've seen those only after installing new Stripes. And a side effect of that is clearly visible to our international clients in Asia. The content delivery is more instant. My thanks go out to all who contributed to this change. Its great to see Stripes improve so much and looking forward to the bright future as well. Cheers, Daniil -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] getting specified instance of DAO in ActionBean
Milan, You could wrap an instance you create in a custom bean context and add it to and retrieve it from the session. Something like the following except with your DAO instead of a user object: http://stripesframework.org/display/stripes/State+Management But I'm curious why doesn't a singleton DAO cut it? Unless your retaining state in your DAO's... which is typically better done elsewhere. --Nikolaos Milan Halenar wrote: Hello, at the beggining let me briefly describe situation: Im developing an web app in which i upload file, parse the file and store its content in a simple DAO. Currently i implemented the DAO as singleton, so in my ActionBean im doing this: private FileParser fp = FileParser.getInstance(); and every session(user) has the same instance of that dao. My aim is to have new instance of this class for every new session, i mean not having the FileParser implemented as a singleton. The problem is that i dont know how to get the specified instance of DAO with users data in the ActionBean. Is there any suggested way to do this? Thanks -- ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] getting specified instance of DAO in ActionBean
Milan, In that case why bother with a DAO at all? i.e. although it would be nice to plug in a DB later the problem you are going to have is where to store the information for the life of a user session and that is typically going to be on the session itself... however until you pass the http request to the DAO you won't have access to that. Personally... I see 2 obvious choices: #1 Use DAO's and add arguments to pass in the http request / session. #2 Use a custom action bean context as I showed you in the previous reply and put access methods on the context itself. I would go with #2 regardless so that it encapsulates the data you are retaining. And if you need to create the additional abstraction or will want to eventually go to a DB then wrap #1 around it but in that case you will want to eventually change both the DAO interfaces (as the http request / session will no longer be required) and the DAO implementation; doesn't totally defeat the purpose of a DAO abstraction but isn't the right thing. In fact, the more I think about it I would look at a different design pattern altogether that focuses on maintaining state or simply do #2. --Nikolaos Milan Halenar wrote: Milan Halenar mhale...@... writes: Ad: im not using any DB, im just storing the content of file in memory in the FileParser class in an ArrayList. And i need for every session to have its own instance of that class. I hope i cleared it a bit. -- ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Different Types of Messages
Hi, So in Stripes we can display messages OR errors to users and everything seems OK. Editing the resource file makes in tandem with CSS appears to work well. However, what if one wants to display different types of messages for users like a Warning and Ok (checkmark)? e.g. checkmark-icon Your article was saved e.g. warn-icon The language of this Article is English however you have selected Spanish Is this possible with Stripes? --Nikolaos -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Different Types of Messages
Rick,
No... I get that... the need here is for an Ok / Info type message and a
Warn type message e.g. If someone just canceled editing an article
neither a X error icon nor a checkmark icon is appropriate... a
warning is more appropriate via say an ! icon.
This is not uncommon in software to provide 3 message states... info,
warn and error.
Stripes supports 2 but not everything is black or white sometimes its
grey... ;-)
I looked at handling this by making the warning messages special cases
that would include a little extra HTML (and CSS) as follows:
cancel.canceledTx=span class=warnWe canceled the changes you were
making to this {0}./p
Problem is that this doesn't work very well for the size and placement
of the warn image (its now inside a span). Not to mention in the
overriden warn case we are trying to place the image in the span and in
the info case we are trying to place it in the div. Just messed up all
around.
Oh well...
--Nikolaos
Rick Grashel wrote:
Nikolaos,
You can use the following in your StripesResources.properties files:
The following is for standard messages:
stripes.messages.header=br/div class=checkmark
stripes.messages.beforeMessage=
stripes.messages.afterMessage=
stripes.messages.footer=/div
Notice the 'class=checkmark' piece.
The following is for errors:
stripes.errors.header=br/div class=errorThe following errors
occurred:/divdiv class=errorol
stripes.errors.beforeError=li
stripes.errors.afterError=/li
stripes.errors.footer=/ol/div
This is only one possible example you could use. Obviously, tailor it
to your needs. But do you actually need more than just an error CSS
class and an information CSS class? If so, then I'd think you need to
write your own rendering strategy for messages.
-- Rick
On Mon, Nov 29, 2010 at 2:54 PM, Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org wrote:
Hi,
So in Stripes we can display messages OR errors to users and
everything
seems OK.
Editing the resource file makes in tandem with CSS appears to work
well.
However, what if one wants to display different types of messages for
users like a Warning and Ok (checkmark)?
e.g. checkmark-icon Your article was saved
e.g. warn-icon The language of this Article is English however you
have selected Spanish
Is this possible with Stripes?
--Nikolaos
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today
with the
Intel(R) Software Partner Program. Five $500 cash prizes are up
for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
mailto:Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Different Types of Messages
Rick,
It's something I was actually tinkering with and looked at as I added
localization to the s:link tag the other day by pretty much doing the
same thing... cloning the Stripes Link tag and adding localization to
create my own a:link tag. But until your reply I thought about putting
this aside until later.
In any event, your suggestion was very well detailed and bang on :-) So
here is what I did:
#1 Added tagging subclasses LocalizedMessageInfo and
LocalizedMessageWarning messages
#2 Cloned MessageTag into MessageWarningTag and MessageInfoTag with
minor variations for picking the correct resource bundle keys; the only
sizable change was at the end of the getMessages method I filtered the
messages for the respective tags to only return a list of messages with
its respective subclass. For example:
// Filter out and return only messages that are subclasses of
LocalizableMessageInfo
if (messages != null) {
ListMessage filteredMessages = new ArrayListMessage();
for (Message message : messages) {
if (message instanceof LocalizableMessageInfo) {
filteredMessages.add(message);
}
}
// Swap full message list with the filtered message list
messages = filteredMessages;
}
return messages;
#3 Cloned the stripes resource property blocks to specify infos and
warnings classes respectively
stripes.messages.info.header=div class=infos
stripes.messages.info.beforeMessage=p
stripes.messages.info.afterMessage=/p
stripes.messages.info.footer=/div
stripes.messages.warning.header=div class=warnings
stripes.messages.warning.beforeMessage=p
stripes.messages.warning.afterMessage=/p
stripes.messages.warning.footer=/div
The nice thing about this mechanism is that it piggyback's on top of how
Stripes handles messages so it integrates seamlessly (e.g. Stripes
adding flash scope when messages added and a redirect performed).
Anyone think this should be incorporated in the Stripes framework?
Much Appreciated Rick!
--Nikolaos
Rick Grashel wrote:
Nikolaos,
It seems like you could easily extend LocalizableMessage and create an
InfoMessage and WarningMessage class. Then, you would just need to
create an InfoMessagesTag class and a WarningMessagesTag class. Have
those classes define before and after properties just like
MessagesTag.java does. In fact, copy and paste MessagesTag.java
wholesale -- just change getMessages() to return ListInfoMessage or
ListWarningMessage. Then, define the tags in your TLD file.
Then, in your ActionBean, just instantiate InfoMessages or
WarningMessages and put them in the context just like a
SimpleMessage. Then, you should easily be able to have a
stripes:warningMessages and stripes:infoMessages tags in your
JSPs. You would need to get rid of any stripes:messages tags as
they don't discern any type of messages to display. Then, everything
should work fine.
Honestly, this probably is an hour or so worth of work and it
continues to follow Stripes' conventions. It might be worth some
consideration.
-- Rick
On Mon, Nov 29, 2010 at 7:18 PM, Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org wrote:
Rick,
No... I get that... the need here is for an Ok / Info type message
and a Warn type message e.g. If someone just canceled editing an
article neither a X error icon nor a checkmark icon is
appropriate... a warning is more appropriate via say an ! icon.
This is not uncommon in software to provide 3 message states...
info, warn and error.
Stripes supports 2 but not everything is black or white sometimes
its grey... ;-)
I looked at handling this by making the warning messages special
cases that would include a little extra HTML (and CSS) as follows:
cancel.canceledTx=span class=warnWe canceled the changes you
were making to this {0}./p
Problem is that this doesn't work very well for the size and
placement of the warn image (its now inside a span). Not to
mention in the overriden warn case we are trying to place the
image in the span and in the info case we are trying to place it
in the div. Just messed up all around.
Oh well...
--Nikolaos
Rick Grashel wrote:
Nikolaos,
You can use the following in your StripesResources.properties files:
The following is for standard messages:
stripes.messages.header=br/div class=checkmark
stripes.messages.beforeMessage=
stripes.messages.afterMessage=
stripes.messages.footer=/div
Notice the 'class=checkmark' piece.
The following is for errors:
stripes.errors.header=br/div class=errorThe following
errors occurred:/divdiv class=errorol
stripes.errors.beforeError=li
stripes.errors.afterError=/li
stripes.errors.footer=/ol/div
This is only one possible example you could use. Obviously,
tailor
Re: [Stripes-users] Clean URL not 100% clean after redirect resolution???
Ben,
That's quite funny as I what I did and I was initially surprised to see
the message on the redirect. Appears to be - once again - a case were
in Stripes is smarter than expected. That clears it up. Thank You.
Incidentally, is there a place that documents the different params that
Stripes uses and moreover expands their abbreviations... . Such as:
__fp used in forms
and
_sourcePage also used in forms however even though it appears to be a
base64 representation of what I expected to be the source page URL but
it in fact appears to be binary data
If there is documentation for this information then that would be great.
Thanks Again,
--Nikolaos
Ben Gunter wrote:
That's the flash scope key. You're probably using flash scope
indirectly by adding a message and then redirecting.
-Ben
On Fri, Nov 26, 2010 at 2:14 AM, Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org wrote:
Hi,
We have the following clean URL:
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{$event})
After a user is done editing a form they click on save which saves
the article and then does a redirect resolution as follows:
RedirectResolution redirect = new
RedirectResolution(ArticleActionBean.class);
redirect.addParameter(authorId, this.authorId).
addParameter(id, this.id http://this.id).
addParameter(titleUrlified, this.titleUrlified);
We end up with:
http://www.local.ca:8080/web/article/28mqnalvgqf2n/2/some-article/view*?__fsk=-1249240358*
Unfortunately this URL isn't totally clean. Might appear picky
but if one tries hard for URL's to follow clean URL's this is not
good albeit the value is harmless. So... how can I get rid of the
__fsk=-1249240358 parameter?
Also... why is Stripes adding it? I don't see this particular
field anywhere and don't see why its necessary.
Thanks,
--Nikolaos
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today
with the
Intel(R) Software Partner Program. Five $500 cash prizes are up
for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
mailto:Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Clean URL not 100% clean after redirect resolution???
Hi,
We have the following clean URL:
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{$event})
After a user is done editing a form they click on save which saves the
article and then does a redirect resolution as follows:
RedirectResolution redirect = new
RedirectResolution(ArticleActionBean.class);
redirect.addParameter(authorId, this.authorId).
addParameter(id, this.id).
addParameter(titleUrlified, this.titleUrlified);
We end up with:
http://www.local.ca:8080/web/article/28mqnalvgqf2n/2/some-article/view*?__fsk=-1249240358*
Unfortunately this URL isn't totally clean. Might appear picky but if
one tries hard for URL's to follow clean URL's this is not good albeit
the value is harmless. So... how can I get rid of the
__fsk=-1249240358 parameter?
Also... why is Stripes adding it? I don't see this particular field
anywhere and don't see why its necessary.
Thanks,
--Nikolaos
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Is this a bug:: Clean Url's and @Validate(required=false)???
Ben,
I agree its not what anyone expects.
I guess it means that I will have to use single character (valid) dummy
values as a work-around e.g.:
/web/article/0/0/_/add
Not ideal but as you point out the web container is the collapsing the
back-to-back slashes.
--Nikolaos
Ben Gunter wrote:
That certainly isn't what I would expect to happen, but it does not
appear to be the fault of Stripes. I set up an ActionBean like you
describe in a test app and got the same results you did. When I hooked
up a debugger to look at UrlBindingFactory.getBinding(..), I stepped
into HttpUtil.getRequestedPath(..) and found that the value returned
by request.getServletPath() is not /web/articleadd but
/web/article/add. It seems the servlet container does us a favor
by collapsing multiple slashes in the path to a single one.
One might be inclined to use request.getRequestURI() instead, but that
causes even bigger problems. See here for a little bit of history:
http://www.stripesframework.org/jira/browse/STS-575
I'm not sure there's much we can do about this.
-Ben
On Sat, Nov 20, 2010 at 6:17 PM, Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org wrote:
Hi,
If I have the following Url binding were each of the 1st 3 fields are not
required:
@UrlBinding(//article//{authorId}/{id}/{titleUrlified}/{$event})
And try the following Url:
/web/article///add
Clearly the add handler gets triggered but then something bizarre
happens.
The values that are assigned are:
authorId = 'add'
id = null
titleUrlified = null
However I expected the following assignment:
authorId = null
id = null
titleUrlified = null
It appears that although Stripes is able to correctly bind the
appropriate fields of the @UrlBinding for the incoming request it doesn't
fulfill that when assigning the values to the attributes of the ActionBean...
It's as if it says well what do we need to assign 1st?
Umm authorId... ok what's the 1st value we have... 'add'... great...
NO... 'add' is bound to the event!!!
It should be we just did this:
1. authorId was not required and had no value hence its assigned null
2. id was not required and had no value hence its assigned null
3. titleUrlified was not required and had no value hence its assigned null
4. and event is assigned 'add'
Is this not a bug?
--Nikolaos
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes 1.5.4 and stripersist 1.0
a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director of Information Technology BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Smarter RedirectResolution To Clean URL?
Hi,
I have the following Url binding were each the 3 arguments are optional.
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{_eventName})
The following Url presents a form to create a new article:
/web/article///add
As an article has not been created yet we don't know the values to {id}
or {titleUrlified} hence the blank entries.
Once the article is saved we set values for {authorId}, {id} and
{titleUrlified} on the ArticleActionBean and do the following (back to
itself):
return (new RedirectResolution(ArticleActionBean.class, view));
However this redirects us to:
/web/article
Instead I would have expected:
/web/245b57557f0d3c57/2/magic-or-science/view
This appears so basic I'm not sure what I am doing wrong.
I know RedirectResolution can take a Url as argument but constructing
the Url myself seems like unnecessary duplication of the binding.
Perhaps there's a smarter way to construct the Url by using the binding
or by somehow associating parameters to the RedirectResolution
Anyone?
--Nikolaos
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Smarter RedirectResolution To Clean URL?
Minor correction below.
--Nikolaos
Nikolaos Giannopoulos wrote:
I have the following Url binding were each the 3 arguments are optional.
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{_eventName})
The following Url presents a form to create a new article:
/web/article///add
As an article has not been created yet we don't know the values to
{id} or {titleUrlified} hence the blank entries.
Once the article is saved we set values for {authorId}, {id} and
{titleUrlified} on the ArticleActionBean and do the following (back to
itself):
return (new RedirectResolution(ArticleActionBean.class, view));
However this redirects us to:
/web/article
Instead I would have expected:
/web/article/245b57557f0d3c57/2/magic-or-science/view
This appears so basic I'm not sure what I am doing wrong.
I know RedirectResolution can take a Url as argument but constructing
the Url myself seems like unnecessary duplication of the binding.
Perhaps there's a smarter way to construct the Url by using the
binding or by somehow associating parameters to the
RedirectResolution
Anyone?
--Nikolaos
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Smarter RedirectResolution To Clean URL?
gshegosh, Much Appreciated. The following was 99% there: return (new RedirectResolution(ArticleActionBean.class, view).addParameter(authorId, this.article.getAuthorId()).addParameter(id, this.article.getId()).addParameter(titleUrlified, this.article.getTitleUrlified()); As it resulted in: /web/article/245b57557f0d3c57/2/magic-or-science?view= This appears to be a bug as it should have injected the event in the clean Url. No? Whereas the following worked perfectly: return (new RedirectResolution(ArticleActionBean.class).addParameter(authorId, this.article.getAuthorId()).addParameter(id, this.article.getId()).addParameter(titleUrlified, this.article.getTitleUrlified()).addParameter(_eventName, view)); Correctly resulting in: /web/article/245b57557f0d3c57/2/magic-or-science/view --Nikolaos gshegosh wrote: Have you tried new RedirectResolution(ArticleActionBean.class, view).addParameter(authorId, 42).addParameter(id, 43) ? :-) -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Smarter RedirectResolution To Clean URL?
Levi,
Because they are equivalent ;-)
No. Seriously. Because {$event} can get easily confused with EL
${event} in Url bindings whereas {_eventName} is pretty explicit and
obvious.
I know I personally will probably not make the same mistake twice but
other developers working on the code might.
This came up a while back when a typo in Freddy's book resulted in code
that didn't work.
In the end, both are fine, one just appears more explicit.
--Nikolaos
Levi Hoogenberg wrote:
Why are you using {_eventName} instead of {$event}?
Op 20 nov 2010 19:29 schreef Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org:
gshegosh,
Much Appreciated. The following was 99% there:
return (new RedirectResolution(ArticleActionBean.class,
view).addParameter(authorId,
this.article.getAuthorId()).addParameter(id,
this.article.getId()).addParameter(titleUrlified,
this.article.getTitleUrlified());
As it resulted in:
/web/article/245b57557f0d3c57/2/magic-or-science?view=
This appears to be a bug as it should have injected the event in the
clean Url. No?
Whereas the following worked perfectly:
return (new
RedirectResolution(ArticleActionBean.class).addParameter(authorId,
this.article.getAuthorId()).addParameter(id,
this.article.getId()).addParameter(titleUrlified,
this.article.getTitleUrlified()).addParameter(_eventName, view));
Correctly resulting in:
/web/article/245b57557f0d3c57/2/magic-or-science/view
--Nikolaos
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Smarter RedirectResolution To Clean URL?
Thanks Ben for the explanation. Makes sense.
Thanks Levi and Gshegosh for the pointers... .
All good!
--Nikolaos
Ben Gunter wrote:
They're very close to equivalent, but not exactly. The special
_eventName parameter overrides all other means of specifying the event
name. (The other ways are: event name as parameter; append event name
to path; and $event with clean URLs, which is really the same as the
first.) So if you use {$event} instead of {_eventName} in @UrlBinding
you can still override the value specified for {$event} by sending a
different value for _eventName in the GET query string or POST request
body. It would be unusual, but I just thought I'd point out the
difference.
Another difference is what you've discovered on your own. The {$event}
construct gets special treatment when building URLs, whereas
{_eventName} does not.
-Ben
On Sat, Nov 20, 2010 at 1:50 PM, Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org wrote:
Levi,
Because they are equivalent ;-)
No. Seriously. Because {$event} can get easily confused with EL
${event} in Url bindings whereas {_eventName} is pretty explicit and
obvious.
I know I personally will probably not make the same mistake twice but
other developers working on the code might.
This came up a while back when a typo in Freddy's book resulted in
code
that didn't work.
In the end, both are fine, one just appears more explicit.
--Nikolaos
Levi Hoogenberg wrote:
Why are you using {_eventName} instead of {$event}?
Op 20 nov 2010 19:29 schreef Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org
mailto:nikol...@brightminds.org mailto:nikol...@brightminds.org:
gshegosh,
Much Appreciated. The following was 99% there:
return (new RedirectResolution(ArticleActionBean.class,
view).addParameter(authorId,
this.article.getAuthorId()).addParameter(id,
this.article.getId()).addParameter(titleUrlified,
this.article.getTitleUrlified());
As it resulted in:
/web/article/245b57557f0d3c57/2/magic-or-science?view=
This appears to be a bug as it should have injected the event
in the
clean Url. No?
Whereas the following worked perfectly:
return (new
RedirectResolution(ArticleActionBean.class).addParameter(authorId,
this.article.getAuthorId()).addParameter(id,
this.article.getId()).addParameter(titleUrlified,
this.article.getTitleUrlified()).addParameter(_eventName,
view));
Correctly resulting in:
/web/article/245b57557f0d3c57/2/magic-or-science/view
--Nikolaos
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating
great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
mailto:Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Stripes forms and Clean Url binding?
Hi,
We have the following Url binding:
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{$event})
And when we direct to the following url:
/web/articleadd
It does a ForwardResolution to a form which contains:
s:form
beanclass=org.test.ui.web.action.content.ArticleActionBean method=POST
...
s:submit name=save /
s:submit name=cancel /
/s:form
However the HTML output is as follows:
form action=/web/article method=POST
...
input name=save value=Save type=submit /
input name=cancel value=Cancel type=submit /
/form
But the action =/web/article isn't sufficient to hit our Url
binding... when we click on the save or cancel buttons???
Am I missing something obvious like in the case of addParameter on
RedirectResolution?
Anyone?
--Nikolaos
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes forms and Clean Url binding?
Hi,
So I figured out a solution to the problem:
s:hidden name=authorId/s:hidden
s:hidden name=id/s:hidden
s:hidden name=titleUrlified/s:hidden
At first I thought it would be nice to force Stripes to build the
complete @UrlBinding i.e. it is already obviously consulting the
@UrlBinding to produce /article but understand why it isn't so. Even
in my case above I didn't want event to be the same so I guess this
offers the most flexibility... because how far do you go in binding
parameters is not black white.
Cheers,
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
We have the following Url binding:
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{$event})
And when we direct to the following url:
/web/articleadd
It does a ForwardResolution to a form which contains:
s:form
beanclass=org.test.ui.web.action.content.ArticleActionBean method=POST
...
s:submit name=save /
s:submit name=cancel /
/s:form
However the HTML output is as follows:
form action=/web/article method=POST
...
input name=save value=Save type=submit /
input name=cancel value=Cancel type=submit /
/form
But the action =/web/article isn't sufficient to hit our Url
binding... when we click on the save or cancel buttons???
Am I missing something obvious like in the case of addParameter on
RedirectResolution?
Anyone?
--Nikolaos
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes forms and Clean Url binding?
Oops... was playing around with a number of solutions. This one won't
work because it didn't solve the fact that form action=/article is
unable to hit the @UrlBinding for the ArticleActionBean.
So far what appears to work is doing the following:
s:form action=${actionBean.formUrlBinding} method=POST
And then having on the action bean:
public String getFormUrlBinding() {
StringBuilder sb = new StringBuilder();
sb.append(/article/).append(this.authorId).append('/').append(this.id).append('/').append(this.titleUrlified);
return (sb.toString());
}
Still appears to be a hack as I am duplicating the @UrlBinding but at
least its encapsulated in the ActionBean... if that is any solace ;-)
Cheers,
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
So I figured out a solution to the problem:
s:hidden name=authorId/s:hidden
s:hidden name=id/s:hidden
s:hidden name=titleUrlified/s:hidden
At first I thought it would be nice to force Stripes to build the
complete @UrlBinding i.e. it is already obviously consulting the
@UrlBinding to produce /article but understand why it isn't so. Even
in my case above I didn't want event to be the same so I guess this
offers the most flexibility... because how far do you go in binding
parameters is not black white.
Cheers,
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
We have the following Url binding:
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{$event})
And when we direct to the following url:
/web/articleadd
It does a ForwardResolution to a form which contains:
s:form
beanclass=org.test.ui.web.action.content.ArticleActionBean method=POST
...
s:submit name=save /
s:submit name=cancel /
/s:form
However the HTML output is as follows:
form action=/web/article method=POST
...
input name=save value=Save type=submit /
input name=cancel value=Cancel type=submit /
/form
But the action =/web/article isn't sufficient to hit our Url
binding... when we click on the save or cancel buttons???
Am I missing something obvious like in the case of addParameter on
RedirectResolution?
Anyone?
--Nikolaos
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Is this a bug:: Clean Url's and @Validate(required=false)???
Hi,
If I have the following Url binding were each of the 1st 3 fields are not
required:
@UrlBinding(/article/{authorId}/{id}/{titleUrlified}/{$event})
And try the following Url:
/web/article///add
Clearly the add handler gets triggered but then something bizarre happens.
The values that are assigned are:
authorId = 'add'
id = null
titleUrlified = null
However I expected the following assignment:
authorId = null
id = null
titleUrlified = null
It appears that although Stripes is able to correctly bind the appropriate
fields of the @UrlBinding for the incoming request it doesn't fulfill that when
assigning the values to the attributes of the ActionBean...
It's as if it says well what do we need to assign 1st?
Umm authorId... ok what's the 1st value we have... 'add'... great... NO... 'add' is
bound to the event!!!
It should be we just did this:
1. authorId was not required and had no value hence its assigned null
2. id was not required and had no value hence its assigned null
3. titleUrlified was not required and had no value hence its assigned null
4. and event is assigned 'add'
Is this not a bug?
--Nikolaos
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Smarter RedirectResolution To Clean URL?
Sorry... Freddy... I should have mentioned that it was corrected. --Nikolaos Freddy Daoud wrote: This came up a while back when a typo in Freddy's book resulted in code that didn't work. By the way, the typo has been corrected for current and future owners of the ebook. Freddy -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Form Validation: Stripes and MooTools (field-metadata Tag)
Andrey,
Clearly the choice of JS framework is not the issue here. However, what
I was looking for was a MooTools version of the jQuery script that Aaron
Porter wrote that leverages the field-metadata tag and that is why I
mentioned MooTools here.
Your suggestion however is very interesting and sounds very simple to
implement and does solve the localization of error messages.
However, I am concerned thought that doing an Ajax call per each field
change will amount to a lot of extra server requests and may be a
performance clog on a high traffic site. Did you ever consider limiting
to 1 Ajax request on hitting form submit... basically a pre-validation
to actual form submission?
Thoughts???
--Nikolaos
Andrey Listochkin wrote:
Hi, Nikolaos
I don't think the choice of JS framework could affect validation in
any way. After all you do use ajax, don't you? :)
Here's how we solved it in one of our projects:
1. On client side we add an event listener to each form field (we
listen for onChange event).
2. This event listener does a plain vanilla ajax request. Something like:
/my/action/bean?fieldName=User+ValueajaxValidate=atrue
In our action bean we have fields with some validation rules and
(optionally) custom methods assigned. If we leave it as is it won't
handle our request correctly because some other fields might be
required. That's why ..
3. Our action bean implements ValidationErrorHandler [1] interface to
hijack the default validation handling mechanism.
4. By the time handleValidationErrors method is called all validation
rules are already applied and ValidationErrors array is already filled
in.
5. Inside this handleValidationErrors we check for ajaxValidate
parameter in request and if it's present we filter out validation
errors corresponding to filedName field.
6. If no errors are found we return a JSON {status: 'ok'}. Otherwise
we return JSON with validation errors.
7. On a client side aour Ajax callback function expects a JSON
response data. If JSON has any errors we show them to user.
It's not really hard to implement ajax validation this way and it's
completely library-agnostic. In our project we use jQuery so I don't
show the code to you to avoid confusion. But if you follow the
guidelines that's going to be easy.
Note that we still required to have a ajaxValidate handler defined in
our action bean. It's going to be invoked when the last field in a
form is being validated and is going to pass validation. This is
because in this case ValidationErrors array is empty and
handleValidationErrors isn't called. If this method isn't defined
Stripes will use a default handler - and it might be not something you
intend to.
Cheers,
Andrey
[1]
http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/validation/ValidationErrorHandler.html
On Mon, 15 Nov 2010 20:05:09 +0200, Nikolaos Giannopoulos
nikol...@brightminds.org wrote:
Hi,
I noticed the following page which shows how to integrate Stripes w/
client side validation via JQuery:
http://www.stripesframework.org/display/stripes/Validation+Reference#ValidationReference-Usingthe{{fieldmetadata}}tag
Has anyone done anything similar w/ MooTools?
If so, was it a rewrite of Aaron's code or did it hook into MooTools
Form Validation?
And if so - anything shared would be appreciated.
We are debating whether to do this now (though are short on time - what
else is new) but anything that accelerates that could help us and in
turn we would post it back to the community. I also realize the effort
isn't huge but JQuery notation is new to me and doing this right w/
MooTools and classes will result in a pretty extensive re-write I'm
afraid.
Lastly, this is probably a stretch but did anyone solve the localization
issue in all of this i.e. localized error messages exist in resource
bundles on the Stripes server side yet the messages need to be
accessible to provide the correct message to the user... Ajax is one
possibility... using a generic set of translated messages is another...
but all don't appear optimal.
Much Appreciated.
--Nikolaos
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Nikolaos Giannopoulos
Director of Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
[Stripes-users] Preventing multiple form submission
Hi, Just wondering how others elegantly solve this situation: 1) User is editing a form and fills it out and clicks submit button 2) Form gets successfully processed on the server however before a response is returned the user hits the stop button, their internet connection drops, etc... 4) User clicks on submit again and tries to re-submit the same information(*) Now, this would be trivial if there was a unique piece of information in the content being posted however lets assume someone posting some blog / news content wherein there is really no unique info (e.g. although it may be rare there is nothing wrong with 2 people say posting the same content with the same title). I was thinking to tag the users session with the last successfully submitted Stripes _sourcePage field and direct the user to the view handler if they are trying to do an edit and the _sourcePagematches. Thoughts??? --Nikolaos -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Form Validation: Stripes and MooTools (field-metadata Tag)
Hi,
I noticed the following page which shows how to integrate Stripes w/
client side validation via JQuery:
http://www.stripesframework.org/display/stripes/Validation+Reference#ValidationReference-Usingthe{{fieldmetadata}}tag
Has anyone done anything similar w/ MooTools?
If so, was it a rewrite of Aaron's code or did it hook into MooTools
Form Validation?
And if so - anything shared would be appreciated.
We are debating whether to do this now (though are short on time - what
else is new) but anything that accelerates that could help us and in
turn we would post it back to the community. I also realize the effort
isn't huge but JQuery notation is new to me and doing this right w/
MooTools and classes will result in a pretty extensive re-write I'm afraid.
Lastly, this is probably a stretch but did anyone solve the localization
issue in all of this i.e. localized error messages exist in resource
bundles on the Stripes server side yet the messages need to be
accessible to provide the correct message to the user... Ajax is one
possibility... using a generic set of translated messages is another...
but all don't appear optimal.
Much Appreciated.
--Nikolaos
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Form Validation: Stripes and MooTools (field-metadata Tag)
Pakin,
Welcome to this mailing list. It's great that you are interested in
collaborating.
I totally agree that Stripes needs work in the Validation area on the
server side... and any thoughts would be welcome.
However, this specific thread is about how to hook in client side
validation so as to pre-validate form input so as to improve the user
experience, reduce server load, etc... . I don't believe JSR-303 has
anything to offer here? Does it?
ASIDE: Feel free to start a new thread on JSR-303 Validation. In fact,
if you look in the archives someone provided some code (although I don't
recall the details, how thorough it was, etc...). Again, I don't get me
wrong but I think another thread might be very worthwhile... .
--Nikolaos
Pakin wrote:
Hi all,
I am new in town and I would like to collaborate...
I think that validation-wise, it would be more interesting trying to tackle
the issue of: how to integrate Stripes server and client validation with
JSR-303
Frameworks like Spring MVC 3 or Loom already have it and I think it is
indeed a competitive advantage over Stripes.
I think Stripes validation should adopt JSR-303 because it is standard and
most of the constraints to be validated come from the database and currently
with stripes you have take care about those explicitly.
You can find more information about what Spring MVC does here:
http://static.springsource.org/spring/docs/3.0.0.RC3/spring-framework-reference/html/ch05s07.html
http://static.springsource.org/spring/docs/3.0.0.RC3/spring-framework-reference/html/ch05s07.html
Cheers,
Angel.
Nikolaos Giannopoulos wrote:
Hi,
I noticed the following page which shows how to integrate Stripes w/
client side validation via JQuery:
http://www.stripesframework.org/display/stripes/Validation+Reference#ValidationReference-Usingthe{{fieldmetadata}}tag
Has anyone done anything similar w/ MooTools?
If so, was it a rewrite of Aaron's code or did it hook into MooTools
Form Validation?
And if so - anything shared would be appreciated.
We are debating whether to do this now (though are short on time - what
else is new) but anything that accelerates that could help us and in
turn we would post it back to the community. I also realize the effort
isn't huge but JQuery notation is new to me and doing this right w/
MooTools and classes will result in a pretty extensive re-write I'm
afraid.
Lastly, this is probably a stretch but did anyone solve the localization
issue in all of this i.e. localized error messages exist in resource
bundles on the Stripes server side yet the messages need to be
accessible to provide the correct message to the user... Ajax is one
possibility... using a generic set of translated messages is another...
but all don't appear optimal.
Much Appreciated.
--Nikolaos
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Nikolaos Giannopoulos
Director of Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Form Validation: Stripes and MooTools (field-metadata Tag)
Pakin,
Comments in-line... .
Pakin wrote:
That's OK,
although I want to clarify that they are related matters as what I was
suggesting has to be also reflected in client validation.
Okay... you mentioned JSR-303 but didn't mention client side validation
so that was the disconnect.
Pretty much the use case would be the following: The framework detects if
there is any JSR-303 provider in the classpath, if so it uses all your JPA
annotated pojos that are binded to any form,
I am right there with you. And this is where Stripes validation doesn't
go far enough.
so the stripes taglibs would
generate client validations at jsp rendering time.
Though Stripes validation does attempt to help in this regard with the
field-metadata that can be injected into a form
Somehow this client
validation should be able to be cross-javascript-framework sort to speak.
Stipes-stuff has jQuery files that integrate Stripes field-metadata.
Although I reckon that jQuery is the de facto standard here.
Why do people feel inclined or the need to call JQuery a de facto
standard. It's a framework that is popular. There are many other JS
frameworks that are as good and for the OO purists perhaps even better.
It's like saying Spring MVC is the de facto standard of web frameworks.
In any event, my personal take is that MooTools is like Stripes... maybe
not the most popular... but the best thought out.
Once the form
is submitted the system detects if the form backing bean is a persisted
object with JPA annotation and perform the validations among other
validations you may have. This way you don't need to repeat your DB backend
related constraints using the custom Stripes validation annotations. IMHO it
would be a very agile and convenient feature.
It would be very convenient and barring the JSR-303 aspect Stripes does
that today... at least w/ the help of Aaron's Stripes Stuff.
I was hoping that someone had done something similar w/ MooTools.
And I agree that JSR-303 is the way to go and that the entire validation
process from server, through client, through annotations (JPA, what
not,...) needs to be thought out and built into Stripes in a proper and
robust manner.
So are you volunteering... like I said there was a post on this mailing
list w/ some JSR-303 code... ;-)
Cheers,
--Nikolaos
Cheers mate,
Angel.
Nikolaos Giannopoulos wrote:
Pakin,
Welcome to this mailing list. It's great that you are interested in
collaborating.
I totally agree that Stripes needs work in the Validation area on the
server side... and any thoughts would be welcome.
However, this specific thread is about how to hook in client side
validation so as to pre-validate form input so as to improve the user
experience, reduce server load, etc... . I don't believe JSR-303 has
anything to offer here? Does it?
ASIDE: Feel free to start a new thread on JSR-303 Validation. In fact,
if you look in the archives someone provided some code (although I don't
recall the details, how thorough it was, etc...). Again, I don't get me
wrong but I think another thread might be very worthwhile... .
--Nikolaos
Pakin wrote:
Hi all,
I am new in town and I would like to collaborate...
I think that validation-wise, it would be more interesting trying to
tackle
the issue of: how to integrate Stripes server and client validation with
JSR-303
Frameworks like Spring MVC 3 or Loom already have it and I think it is
indeed a competitive advantage over Stripes.
I think Stripes validation should adopt JSR-303 because it is standard
and
most of the constraints to be validated come from the database and
currently
with stripes you have take care about those explicitly.
You can find more information about what Spring MVC does here:
http://static.springsource.org/spring/docs/3.0.0.RC3/spring-framework-reference/html/ch05s07.html
http://static.springsource.org/spring/docs/3.0.0.RC3/spring-framework-reference/html/ch05s07.html
Cheers,
Angel.
Nikolaos Giannopoulos wrote:
Hi,
I noticed the following page which shows how to integrate Stripes w/
client side validation via JQuery:
http://www.stripesframework.org/display/stripes/Validation+Reference#ValidationReference-Usingthe{{fieldmetadata}}tag
Has anyone done anything similar w/ MooTools?
If so, was it a rewrite of Aaron's code or did it hook into MooTools
Form Validation?
And if so - anything shared would be appreciated.
We are debating whether to do this now (though are short on time - what
else is new) but anything that accelerates that could help us and in
turn we would post it back to the community. I also realize the effort
isn't huge but JQuery notation is new to me and doing this right w/
MooTools and classes will result in a pretty extensive re-write I'm
afraid.
Lastly, this is probably a stretch but did anyone solve the localization
issue in all of this i.e. localized error messages
[Stripes-users] Potential 1.5.4 Proxy Issue WAS [JIRA] Created: (STS-779) Release 1.5.4 (also to Maven Repo)]
Grzgorz, Always makes me cringe to hear IIS used as a proxy for J2EE apps when there are so many great unix based RP's out there ;-) ;-) ;-) In any event, you probably don't have much say in the matter OR perhaps you do... but regardless... you might want to try setting up something like Oracle Web Server (formerly Sun Web Server and since version 7.0 has built-in RP capabilities) OR Squid OR Pound and do a side-by-side test. Say install the RP on a another port and proxy to the same glassfish instance listening on port 8080. I did pretty much the same thing when a client had a F5 load balancer that they weren't able to configure the load balancing sticky-session cookie on and to prove it was the F5 that was the issue I quickly setup a Sun RP as a software load balancer and proved that the F5 indeed was mis-configured b/c the Sun RP had no issues software load balancing to the GlassFish application (Sun OpenSSO / Access Manager). In your case you might be able to prove whether or not IIS is causing you hardship in much the same way. Also you may want to try setting up a more vanilla non-Stripes app and see if you can reproduce the issue. Also you say I'm seeing strange problems... if you could be more descriptive on what is happening then that would help as well. BTW do you have any load balancer software / hardware in the mix? Did it work without issue w/ 1.5.3? Personally - I doubt it that Stripes is the cause - and the only way to prove that is to rule things out one piece at a time. --Nikolaos Ben Gunter wrote: I use the trunk patched with the streaming layout modifications behind Apache's mod_proxy in lots of different places and have never had a problem with it. I've attached a patch you can apply to the 1.5.4 source code to revert the layouts to what they were in 1.5.3. You can check out 1.5.4 from here: https://stripes.svn.sourceforge.net/svnroot/stripes/tags/1.5.4 You can build with maven or ant dist. -Ben 2010/11/10 Grzegorz Krugły g...@karko.net mailto:g...@karko.net Ben, a quick question as I'm seeing some strange problems right now after overnight production deployment and because the discussion about layouts is fresh in my head, it naturally is the first candidate for my cause ;-) Have You (or anyone else for that matter) tried it all behind a proxy? I have a situation here where everything works when accessed on Glassfish directly (via 8080 port), but when accessed through IIS proxying to Glassfish, there are some connection resets or pages server are cut in the middle. Is there a simple way I can modify 1.5.x branch code to bring back old layout mechanisms? I have some other modifications so I cannot just drop in 1.5.3 back to test it :-( W dniu 10.11.2010 04:16, Ben Gunter pisze: My turn to join in the fun on this thread! As far as I'm concerned, the layout changes are solid. Everyone who reported problems while I was working on the changes is now reporting that everything works. All the zany tests I could come up with that used to break things no longer break things. I'm confident it's ready to ship. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] [JIRA] Created: (STS-779) Release 1.5.4 (also to Maven Repo)]
Thought those on the use mailing list might want to voice their opinion(s). --Nikolaos Original Message Subject: [Stripes-dev] [JIRA] Created: (STS-779) Release 1.5.4 (also to Maven Repo) Date: Mon, 8 Nov 2010 19:52:13 -0600 (CST) From: Nikolaos (JIRA) j...@stripesframework.org Reply-To: Stripes Development List stripes-developm...@lists.sourceforge.net To: stripes-developm...@lists.sourceforge.net Release 1.5.4 (also to Maven Repo) -- Key: STS-779 URL: http://www.stripesframework.org/jira/browse/STS-779 Project: Stripes Issue Type: Task Affects Versions: Release 1.5.4 Reporter: Nikolaos Ben Gunter wrote on 10/5/2010: The layout tags in 1.5.3 and earlier buffer virtually everything in memory before dumping it all out at once. I've modified the tags to stream directly to output instead, but it required a major overhaul so I'd like to have it tested thoroughly before I release 1.5.4. From the perspective of the Stripes developer, layouts should work almost exactly the same. snip I have lots of crazy test cases that work great. I just wanted people to drop in a snapshot where they're running 1.5.3 and make sure everything still works. The issues that I personally had w/ nested layouts in 1.5.4 Snapshot have been resolved with this fix. I believe in asides others have echoed this sentiment. Can we now move forward to officially release 1.5.4 (also to Maven Repo) We can always delay this release but to what end? There will always be another release to pack in more fixes or features. Who in the Stripes community agrees / disagrees? --Nikolaos -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Stripes-development mailing list stripes-developm...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-development -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] [JIRA] Created: (STS-779) Release 1.5.4 (also to Maven Repo)]
Marcus, I don't see the grounds / basis for Remi's comments and totally disagree with a nonchalant care taken for any release. *Please re-read the initial post on this thread.* Nested layouts was the main thing IMO that held back the 1.5.4 release. I reported some issues w/ nested layouts as well as provided Ben with simple reproducible tests. Ben resolved those issues a month ago and said: I have lots of crazy test cases that work great. I just wanted people to drop in a snapshot where they're running 1.5.3 and make sure everything still works. Others have made aside comments that nested layouts work for them. Cheers, --Nikolaos Marcus Kra?mann wrote: Hi, Am 09.11.2010 20:51, schrieb VANKEISBELCK Remi: Let's go. It's been too long already. And if this layout thing actually turns out to be a disaster, well, we'll fix and re-release. The release process (apart from the whole website/news etc) is really straightforward with maven now, I don't see no showstopper. A new release on the stable 1.5.x branch that possibly breaks existing applications would be a showstopper. Has there been any _qualified_ feedback for the layout changes? Greets, Marcus -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] [JIRA] Created: (STS-779) Release 1.5.4 (also to Maven Repo)]
Remi, Man... why couldn't you have just said: I agree that 1.5.4 should be released as I have no issues with it or just OK. It would have had the effect of what you and I and a number of other people are asking for... a timely release of 1.5.4... all things considered. While nothing you say is overtly wrong, you need to understand the tone and candor of your comments are alarming to some who have not had issues with nested layouts OR have not had time to test BUT who have come to expect solid releases for Stripes. I know you didn't intend any mis-direction with your comment but unfortunately not everyone will read or get every nuance of every e-mail. And yes - releases can be re-released - and we have you to thank for the Maven release piece but honestly lets not go there... agreed ;-) Anyone else have any issues with nested layouts in 1.5.4 or 1.5.4 please speak up now. Cheers, --Nikolaos VANKEISBELCK Remi wrote: Hi, The question is about the nested layouts feature that Ben included weeks ago. Remember ? He even asked for testing at that time... Not sure I remember you whining people sending anything concrete, like test cases. At least no such thing got commited in our webtests... anyway. I have been talking with Ben about it and he said that according to him the nested layouts feature is ready unless someone has a problem with it. Since no one has a problem, and since it was the feature we waited for in order to release, I suggested to go for it. We're not gonna spend months with this stuff. Many people is waiting for 1.5.4 to be officially released. If you're not, well, just stick to 1.5.3. Also, many people have tried out the 1.5.4-SNAPSHOT version. So I don't think there's any reason to panic here... Now for the if it has a problem we'll release again : that's what every software does, isn't it ? I mean, there are bugs, we fix them, we release... Moreover, now that releasing into maven central is a one-command operation or almost, I don't see the problem. Even a critical issue (which doesn't seem to be the case for now) would not really serious : just rollback and keep 1.5.3 in the meantime we fix the bug. Don't make me wrong : I don't say it's classy to release with a blocker. But it ain't classy to wait forever either, and again, 1.5.4 has already been out for a while as a SNAPSHOT so it should be tested the best we can... Sometimes, you just need balls :P Anyway, unless you guys have a problem with the layouts thing, I don't see why you complain. No layout problem found ? Well, let's go. That was my point. Cheers Remi 2010/11/9 gshegosh g...@karko.net mailto:g...@karko.net W dniu 09.11.2010 22:29, Nikolaos Giannopoulos pisze: What is the issue you have with the 1.5.4 release going live? Personally I have no issue with 1.5.4 release going live since it works splendidly for me on Glassfish 3 even with my quirky CMS stuff based on layouts. What I have disagree with is the approach that Remi seems to be supporting: And if this layout thing actually turns out to be a disaster, well, we'll fix and re-release. In my opinion, either the feature is working, or it's out of the release. I'm not current with the state of layout tags modifications, if they are confirmed to be working, let 1.5.4 be released; I based my previous post on that single sentence which could suggest they are NOT fully confirmed to be working. -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director of Information Technology BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] [JIRA] Created: (STS-779) Release 1.5.4 (also to Maven Repo)]
Samuel, I think we need to strive for compatibility with a officially released GA versions of software... If JBoss 6 is not GA... is it a legitimate reason to hold back 1.5.4? IMHO... No. What if we fix Stripes and JBoss 6 is altered before GA... do we again delay 1.5.4? In fact, we can have this same conversation about any version of software that has not gone GA. I understand your issue and how serious it is to you but we have to draw a line in the sand somewhere. Again this is IMHO. Unfortunately, I can't help you with JBoss 6 as I have no experience with that particular App Server (many others but not that one) but what would help immensely towards getting issues resolved in a release is trying to figure out the issues and possibly even developing a patch OR at least working on the issues sufficiently that the problem is clearly understood and can be remedied. I did look at your tickets though and in this specific case, it appears that your JBoss 6 version can not find ActionBeans. Sounds pretty broken. But also appears weird that it would have anything to do with Stripes at this point... i.e. I would expect the issue to have something to do with JBoss more than Stripes as really Stripes has no dependency on any functionality specific to a particular App Server and runs fine on anything J2EE... and that tips the scale for me to not wait for this particular issue... as tempting as it may be... there will always be something to fix. Again... others can chime in with their opinion. As far as time line for 1.5.5 or 1.6 is concerned I can't speak to that either... but I imagine for every day 1.5.4 is not released that probably pushes out a potential release of 1.5.5 or 1.6 b/c all we essentially are doing is sitting on our hands and waiting... for what... who knows ;-) My 2 cents... and others may disagree... . --Nikolaos Samuel Santos wrote: Currently Stripes is not working with JBoss 6. This is a very serious issue to me. Shouldn't we try to fix it before releasing version 1.5.4? How much will we have to wait until version 1.5.5 or 1.6? Will they be out in time for JBoss 6 GA? We have 3 open issues related to this - STS-773, STS-775 and STS-776. Cheers, -- Samuel Santos http://www.samaxes.com/ On Wed, Nov 10, 2010 at 12:20 AM, Nikolaos Giannopoulos nikol...@brightminds.org mailto:nikol...@brightminds.org wrote: Remi, Man... why couldn't you have just said: I agree that 1.5.4 should be released as I have no issues with it or just OK. It would have had the effect of what you and I and a number of other people are asking for... a timely release of 1.5.4... all things considered. While nothing you say is overtly wrong, you need to understand the tone and candor of your comments are alarming to some who have not had issues with nested layouts OR have not had time to test BUT who have come to expect solid releases for Stripes. I know you didn't intend any mis-direction with your comment but unfortunately not everyone will read or get every nuance of every e-mail. And yes - releases can be re-released - and we have you to thank for the Maven release piece but honestly lets not go there... agreed ;-) Anyone else have any issues with nested layouts in 1.5.4 or 1.5.4 please speak up now. Cheers, --Nikolaos VANKEISBELCK Remi wrote: Hi, The question is about the nested layouts feature that Ben included weeks ago. Remember ? He even asked for testing at that time... Not sure I remember you whining people sending anything concrete, like test cases. At least no such thing got commited in our webtests... anyway. I have been talking with Ben about it and he said that according to him the nested layouts feature is ready unless someone has a problem with it. Since no one has a problem, and since it was the feature we waited for in order to release, I suggested to go for it. We're not gonna spend months with this stuff. Many people is waiting for 1.5.4 to be officially released. If you're not, well, just stick to 1.5.3. Also, many people have tried out the 1.5.4-SNAPSHOT version. So I don't think there's any reason to panic here... Now for the if it has a problem we'll release again : that's what every software does, isn't it ? I mean, there are bugs, we fix them, we release... Moreover, now that releasing into maven central is a one-command operation or almost, I don't see the problem. Even a critical issue (which doesn't seem to be the case for now) would not really serious : just rollback and keep 1.5.3 in the meantime we fix the bug. Don't make me wrong : I don't say it's classy to release with a blocker. But it ain't classy to wait forever either, and again, 1.5.4 has already been out for a while as a SNAPSHOT so it should be tested the best we can
Re: [Stripes-users] [JIRA] Created: (STS-779) Release 1.5.4 (also to Maven Repo)]
Freddy, The point wasn't that anyone got offended... but rather that some got alarmed by the comment w.r.t. disaster and started jumping all over it. As I mentioned in another post... I don't think that is what Remi intended to say... . The unfortunate thing is that the nested layout problem reference is a red herring... and for me that was the bigger issue. I don't think there is any doubt that Remi wants this released and released properly just like the rest of us. In any event, just wanted to clarify that... . --Nikolaos Freddy Daoud wrote: While nothing you say is overtly wrong, you need to understand the tone and candor of your comments are alarming to some... ...unless know Rémi, and then you know not to get offended :) Seriously people, unless someone calls you a !(*$? !*$?!, don't get offended. At least not on the Stripes mailing list. We're all friendly here and I have yet to see anyone actually directly and nastily insult another. Too often, offense is taken where none was intended, by the unfortunately toneless nature of plain text. Cheers, Freddy -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] [Stripes-dev] Stripes 1.5.4 released
Ben, That is great news! I know the entire Stripes community appreciates your instrumental involvement in the 1.5.4 release. When you get a chance can you please also close the following :-) http://stripesframework.org/jira/browse/STS-779 Thanks Again, --Nikolaos Ben Gunter wrote: It's available from Sourceforge now, and it should sync to Maven central soon. Here's a list of changes since 1.5.3: http://stripesframework.org/jira/browse/STS?report=com.atlassian.jira.plugin.system.project:changelog-panel -Ben -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Stripes-development mailing list stripes-developm...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-development -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] ActionBean and PageOnLoad
Mike,
What you are looking for and more is covered in Freddy Daoud's book on
Stripes.
The mechanism you are looking for is as follows:
s:url var=url
beanclass=org.test.ui.web.action.view.support.MenuViewHelper
prependContext=false
s:param name=currentSection value=${currentSection} /
/s:url
jsp:include page=${url} /
There is a lot happening there so have fun... and get the book (it goes
into more detail on how the sections can be represented using enums and
localization and more)... its well worth it... .
--Nikolaos
dimension123 dimension123 wrote:
Hi,
I am using stripes layout to create a 'master page' of sorts. One of
the layout component (the 'header' layout) is responsible for rending
the horizontal tab menu on the page. Since this is the header, it
appears for all pages of course. I need the tabs that are displayed
to be dynamic based on user roles. For instance, If a user is Guest
vs a Registered User, the tabs will be different. If a user is an
Administrator, an Admin tab will show. etc.
My base actionbean has a method that that delegates to a
SecurityService that can determine which roles a user has. The issue
i'm having is how to do this the 'right' way. Right now, when you
first land on a page, it does not appear as though there is a way to
invoke an actionbean method. This seems to happen only if you submit
the page or if you use a url that is bound to the actionbean (i.e.
/MyActionBean.action). It seems as though the ActionBean does not
really come into scope until that happens.
Is there away to make an actionbean come into scope when a page is
first loaded?
Is there away to bind an actionbean to a stripes layout component such
that, in the case described above, that action bean will always be
available to the web application (given that the header is always
displayed)?
If i can do that, i figure i would have what i need to solve the problem.
Are there other ways anyone can recommend to solve this problem?
thanks,
Mike
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] CryptoUtils standalone
Keith, The issue below is not about CryptoUtil but more so b/c Stripes requests must go through StripesFilter / DMF... . Considering one can run JUnit or TestNG cases using MockServlet objects I imagine you can do something similar. --Nikolaos Keith wrote: Hi, We have a stripes web application. We now wish to re-use some of the functionality of the web application in a standalone java program without re-writing the code. The problem we are facing is that the web-application uses the CryptoUtils class to encrypt/ decript some values. When this is run from a standalone program we get the error below. Is it possible to use the CryptoUtil in standalone mode, perhaps by Mocking certain objects, or injecting a Configuration instance. Cheers, Keith ERROR: net.sourceforge.stripes.controller.StripesFilter - net.sourceforge.stripes.exception.StripesRuntimeException: Something is trying to access the current Stripes configuration but the current request was never routed through the StripesFilter! As a result the appropriate Configuration object cannot be located. Please take a look at the exact URL in your browser's address bar and ensure that any requests to that URL will be filtered through the StripesFilter according to the filter mappings in your web.xml. at net.sourceforge.stripes.controller.StripesFilter.getConfiguration (StripesFilter.java:161) at net.sourceforge.stripes.util.CryptoUtil.decrypt(CryptoUtil.java:181) ... -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] ActionBean and PageOnLoad
Mike,
MenuViewHelper is an ActionBean (sorry if the name is a little
deceiving). s:url constructs a URL to the ActionBean and the
jsp:include includes the ActionBean which essentially processes the
default handler on the ActionBean and forwards to a a JSP.
Instead of building a menu in the JSP do whatever you like with your
tabs and authorization. It really doesn't matter whether its a menu or
tabs its the idea that is key i.e. what I gave you was the key part
which is how to inline / embed the output of the view of an ActionBean
inside a JSP.
Simply place the block I gave you below within a layout-component tag in
a nested layout and render and voila you are golden.
What do you feel is still missing?
--Nikolaos
dimension123 dimension123 wrote:
Nice. I had actually ordered that book this morning before even
posting my question. I was hoping for a solution before the book gets
here however.
In my case i'm not really trying to build a menu, but rather tabs. To
do that, i feel i need a way to be able to reference an actionbean
from the layout component that is always visible and when pages are
loaded rather than submitted. That way i can either call a method on
the actionbean to determine if the current user is entitled or not to
view certain areas of the page.
Not quite sure yet how to do it.
On Sat, Nov 6, 2010 at 8:29 PM, Nikolaos Giannopoulos
nikol...@brightminds.org mailto:nikol...@brightminds.org wrote:
Mike,
What you are looking for and more is covered in Freddy Daoud's book on
Stripes.
The mechanism you are looking for is as follows:
s:url var=url
beanclass=org.test.ui.web.action.view.support.MenuViewHelper
prependContext=false
s:param name=currentSection
value=${currentSection} /
/s:url
jsp:include page=${url} /
There is a lot happening there so have fun... and get the book (it
goes
into more detail on how the sections can be represented using
enums and
localization and more)... its well worth it... .
--Nikolaos
dimension123 dimension123 wrote:
Hi,
I am using stripes layout to create a 'master page' of sorts.
One of
the layout component (the 'header' layout) is responsible for
rending
the horizontal tab menu on the page. Since this is the header, it
appears for all pages of course. I need the tabs that are displayed
to be dynamic based on user roles. For instance, If a user is
Guest
vs a Registered User, the tabs will be different. If a user is an
Administrator, an Admin tab will show. etc.
My base actionbean has a method that that delegates to a
SecurityService that can determine which roles a user has. The
issue
i'm having is how to do this the 'right' way. Right now, when you
first land on a page, it does not appear as though there is a way to
invoke an actionbean method. This seems to happen only if you
submit
the page or if you use a url that is bound to the actionbean (i.e.
/MyActionBean.action). It seems as though the ActionBean does not
really come into scope until that happens.
Is there away to make an actionbean come into scope when a page is
first loaded?
Is there away to bind an actionbean to a stripes layout
component such
that, in the case described above, that action bean will always be
available to the web application (given that the header is always
displayed)?
If i can do that, i figure i would have what i need to solve the
problem.
Are there other ways anyone can recommend to solve this problem?
thanks,
Mike
--
The Next 800 Companies to Lead America's Growth: New Video
Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
mailto:Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen
Re: [Stripes-users] Stripes Clean URLs
Martin,
Comments in-line...
Martin Walsh wrote:
Nope, same issues described below.
M
On 11/ 5/10 01:39 PM, Ben Gunter wrote:
Please try 1.5.3 and see if that helps.
-Ben
On Fri, Nov 5, 2010 at 9:27 AM, Martin Walsh martin.wa...@oracle.com
mailto:martin.wa...@oracle.com wrote:
I am running into a few issues with clean URLs. I am using Stripes 1.5.2
and Tomcat 6.0.26.
I am attempting to use clean URLs with parameters that represent a file
path.
e.g.
binding = /action/test/{path}
parameter = String path = tmp/test.txt
I am using the stripes:link tag to generate the link on a JSP page using
the path variable. I am currently running into two issues.
Firstly, the link generated is escaped, escaping the '/'. This results
in a link of http://localhost:8080/test/action/test/tmp%2Ftest.txt. When
clicked on, Tomcat returns a error 400 (Bad Request). The request does
not even make it through to Stripes.
That appears to be encoded properly. Is the URL correct i.e. have you
tried simply going to:
http://localhost:8080/test/action/test/tmp_test_txt
Otherwise it seems quite bizarre. The other thing I would suggest is
perhaps setting up a root binding like /action and then in debug mode
see what the request looks like that may be tripping up Stripes and not
matching.
Secondly, if the parameter includes a special char, i.e. a space.
e.g.
parameter = String path = test file.txt
the link is encoded, which gives
http://localhost:8080/test/action/test/test+file.txt. However the
parameter is not decoded, so in my action bean, the path variable is
test+file.txt instead of test file.txt.
That isn't totally surprising to me. Just use:
java.net.URLDecoder.decode(string, encoding);
In say the setPath(...) method as you expect that you might have a case
wherein the parameter has encoded characters.
HTH,
--Nikolaos
Thanks in advance for any help.
M
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes Clean URLs
Martin, Comments in-line... Martin Walsh wrote: Thanks Nikolaos. Response in-line... That appears to be encoded properly. Is the URL correct i.e. have you tried simply going to: http://localhost:8080/test/action/test/tmp_test_txt The URL would be correct if the %2F was a '/'. i.e. The following works: http://localhost:8080/test/action/test/tmp/test.txt But with the final '/' being encoded because it is technically a parameter, it results in a request of http://localhost:8080/test/action/test/tmp%2Ftest.txt This request then does not even make it to Stripes. Tomcat just returns a 400 error, before it even invokes Stripes. So I think the question really is, which side is wrong. Tomcat not even trying to handle the URL, or Stripes encoding the '/' when generating the clean URL. How do you know it isn't making it to Stripes? Personally I think part of the issue is that you are trying to inject data that can have spaces or slashes or whatever as part of a base URL. Typically that would be part of a parameter. How about if you did something like: http://localhost:8080/test/action/test?file=tmp%2Ftest.txt i.e. create a link with a parameter called file? I know that changes things slightly but that makes more sense to me. Secondly, if the parameter includes a special char, i.e. a space. e.g. parameter = String path = test file.txt the link is encoded, which gives http://localhost:8080/test/action/test/test+file.txt. However the parameter is not decoded, so in my action bean, the path variable is test+file.txt instead of test file.txt. That isn't totally surprising to me. Just use: java.net.URLDecoder.decode(string, encoding); In say the setPath(...) method as you expect that you might have a case wherein the parameter has encoded characters. I can do that as a fix for now. Should this not be fixed in Stripes though? I would imagine there is a reason why Stripes does not URL decode every single parameter... and personally I would not want it to... as having to URL decode data is not often a requirement and would be an often needless performance penalty i.e. often clear text with spaces et al. is collected via a form POST wherein it doesn't matter how the data is formatted. So... No I don't think this is a bug. I think you are simply combining data that doesn't belong in a base part of a URL normally - and most often gets form POST'ed - into a URL and then having this issue. Said differently I think what you are trying to do is a little odd ;-) --Nikolaos -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Source forge description: It's stripey and itdoesn't suck
Don't want to interrupt this brain storming on missing but after having experienced so many other frameworks my thoughts about Stripes were wow... It does so much more for you that you actually write less code. Moreover it does things smarter than other frameworks so you end up writing less code. SO how about a play on Java's write once; run anywhere. Stripes: write less; run smarter. OR Stripes: write less; run more. :-) --Nikolaos Oscar Westra van Holthe - Kind wrote: On 29-10-2010 at 16:37, jfonta...@codegap.com wrote: Stripes: the missing link? ;) Better. Oscar -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Odd Clean URL Binding??? (1.5.4 Snapshot)
Nathan,
No. The +1 wasn't for adding {_eventName}... it was for using
{_eventName} instead of {$event} which already works as a param but also
works in URL binding.
That is to say the following are synonymous:
@UrlBinding(/share/{id}/{titleUrlified}/{_eventName})
and
@UrlBinding(/share/{id}/{titleUrlified}/{$event})
... and I agree w/ Samuel and have chosen the former just as it makes
things all the more clearer (and is less prone to the EL typo)
--Nikolaos
Nathan Maves wrote:
I don't see an issue adding this new magic name but we would need to
keep the old one as well to maintain backwards compatibility.
Nate
On Thu, Oct 28, 2010 at 6:59 PM, Samuel Santos sama...@gmail.com
mailto:sama...@gmail.com wrote:
+1 for {_eventName}
--
Samuel Santos
http://www.samaxes.com/
On Fri, Oct 29, 2010 at 1:14 AM, Joaquin Valdez
joaquinfval...@gmail.com mailto:joaquinfval...@gmail.com wrote:
I have always been partial to the ~
Joaquin
On Oct 28, 2010, at 5:11 PM, Freddy Daoud wrote:
You are both correct. Indeed perhaps something like
{#event} would
have been better. Hindsight is always 20-20.
I realize I'm probably the only one who would like this, but
I would
have used {_eventName} because that special request parameter is
already being used for the event name. So, one less
magical thing
to learn.
Freddy
--
Nokia and ATT present the 2010 Calling All Innovators-North
America contest
Create new apps games for the Nokia N8 for consumers in
U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly
$6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish
to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
mailto:Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Joaquin Valdez
joaquinfval...@gmail.com mailto:joaquinfval...@gmail.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Odd Clean URL Binding??? (1.5.4 Snapshot)
Hi,
We have the following:
@UrlBinding(/share/{id}/{titleUrlified}/${event})
Where id is a Long and titleUrlified is a String
When we test the following url:
/share/0/anything/edit
We get the following binding:
id=0
titleUrlified=anything/edit
and the @DefaultHandler view() method gets invoked vs. the edit() method
Why is titleUrlified NOT set to anything? Why is the binding so
aggressive?
Hopefully I am doing something silly. Anyone
--Nikolaos
P.S. I haven't tested 1.5.3 (yet)... as it is quite a pain to switch
between the 2... (at the moment)
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Source forge description: It's stripey and it doesn't suck
Many take from the word simple alone to imply not feature rich. So adding some sort of qualifier is great but I am not sure that complete is the word. Nothing in software is ever complete unfortunately. (Not trying to start a flame war with those that believe Stripes is complete... I just don't think it is complete... heavily feature rich - sure... complete - No - IMHO). Just my 2cents... --Nikolaos Joaquin Valdez wrote: I like it! On Oct 28, 2010, at 1:31 PM, Evan Leonard wrote: the other thing that people keep talking about is how Stripes is (or nearly is) feature complete. So how about: Stripes - simple complete. On Oct 28, 2010, at 2:26 PM, Søren Pedersen wrote: What about: Stripes - because it's simple Den 28/10/2010 22.14 skrev Nikolaos Giannopoulos nikol...@brightminds.org mailto:nikol...@brightminds.org: On a more serious note... I agree with Karen. In fact... IMO its always better in marketing to differentiate yourself (and speak to your audience) with what you do well... How about something like: Stripes: The robust and intuitive Java web framework --Nikolaos 2010/10/28 Freddy Daoud xf2...@fastmail.fm mailto:xf2...@fastmail.fm mailto:xf2...@fastmail.fm mailto:xf2...@fastmail.fm On the source forge page of Stripes I see the text: Source forge descript... mailto:Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users --... -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net mailto:Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users Joaquin Valdez joaquinfval...@gmail.com mailto:joaquinfval...@gmail.com -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Dual Form... Log-in and Sign-up
Hi, Just about to build a horizontally split Log-in / Sign-up form and I was thinking... The Log-in form entails a simple user name and password The Sign-up form entails a wizard like interface for a multi-page set of forms I am considering 2 options: 1) 2 ActionBeans... the LoginActionBean presents both forms by default and validates and processes Login requests AND the SignupActionBean takes some initial information and starts the Sign-up process (first, last, email, password) and continues the process in the SignupActionBean... However, what if the e-mail address in the Sign-up isn't formatted correctly... it doesn't seem right to bounce back to the LoginActionBean 2) Have an initial ActionBean that presents the 2 forms and have the forms post to either of 2 independent ActionBeans... However, once again on validation both beans need to direct back to this initial ActionBean. I wonder if the 2nd ActionBean being a wizard if I am going to come across any issues... . I know that splitting the forms into 2 separate pages is obviously the simple solution but alas requirements are otherwise... . Any pointers on how others have tackled or would tackle such a problem? Thanks, --Nikolaos -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Good News:: JRebel working again for 1.5.4 Snapshot (and still for 1.5.3)
All, The latest Nightly Build of JRebel contains an updated Stripes plug-in that resolves the issue I faced with UrlBindingFactory.getInstance() not being available in Stripes 1.5.x (going forward). Essentially the solution entails: 1) abstracting calls to UrlBindingFactory.getInstance() to a separate method 2) trapping NoSuchMethod exceptions on calls to UrlBindingFactory.getInstance() and then through reflection code attempting instead: ((UrlBindingFactoryProvider)nameBasedActionResolver).getUrlBindingFactory() The next release after the current 3.1.2a release will contain this update until then the Night Build works fine. Cheers, --Nikolaos -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Nested indexed property question
Nathan,
Are you asking that you would expect:
foo[0].bar=abc
foo[1].bar=abcd
foo[2].bar=
foo[3].bar=abcde
To end up as:
foo[0].bar=abc
foo[1].bar=abcd
foo[2].bar=abcde
Although that's possible I don't think Stripes should be the one
deciding that the 3rd value of null should simply be discarded. I would
prefer to post-filter myself in the action bean which thus allows having
both possible outcomes.
BTW while some collections do not allow null values many do IIRC.
Cheers,
--Nikolaos
Nathan Maves wrote:
In my case there are no required validations.
On Fri, Oct 22, 2010 at 3:16 PM, Joaquin Valdez
joaquinfval...@gmail.com mailto:joaquinfval...@gmail.com wrote:
Hello!
I would say it depends on the validation being used on the List of
Foo objects.
For example:
@ValidateNestedProperties({
@Validate(field = bar, required = true),
@Validate(field = bar1, required = true),
@Validate(field = bar2, required = true),
@Validate(field = bar3, required = true),
@Validate(field = bar4, required = true),
@Validate(field = bar5, required = true)
})
private ListFoo foos;
Hope that helps! The bazooky example shows this concept quite
clearly.
Joaquin
On Oct 22, 2010, at 1:39 PM, Nathan Maves wrote:
Give the following parameter
foo[0].bar=abc
foo[1].bar=abc
foo[2].bar=
foo[3].bar=abc
I would expect the CollectionFoo in my action to have a size
of 3. Instead I get a size of 4 where one of the items in the
collection is null.
Is this the correct behavior?
Nathan
--
Nokia and ATT present the 2010 Calling All Innovators-North
America contest
Create new apps games for the Nokia N8 for consumers in U.S.
and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M
in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to
Ovi Store
http://p.sf.net/sfu/nokia-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
mailto:Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Joaquin Valdez
joaquinfval...@gmail.com mailto:joaquinfval...@gmail.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] CleanUrl bug from 1.5.1+ when using MockRoundtrip
Nathan,
We have limited test cases for our Action Beans at this time. So far no
issues.
Could you be more specific about the error that is being produced.
--Nikolaos
Nathan Maves wrote:
Is there anyone else out here using UrlBinding with MockRoundTrip?
This is killing me that we can upgrade to the latest Stripes codebase.
Nathan
On Wed, Oct 13, 2010 at 11:32 AM, Nathan Maves nathan.ma...@gmail.com wrote:
We have multiple test cases where we are using UrlBinding with 1.5 and
everything works perfect.
Here is an example of one of our bindings
@UrlBinding(/admin/product/{$event}/{product.id})
All versions (1.5.1, 1.5.2, 1.5.3) work fine outside of the test
fixture. It is only within a test using the MockRoundTrip where we
get the error. The error is a validation error where it claims to
have a conversion issue where the replacement parts are [Product Id,
{product.id}]. We get this when passing in a parameter or not.
I did find the following change from 1.5 to 1.5.1 that might have
something to do with it.
http://www.stripesframework.org/jira/browse/STS-592
Nathan
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Keeping the Stripes ball moving forward
All, I have tested the nested layouts of 1.5.4 and everything appears to be working fine. Excellent job Ben I also have contacted the Zero Turn Around folks that make JRebel and raised the issue w/ their broken Stripes plug-in for 1.5.x / 1.6.x due to the code usage change of UrlBindingFactory - from singleton to local instance. I am hoping to work w/ them to find a way to get JRebel working with Stripes again. Until that time can we hold off releasing 1.5.4 just in case something else is required to help things work. I know one normally does not tailor a framework to the tools around it but I am worried that the hook it had / needs may no longer be available to it. As JRebel supports a ton of other frameworks I think its important that we try to maintain its ability to support Stripes. Will let everyone know how things progress... . --Nikolaos amagha wrote: Folks -- As many of you know, we've had a lengthy discussion (that continues) about Stripes and its future. This includes fresh blood in leadership, a new website, and greater contribution and participation by the larger community. To this last point (participation), please note that Ben is trying to get us all to a newer version of Stripes (v1.5.4), and is soliciting help/input. Please see his Sep. 29th post entitled http://old.nabble.com/Streaming-layouts-(again)-to29842130.html Streaming layouts (again) . During the lengthy thread on Stripes and its future (see http://old.nabble.com/IMPORTANT::-Developing-stripes-(Future...-Part-DEUX)-to29747051.html here ), many people chimed in and stated they'd be willing to participate and help out when needed. Its times like this--when Ben is trying to move Stripes forward--that your help is needed! Please check out 1.5.4, per Ben's request, and report back success and/or failure so Ben hears back from the same community that's both passionate about Stripes and indicated just a couple of weeks ago that they wanted to help. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] Associating Parameters to Specific Actions
Evan / Christian / Remi et al.
This thread is very interesting and I am enjoying it... and hope it
continues...
However, can we rename this thread to something more aligned to the
discussion?
If no one minds I have taken the liberty to rename it to the above ;-)
Regards,
--Nikolaos
Evan Leonard wrote:
Here's an interesting approach from the waffle framework. It uses
annotations, but lists all the parameter names in a single annotation.
@ActionMethod(parameters = {firstNumber, secondNumber})
Evan
On Oct 5, 2010, at 6:48 AM, Poitras Christian wrote:
It's a problem that we faced in MyBatis when dealing with multiple
parameters. We went with the annotation approach.
I guess there are many workarounds for that and Spring is probably using
one. Debug seems like a good workaround.
Christian
-Message d'origine-
De : Freddy Daoud [mailto:xf2...@fastmail.fm]
Envoyé : October-05-10 8:40 AM
À : Stripes Users List
Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
Are you sure? I think that if you compile with debug info turned
on, and your request parameters are named param1 and param2,
they will be bound correctly without the need for the annotations.
Or is that what you meant by you will need the source code?
Cheers,
Freddy
On Tue, 5 Oct 2010 08:36:43 -0400, Poitras Christian
christian.poit...@ircm.qc.ca said:
A problem with the Spring approach is that parameter names are not
accessible by reflection.
The consequence is that if you have method like
public void substract(int param1, int param2)
It will be difficult to pass the parameters in the right order. You will
need either the source code to find the parameter names or an annotation
like
public void substract(@Param(param1) int param1, @Param(param2) int
param2)
Stripes is not affected by that problem.
Christian
-Message d'origine-
De : Evan Leonard [mailto:evan.leon...@gmail.com]
Envoyé : October-04-10 4:59 PM
À : Stripes Users List
Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
+1. Though it will take one of us being dissatisfied *enough* to
implement this ourselves :-)
On Oct 2, 2010, at 9:05 PM, Simon wrote:
In other words, in Stripes you'd have
private User user;
/* getters and setters */
public Resolution save() {
// do something with user
}
In Spring MVC you'd have
public void save(User user) {
// do something with user
}
The do somethings in both Stripes action beans and Spring controllers
are
best left to injected helpers, daos, and so on, keeping the
action/controller
classes simple.
So, in that respect, I'm not sure that using local variables leads to more
complex procedural code, if you keep things simple in controllers.
The main drawback to the Stripes approach is that if you have multiple
handlers on a single action it becomes ambiguous which bean properties
are inputs to each action. When they are arguments to the handler
method it is super clear what applies where. I wouldn't mind
sometimes if Stripes supported either approach - why not just look for
any method that returns Resolution and then if there are parameters,
try to bind them, if you can? (yes, you probably need annotations to
tell you the name to bind on, but I can live with that)
Cheers,
Simon
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Stripes and charset UTF-8
Luis,
AFAIK anything outside of the layout-definition tag will not be involved
in rendering.
So although its perfectly fine to put your taglibs include file there
(b/c it doesn't really render anything) putting your language encoding
there should basically make it as if the tag was never included in the
1st place and your results are to be expected AFAIK.
Try the following:
%@ include file=/WEB-INF/jsp/common/taglibs.jsp%
s:layout-definition
%@ page language=java contentType=text/html; charset=UTF-8
pageEncoding=UTF-8%
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
and let us all know if this helps or if I'm out to lunch... ;-)
--Nikolaos
Luis Castro wrote:
Hello,
I'm testing Stripes 1.5.3 with Apache Tomcat 6.0.20 and I have a
layout_main.jsp with s:layout-definition tag.
When I request a page generated by Stripes, Tomcat sends this to the
browser:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=EB09B410B8D18F4AACBEA52E270F6ABF;
Path=/TestStripes15
*Content-Type: text/html *
Content-Language: es-CR
Transfer-Encoding: chunked
Date: Sat, 25 Sep 2010 14:46:36 GMT
And when I request a jsp file not generated by Stripes, I get
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
*Content-Type: text/html;charset=UTF-8 *
Content-Length: 498
Date: Sat, 25 Sep 2010 14:47:17 GMT
It seems the charset=UTF-8 is missing when the page is generated by
Stripes. The header of my layout_main.jsp is as follows:
%@ page language=java contentType=text/html; charset=UTF-8
pageEncoding=UTF-8%
%@ include file=/WEB-INF/jsp/common/taglibs.jsp%
s:layout-definition
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=UTF-8 /
title${title}/title
I have tried several combinations: putting the DOCTYPE below and
after the s:layout_definition tag with no success.
Any advise will be appreciated.
Luis.
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Nikolaos Giannopoulos
Director, BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] database connection
Frank, Frank Pavageau wrote: On Fri, Sep 24, 2010 at 2:46 AM, Nikolaos Giannopoulos nikol...@brightminds.org wrote: Huh, no. The socket that is closed is the one to the PostgreSQL server, not the one to the browser. There's no application code trying to write the HTTP response in the stack between the entry point in Hibernate and the throw of the exception in the PSQL JDBC driver, hence no opportunity to write on the browser's socket. Your right. I missed the underlying: [16/Sep/2010:09:38:15] info ( 2360): CORE3282: stdout: Caused by: java.net.SocketException: Connection reset by peer: socket write error ... [16/Sep/2010:09:38:15] info ( 2360): CORE3282: stdout:* at org.postgresql.core.PGStream.flush(PGStream.java:508)* [16/Sep/2010:09:38:15] info ( 2360): CORE3282:* *stdout: * at org.postgresql.core.v3.QueryExecutorImpl.sendSync(QueryExecutorImpl.java:676)* [16/Sep/2010:09:38:15] info ( 2360): CORE3282: stdout: *at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191)* If it were a connection closed message, I'd say that PSQL sets a TTL on its connection like MySQL does, but the connection reset by peer looks like a firewall between the application and the DB which has lost track of the open connection, due to it staying idle too long. Or maybe Java hasn't noticed that the connection was closed earlier and is now only getting a reset status. I agree. That's why I asked if a load balancer was being used in my 1st reply. Cisco and IIRC Big IP for example default to time out idle connections at 16 seconds which is great for HTTP but can be disastrous to any connection pool that comes under heavy or bursts of load. The question is equally valid if there are any firewalls. Anyway, to mitigate that, you could set your connection pool to close connections that have stayed idle too long. And actually it seems your c3p0 is at least partially configured to do so with the c3p0.idle_test_period parameter. I don't use it and don't know it, but isn't there another parameter to declare the max idle time which doesn't have a decent default value ? With DBCP (the standard pool used by Tomcat but also usable directly through Hibernate, as c3p0 is here), a typical configuration to do that would be (somewhat matching yours) : maxActive = 20 maxIdle = -1 minIdle = 5 maxWait = 100 minEvictableIdleTimeMillis = 30 (5 minutes idle before getting closed) timeBetweenEvictionRunsMillis = 3 (check every 30 seconds for idle connections to close) However, since you're getting connection resets, I'd really set minIdle (or c3p0.min_size) to 0, since keeping 5 connections opened no matter what could keep some opened forever, while the DB closes it on the other end, be it because of a time to live or a time to idle setting. Once your application sees some activity again, it can probably wait for the time to re-establish a connection. Unless it only sees short bursts of intense activity, in which case you might want to change the setting on the DB side. Since he is getting connection resets shouldn't he try to determine why they are happening and correct that vs. finding ways for his pool to stay empty? In my experience if you don't truly figure out why these things are happening they won't go away and will bite you down the road... a day, a week, a month, a year later... but they typically need to be understood and resolved. Perhaps its a good temporary measure but I would be more interested in seeing it happen again and collecting as much diagnostic information as I can from the OS, the network, the processes, etc... - essentially a snapshot of state of all related components in time - as I mentioned in the other reply than trying to figure out how to tweak your connection pools so as to inhibit this issue from surfacing... . Just an opinion of course. --Nikolaos Frank -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Security and Authentication
Thomas, Look at the ticket that Grzegorz referenced. You have essentially 2 options: - Put a little extra xml in your web.xml (what I call a work around in the thread) - Get the DynamicMappingFilter.java file from 1.5.x... In any event its all detailed there. I personally did the latter and created my own 1.5.3.1 jar. --Nikolaos P.S. Searching the mailing list really helps as this issue has come up quite a few times Grzegorz Krugły wrote: W dniu 22.09.2010 16:09, Thomas Menke pisze: Grzegorz Krugły wrote: What app server are You using? Current release of Stripes failed for me like that on Glassfish 3, I had to download the newest code from SVN's 1.5.4 branch where this has been resolved. I am using Tomcat 6.0.24 (installed from Ubuntu repository). Perhaps You could try checking out Stripes version from SVN from this branch: https://stripes.svn.sourceforge.net/svnroot/stripes/branches/1.5.x/ The build is maven-based so it's quite easy; opening it in NetBeans allowed me to build it just by Shift-F11. As I said, I had this trouble in Glassfish 3, there's a ticket (http://www.stripesframework.org/jira/browse/STS-678) that says the same is in WebSphere, perhaps Tomcat 6 has the same kind of optimizations that made old DynamicMappingFilter fail? It's fixed by Ben in the 1.5.x branch. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] database connection
/ property name=hibernate.connection.password value=xx/ property name=hibernate.connection.url value=jdbc:postgresql://localhost/joaquinv_cheap/ -- property name=hibernate.hbm2ddl.auto value=update/ /properties /persistence-unit /persistence Thanks! Joaquin -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director, BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] database connection
-- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- Nikolaos Giannopoulos Director, BrightMinds Software Inc. e. nikol...@brightminds.org w. www.brightminds.org t. 1.613.822.1700 c. 1.613.797.0036 f. 1.613.822.1915 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
[Stripes-users] IMPORTANT:: Developing stripes (Future... Part DEUX)
Ben, You have made it clear that you needed to get away from the code back in June after having made a flurry of commits. Everyone understands and appreciates what you have done for Stripes as you have single handedly maintained Stripes for quite some time (I assume since its beginnings with Tim) and have been an incredible driving force IMO. But the time of a single developer cobbling together code OR merely accepting patches that are ready and tested from the community - but not having the time to integrate them - must be over. At some point in time we need to stand aside to see a project grow otherwise we will - and not to be dramatic - smother it and indeed it will die... . There are developers like Evan, Nicolai, myself (down the road) and others in the wings (whose names I don't have readily with me but have voiced themselves already) that are ready to get involved **today** and / or contribute their extensions that they have built for their real world projects... and yet the lack of response to requests on how to get involved is quite unsettling to say the least. Another area... 1.5.3 was released on December 16, 2009 yet a full 9 months later it still does not appear in Maven Central. One suggested solution was to setup a Sonatype repo for Stripes so that it automatically syncs to Maven Central. In STS-738 back in May of this year you said In case you missed my note on the mailing list the other day, I'm working on getting this going through Sonatype. I'll resolve this issue when it's done. The fact that it isn't setup is not my biggest concern and is not a problem as in the end you volunteer your efforts / time. However since then others including Samuel Santos and Nathan Maves have offered to help setup a Sonatype repo for Stripes - which they both have stated they have experience doing - yet once again no reply to their offers to help. Once again this is unsettling... . This thread is by no means meant to be critical of your contributions... as they most likely overshadow everyone else's in this community for their extent and dedication. This is meant more as a wake up call to all those that hold the keys to Stripes. I assume that includes yourself, Freddy and Aaron but don't know for sure... . In my mind 3 things need to happen for Stripes to prosper: 1) Getting Stripes automatically sync'd up through Sonatype will deflect the perception that the project is stale i.e. 9 months since its last release is no big deal... not having its latest release out there where it can be *effortlessly consumed* *IS* IMO. 2) Some process needs to be setup to allow others to get into the ground floor as contributors. This OSS at its best. There are numerous talented people on this list alone that not letting go of the keys WILL kill Stripes. Period. As I personally have not led any OSS projects I am not sure what the best procedure / process to follow is nor do I know where to start but I'm sure others can chime in on how to properly initiate this. If this was truly difficult then OSS would not exist. This is *CRITICAL*. 3) All the other good initiatives that have been started need to continue like setting up a new web site, a better place for forums (mailing lists are wonderful but people search the web more often than mailing lists for quick answers), deciding on how to partition extensions, stacks, etc... (of course there is debate here), etc... But if 1) and 2) don't happen then yes not to sound dramatic Stripes will surely die... not b/c it isn't a great product... but b/c people like myself and others in the community will feel that they are beating a dead horse in trying to get involved... and will simply give up and look elsewhere. If you alienate those that the early adopters / sneezers then 3) won't matter at all. Ben, Freddy and / or Aaron... its time to step up to the plate... to if anything hand over the keys and take on a reviewer / advisor role in the future of this wonderful framework. Regards, --Nikolaos Evan Leonard wrote: Nicolai, Absolutely. This is a must. I am starting to use Stripes for a project and want to participate in the community. However, its not clear how to do so! Is it clear in the community how decisions are made about these things? Are there certain core developers with some level of authority? Forgive me as I'm just coming up to speed. Evan -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
