Re: [struts-dev] classpath issues...
Musachy Barroso wrote: Fair enough. My only other issue with this extra try/catch block is that it seems too broad. The inner catch is for Exception, which I think means the outer catch for IOException can never be triggered... The URI constructor of File says the argument must be "An absolute, hierarchical URI with a scheme equal to "file", a non-empty path component, and undefined authority, query, and fragment components" and if not, it throws IllegalArgumentException. We're still not checking all those conditions, so if it's a bad URI getting handed to the File constructor that we're trying to protect ourselves from, making that catch specific for IllegalArgumentException seems like a good choice. At least if it were trimmed down to RuntimeException, then a valid IOException would get out of the inner try/catch block appropriately... -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
Fair enough.
musachy
On Mon, Jun 9, 2008 at 11:17 AM, Dale Newfield <[EMAIL PROTECTED]> wrote:
> Musachy Barroso wrote:
>>
>> I think "file".equalsIgnoreCase(uri.getScheme()) already covers that,
>> doesn't it?
>
> No. All that checks is that it has a scheme (and is thus not relative), and
> that scheme is "file".
>
> Here's the values returned by that iterator for my app running under
> glassfish on XP:
>
> file:/C:/Sun/SDK/
> file:/C:/Sun/SDK/domains/domain1/lib/classes/
> file:/C:/Sun/SDK/domains/domain1/applications/j2ee-modules/myApp/WEB-INF/classes/
> file:C:/Sun/SDK/domains/domain1/generated/ejb/j2ee-modules/myApp/
>
> They are all file: urls, but since the last one is missing a slash before
> "C:", the File constructor fails complaining "URI is not hierarchical".
> According to the URI javadoc: "A hierarchical URI is either an absolute URI
> whose scheme-specific part begins with a slash character, or a relative URI,
> that is, a URI that does not specify a scheme." Since it also says that "An
> opaque URI is an absolute URI whose scheme-specific part does not begin with
> a slash character ('/').", then ensuring that it is also not opaque will
> ensure that it is hierarchical, and thus that File won't barf on it.
>
> -Dale
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
Musachy Barroso wrote:
I think "file".equalsIgnoreCase(uri.getScheme()) already covers that,
doesn't it?
No. All that checks is that it has a scheme (and is thus not relative),
and that scheme is "file".
Here's the values returned by that iterator for my app running under
glassfish on XP:
file:/C:/Sun/SDK/
file:/C:/Sun/SDK/domains/domain1/lib/classes/
file:/C:/Sun/SDK/domains/domain1/applications/j2ee-modules/myApp/WEB-INF/classes/
file:C:/Sun/SDK/domains/domain1/generated/ejb/j2ee-modules/myApp/
They are all file: urls, but since the last one is missing a slash
before "C:", the File constructor fails complaining "URI is not
hierarchical". According to the URI javadoc: "A hierarchical URI is
either an absolute URI whose scheme-specific part begins with a slash
character, or a relative URI, that is, a URI that does not specify a
scheme." Since it also says that "An opaque URI is an absolute URI
whose scheme-specific part does not begin with a slash character
('/').", then ensuring that it is also not opaque will ensure that it is
hierarchical, and thus that File won't barf on it.
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
I think "file".equalsIgnoreCase(uri.getScheme()) already covers that, doesn't it? musachy On Mon, Jun 9, 2008 at 1:44 AM, Dale Newfield <[EMAIL PROTECTED]> wrote: > Musachy Barroso wrote: >> >> Yes, try/catching errors there is a good idea. I will fix it, and log >> the exception. > > Thank you for adding that. Can I lobby you also modify your "make sure it's > a file uri" check to be "make sure it's a non-opaque file uri"? > > (I.E.: Also check for !uri.isOpaque() .) > > This will prevent a bunch of cryptic stack traces from entering the logs > (possibly MANY times) for many users. > > -Dale > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
Musachy Barroso wrote: Yes, try/catching errors there is a good idea. I will fix it, and log the exception. Thank you for adding that. Can I lobby you also modify your "make sure it's a file uri" check to be "make sure it's a non-opaque file uri"? (I.E.: Also check for !uri.isOpaque() .) This will prevent a bunch of cryptic stack traces from entering the logs (possibly MANY times) for many users. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
Yes, try/catching errors there is a good idea. I will fix it, and log
the exception.
musachy
On Sat, Jun 7, 2008 at 1:58 PM, Dale Newfield <[EMAIL PROTECTED]> wrote:
> Struts Two wrote:
>>
>> Hi:
>> I think this is because an existing bug in struts 2. I have been
>> experienceing the same issue for sometime. There are two JIRA issues opened
>> for this. You can refer to : WW-2633 and WW-2642 .
>
> My problem appears to be related to yours, but with a different source.
> Both are due to urls that this code can't handle, but those urls have
> different sources. The following patch both extends Musachy's detection to
> detect my issue as well, and adds a try/catch block so that any exception
> thrown because of a URI that File cannot handle is swallowed and the
> processing continues. I would like to find the source of the bad url, but
> this patch to xwork will at least prevent that bad url from being a
> showstopper for me.
>
> So, should I just add this patch to WW-2633, or should I open a new issue?
>
> -Dale
>
> Index:
> src/java/com/opensymphony/xwork2/validator/DefaultValidatorFactory.java
> ===
> --- src/java/com/opensymphony/xwork2/validator/DefaultValidatorFactory.java
>(revision 1783)
> +++ src/java/com/opensymphony/xwork2/validator/DefaultValidatorFactory.java
>(working copy)
> @@ -98,8 +98,9 @@
> Iterator urls = ClassLoaderUtil.getResources("",
> DefaultValidatorFactory.class, false);
> while (urls.hasNext()) {
> URL u = urls.next();
> +try {
> URI uri = new URI(u.toExternalForm().replaceAll(" ",
> "%20"));
> -if ("file".equalsIgnoreCase(uri.getScheme())) {
> +if (!uri.isOpaque() &&
> "file".equalsIgnoreCase(uri.getScheme())) {
> File f = new File(uri);
> FilenameFilter filter = new FilenameFilter() {
> public boolean accept(File file, String fileName) {
> @@ -108,6 +109,10 @@
> };
> files.addAll(Arrays.asList(f.listFiles(filter)));
> }
> +} catch (IllegalArgumentException e) {
> + e.printStackTrace();
> + // swallow
> +}
> }
> } catch (URISyntaxException e) {
> e.printStackTrace();
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
Struts Two wrote:
Hi:
I think this is because an existing bug in struts 2. I have been experienceing
the same issue for sometime. There are two JIRA issues opened for this. You can
refer to : WW-2633 and WW-2642 .
My problem appears to be related to yours, but with a different source.
Both are due to urls that this code can't handle, but those urls have
different sources. The following patch both extends Musachy's detection
to detect my issue as well, and adds a try/catch block so that any
exception thrown because of a URI that File cannot handle is swallowed
and the processing continues. I would like to find the source of the
bad url, but this patch to xwork will at least prevent that bad url from
being a showstopper for me.
So, should I just add this patch to WW-2633, or should I open a new issue?
-Dale
Index:
src/java/com/opensymphony/xwork2/validator/DefaultValidatorFactory.java
===
---
src/java/com/opensymphony/xwork2/validator/DefaultValidatorFactory.java
(revision 1783)
+++
src/java/com/opensymphony/xwork2/validator/DefaultValidatorFactory.java
(working copy)
@@ -98,8 +98,9 @@
Iterator urls = ClassLoaderUtil.getResources("",
DefaultValidatorFactory.class, false);
while (urls.hasNext()) {
URL u = urls.next();
+try {
URI uri = new URI(u.toExternalForm().replaceAll(" ",
"%20"));
-if ("file".equalsIgnoreCase(uri.getScheme())) {
+if (!uri.isOpaque() &&
"file".equalsIgnoreCase(uri.getScheme())) {
File f = new File(uri);
FilenameFilter filter = new FilenameFilter() {
public boolean accept(File file, String
fileName) {
@@ -108,6 +109,10 @@
};
files.addAll(Arrays.asList(f.listFiles(filter)));
}
+} catch (IllegalArgumentException e) {
+ e.printStackTrace();
+ // swallow
+}
}
} catch (URISyntaxException e) {
e.printStackTrace();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath issues...
Could you try the latest xwork trunk? musachy On Sat, Jun 7, 2008 at 10:36 AM, Struts Two <[EMAIL PROTECTED]> wrote: > Hi: > I think this is because an existing bug in struts 2. I have been > experienceing the same issue for sometime. There are two JIRA issues opened > for this. You can refer to : WW-2633 and WW-2642 . > > > > __ > Get a sneak peak at messages with a handy reading pane with All new Yahoo! > Mail: http://ca.promos.yahoo.com/newmail/overview2/ -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath issues...
Hi: I think this is because an existing bug in struts 2. I have been experienceing the same issue for sometime. There are two JIRA issues opened for this. You can refer to : WW-2633 and WW-2642 . __ Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/
Re: [struts-dev] classpath issues...
Musachy Barroso wrote: I've done a bunch of searching to try to find where that classpath is constructed, or any other reports of similar issues, but found neither. In ClassLoaderUtil probably. ClassLoaderUtil is an xwork class. While looking at it earlier today I did find a bug (submitted a JIRA issue w/patch), but the fact that it was never detected before makes me think that code path never gets executed. It mostly just passes along URIs that it learns about by asking a series of class loaders. The "missing slash" uri that it passes along came from one of those class loaders (the first one searched). Are you suggesting that I should add special case "checking" code in there to validate/fix any URI before returning it? Seems like a hack, but I could do that... ...but it doesn't fix the fact that glassfish/the jvm/something appears to be supplying either an invalid classpath, or a broken class loader... -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath issues...
> I've done a bunch of searching to try to find where that classpath is > constructed, or any other reports of similar issues, but found neither. In ClassLoaderUtil probably. musahcy -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
classpath issues...
I recognize that this isn't specifically an xwork question, but I'm
investigating a bug that's tickled by xwork code, and I was hoping
someone might be able to point to where I should be asking this question...
I'm trying to get my struts2 app running under Sun's glassfish
distribution on a windows box (XP, SP3). Pages seem to render fine when
not logged in, but when logged in instead I wind up with pages and pages
of exceptions, seemingly all rooted in an exception (URI is not
hierarchical) thrown at
com.opensymphony.xwork2.validator.DefaultValidatorFactory.parseValidators
(Possibly due to an additional component only included for logged-in
users, which happens to include a form that is being added to the page
in a recursively called .tag file.)
I had thought that the patch applied for XW-611 is what uncovered the
problem, but I just tested rolling back that change, and it did not help.
After quite a bit of digging I've found that the cause is a malformed
URL (missing the initial '/') included in the results of
Thread.currentThread().getContextClassLoader().getResources("")
file:/C:/Sun/SDK/
file:/C:/Sun/SDK/domains/domain1/lib/classes/
file:/C:/Sun/SDK/domains/domain1/applications/j2ee-modules/myApp/WEB-INF/classes/
file:C:/Sun/SDK/domains/domain1/generated/ejb/j2ee-modules/myApp/
I've done a bunch of searching to try to find where that classpath is
constructed, or any other reports of similar issues, but found neither.
I seem to be going in circles. Can anyone here point me in another
direction?
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
