Re: Action path prefix rules?

[Heikki Hyyrö]

Sorry, my post obviously had a typo. I was supposed to write the link 
open tag as .


-Heikki


Heikki Hyyrö kirjoitti 14.8.2020 klo 11.47:


  


  Link to bar-action



-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Action path prefix rules?

[Heikki Hyyrö]

Hi,

I am a bit confused about the rules concerning mapping URL paths to 
actions. Let's say that I have a Struts application running at 
example.com with the app name "myApp". Then the usual path to access a 
Struts action named "foo" would presumably be


example.com/myApp/foo.action

Now, it seems to be also possible to access the foo-action even by 
adding a more or less arbitrary path prefix before the app name. E.g. 
also both


example.com/abcde/myApp/foo.action
example.com/some/bogus/prefix/myApp/foo.action

seem to access foo. I am wondering where the rules that allow this are 
defined? What would be the relevant documentation to look into?


As a specifid question, I wonder about links. If the foo-page contains 
e.g. a link created with the url-tag, such as



  


  Link to bar-action


the link does not include any "extra" path prefix and always points to 
example.com/myApp/bar.action. I am wondering why this happens? And what 
if I actually would want the link to reflect the actual access URL, 
including any "extra" path prefix (e.g. the link might point to 
example.com/some/bogus/prefix/myApp/bar.action)? Is this possible?



-Heikki


-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Passing a parameter from an interceptor to an action

[Heikki Hyyrö]

Hi,

I would like to pass a parameter from an interceptor to an action, but 
am not sure what is a proper way to do it if I also want to ensure that 
a parameter with the same name cannot be injected into the action as a 
request parameter.


I have set the interceptor to add the parameter into the valuestack, but 
this approach does not seem to work if the parameter name is included 
either in the excludeParams-parameter of the params interceptor or as a 
blocked parameter of the parameter filter. Either of these last two 
seems to prevent the parameter from being accessible by the action. If 
the params interceptor and parameter filter apply to _all_ values in the 
value stack, and not only request parameters, then is there some other 
route that allows to pass a "private" parameter from an interceptor to 
an action?


-Heikki


-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Problem reading a resource file (migrating 2.3.29 --> 2.5.10)

[Heikki Hyyrö]

11.03.2017, 09:20, Lukasz Lenart kirjoitti:

This is do the changes in ActionSupport's dependencies, you must
inject them first to have access to resource bundles.

Instead your approach with singleton you can use something like this

public class DbConnectionManager {

   public DbConnectionManager(@Inject TextProvider textProvider) {
 String driverNames = textProvider.getText("database.drivers");
 ...
   }
}

and then

public class MyAction extends ActionSupport {

   public String execute() {
 DbConnectionManager mgr = container.inject(DbConnectionManager.class)
 
   }
}

but perhaps the best option would be to disconnect your DAO layer from
Web layer, you have coupled two different layers which is a "bad
design" ™

Thanks, I will have a look at this.

I now that the particular example was a bit of a hack. 
DBConnectionManager inherited ActionSupport only for the sole purpose of 
getting easy access to the resource files (just rely on the framework to 
find it; no need to hard code any path or filename). Changing this is 
not such a big deal; something like 
DbConnectionManager.class.getResourceAsStream("package.properties") 
should work.


A related question is how to access resources from a static context. For 
example if I have an Enum whose constants are based on strings defined 
in the resource files, what would be a proper way to access them? I am 
thinking of something like:


public Enum Event
{
SOME_EVENT(0, "header.some_event"),
ANOTHER_EVENT(1, "header.another_event"),
...

private final int eventId;
private final String eventString;

private LogEvent(int id, String description)
{
eventId = id;
// How to achieve the following conversion of a generic
// header into how its defined in the resource files?
eventString = getText(string);
}
}

Is there a nice way to handle this with getText, or should I again use 
getResourceAsStream or some other non-Struts facility?


-Heikki

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Problem reading a resource file (migrating 2.3.29 --> 2.5.10)

[Heikki Hyyrö]

Hi,

I decided to migrate a Struts-based application from Struts 2.3.x to 
2.5.x. The application worked without problems with Struts version 
2.3.29. After updating to 2.5.10, the application no longer seems to be 
able to read a root-level resource file "package.properties": calling 
getText("some.needed.property") results in an exception.


Since this problem did not happen with 2.3.29, I wonder if the 2.5.x 
versions have introduced a fundamental change in how the resource files 
are handled? I was not able to find such information in the 2.3 --> 2.5 
migration guide.


The problem occurs in the constructor of a database connection manager 
class that tries to retrieve database information (driver information, 
database url, and so on) from package.properties. A rough sketch of the 
class is something like:


public class DbConnectionManager extends ActionSupport
{
  private DbConnectionManager()
  {
String driverNames = getText("database.drivers");  // This throws 
an exception in 2.5.10, but was ok in 2.3.29.

...
  }
}

I suppose this problem could have something to do with the fact that 
this is a singleton class that is initialized only once during the 
lifetime of the application? If this is the case, then what would a 
simple way to fix the problem? A related question would be: how should I 
access resource files from a non-action context (e.g. read resources in 
static initialization), if ActionSupport no longer permits it?


-Heikki


-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Mysterious(?) carriage returns

[Heikki Hyyrö]

Chris Pratt  kirjoitti 7.4.2015 kello 0.32:
> 
> I believe line breaks in HTTP are always represented as  pairs,
> regardless of the Client or Server OS's


Thanks for the tip; it helped me to look for the right thing and verify that 
HTML 4.01 specification indeed states exactly what you said: 
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 


-Heikki

Mysterious(?) carriage returns

[Heikki Hyyrö]

Hi,

I have been stumped by the following problem: newlines within text received 
from an html form show up in the form ”\r\n” in our Struts 2 -based 
application. I am wondering how this is possible because I have verified the 
following:

1) The system is running on OS X or Linux, so the OS default newline is ”\n”.

2) The Java virtual machine reports ”\n” as its newline character 
(System.getProperty(”line.separator”)) when running the Struts 2 -application 
in a debugger.

3) When inspecting the form text in a browser debugger, the text shows newlines 
in the form ”\n” just before the form is submitted. I double-checked this by 
inspecting the actual character code values.

4) When I set a breakpoint to the bean-setter of the corresponding action in 
the Struts 2 application and let the form submission from the browser be 
executed, the setter receives the form text as a String-parameter where the 
newlines have become ”\r\n”.

What can be the reason for this? The form submission mechanism (something on 
the browser-side or in Tomcat) or the way Struts 2 handles form parameters 
before feeding them to the action? I want to get rid of these extra carriage 
returns but would very much like to find some other way than writing special 
code (such as a custom parameter interceptor) for reverting the text back to 
its original form...

-Heikki
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Anyway to map properties to different request names?

[Heikki Hyyrö]

Paul Benedict  kirjoitti 5.11.2014 kello 22.54:
> It bothers me that the Java programming model dictates the parameter names.
> In theory "personId" could be sent as "a" -- although a variable named "a"
> in Java is bad naming conventions. There isn't a good technical reason to
> keep this 1:1 mapping. The shorter the bytes sent too the better And in
> reverse, if one is working on re-implementing an existing servlet/service,
> you have to give poor names to your Java model to match existing form names.


One simple (but perhaps ugly?) way is to provide also page-specific setters 
along with the usual JavaBean-setters:

// Page provides personId using the name ”a”.
public final void setA(String personId) { ... }

// JavaBean-version (if also needed)
public final void setPersonId(String personId) { ... }

-Heikki


-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Struts 2 and automatic ids

[Heikki Hyyrö]

Lukasz Lenart  kirjoitti 21.9.2014 kello 11.48:
> Can you prepare some exact example app?


Would the example snippet at the bottom be enough? It shows a slightly cleaned 
version of one form we use. The form basically consists of a table that lists 
the users of the system. Each user can be assigned to a user group. This form 
sends two arrays to the action updateGroups: one is ”userIds”, which contains 
the user ids, and the other one is ”groupIds”, which contains the group ids 
(which may be changed via the select-list in the last column).

Struts generates identical id for each input field that gives values to these 
two lists. For example if there are 500 users, the html-code output by Struts 
will contain 500 snippets that look like:



Each of these snippets will differ only in what is the value of the first 
hidden field. WWW validator will then output hundreds of errors of form 
"Duplicate ID updateUserGroups_groupIds” and "Duplicate ID 
updateUserGroups_userIds”.

In this particular case the problem might(?) go away if the form used explicit 
index notation with the array names ”userIds" and "groupIds", but as far as I 
know (e.g. based on the book Struts 2 in Action), the practice of populating 
arrays without explicit indexing is quite normal.

-Heikki




  

  Name
  Login
  Email
  Group

  
  

  

  

  
  
${user.lastName}, ${user.firstName}
  

${user.login}
mailto:${user.email}";>${user.email}

  
  

  

  


  

  




-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Html-encoding to UTF-8: hidden field vs. other fields?

[Heikki Hyyrö]

Heikki Hyyrö  kirjoitti 21.9.2014 kello 0.08:
> 
> 

Re: Html-encoding to UTF-8: hidden field vs. other fields?

[Heikki Hyyrö]

Lukasz Lenart  kirjoitti 21.9.2014 kello 11.32:
> 
> Missing encoding declaration?


Both forms are based on the same page-template that has



in the page header.

Is this not enough? Did you mean some other declaration?

-Heikki




-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Html-encoding to UTF-8: hidden field vs. other fields?

[Heikki Hyyrö]

Hi all,

I have recently ran into a problem, which at least on the surface seems a bit 
strange. First the background. The Struts 2 -based application in question has 
the following kind of guard for losing data due to session timeout. If a user 
tries to submit a form after session timeout, the application forwards the user 
to a relogin page. The relogin page forwards (almost) all parameters that it 
received to another page that then automatically (using Javascript) calls the 
original action by submitting a form with hidden parameters that convey all 
parameters that the original form had submitted.

This works fine except for a strange(?) problem regarding character encoding. 
If the submitted form contains special characters, such as ö or ä, 
the final action receives them in garbled form. I have checked that these 
characters are still html-encoded on the forwarding page itself, for example 
the raw html-code of the last form on the auto-forwarding page might look like 
this:


  
  


When this form is submitted, the action saveText receives the parameter ”text” 
in garbled (not correct UTF-8) form.

However, if there is no timeout and I look at the raw html-code of the original 
form, the code might look like this:


  
Köln
  


When this form is submitted (and there is no session timeout), the action 
saveText receives the text as correct UTF-8. The two forms and their contents 
seem identical except that in the first case the text is in a hidden field 
whereas in the latter case it is in a textarea. Why does the action saveText 
receive the data garbled in one case and ok in the other? Aren’t both types of 
input fields handled in the same way by the Struts 2 framework? How could I fix 
this problem?

Best regards,
Heikki
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Struts 2 and automatic ids

[Heikki Hyyrö]

Martin Gainty  kirjoitti 11.9.2014 kello 14.31:
> MG>reference for id is here
> http://www.w3.org/TR/html401/struct/global.html#adef-id
> 
> MG>the 'functions' the (generated) id plays are illustrated here:
> The (unique) id attribute has several functions in HTML:

Yes, I am quite aware of what ids are used for. But the idea of generating ids 
without any real need for them is strange. For example one page has a large 
form with dozens of links. Struts generates unique (and rather long, creating 
unnecessary bloating) ids to each different link. For example one page with 
(possibly hundreds of) links to modifying user information has an id of form 
”updateUserGroups_#” for each such link (where # is a number representing the 
particular user whose information the link allows to edit).

> MG>struts generates HTML tags using themes which means you *can* create a 
> custom theme as seen here
> 
> http://www.mkyong.com/struts2/working-with-struts-2-theme-template/

Yes, this is something I have been trying to look into, but before trying to 
create a new template I was wondering if there is no simpler way.

> MG>If you *dont* want to create a new custom theme you can refactor existing 
> xhtml.ftl to set id=”"


> MG>can you indicate why you want to disable Struts generation of id for HTML 
> tag?
> MG>if set id="" then you would disable references to 'id' so the id reference 
> would not resolve?

Like mentioned, one goal for me is to have the pages pass the W3C markup 
validator without errors. Currently Struts sometimes gives identical ids to 
more than one element on the same page. Of course one might say that failing 
validation is not a big deal in itself, but still it feels a bit ”dodgy”…

> MG>http://struts.1045723.n5.nabble.com/Struts-tags-ID-generation-td3476228.html

Thank you for this reference, I have tried to look for existing discussion 
about the topic but had not found this! It seems that this reference discusses 
exactly what I would like to do. And unfortunately it also seems (based on the 
reference) that there is no easy way out, as they mention that some parts in 
the Struts Java code itself assume existence of ids.

Perhaps the simplest way is to replace all  tags by basic  tags, 
as the id-bloating seems to happen mainly within forms. This leads to a bit 
more complicated form markup in the jsp files, but overall should not be a too 
big nuisance.

-Heikki

Struts 2 and automatic ids

[Heikki Hyyrö]

Hi all,

I recently began to audit a Struts 2.3.16.1 application that I am maintaining. 
While running the pages through the HTML markup validation test at 
http://validator.w3.org/, I noticed a problem: Struts 2 seems to automatically 
generate id’s to many elements related to forms, and sometimes this results in 
a page that has several elements with identical auto generated id. This then 
leads to a markup validation error. So far the only way I have found to get 
around this is to explicitly generate own unique ids, but this feels like a 
stupid solution. Is it not possible to prevent Struts from auto generating ids 
to forms and some elements within them?

I have tried to google for some solution but have found nothing useful. In case 
it matters, the application in question uses the basic Struts ”simple theme” 
globally, but the same problem occurs also with the "xhtml theme".

Best regards,

Heikki