[Openjmx-devel] [ openjmx-Bugs-513698 ] XSLTProcessor cannot read JARs on Win32

[n***@sourceforge.net]

Bugs item #513698, was opened at 2002-02-06 03:55
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

Category: Http Adapter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Glencross (chrisglencross)
Assigned to: Nobody/Anonymous (nobody)
Summary: XSLTProcessor cannot read JARs on Win32

Initial Comment:
Using beta 2 (same result in beta 1).

Lines 287 and 291 use new File(this.path,
path).toString() to build the path to a resource in a
JAR file.

Unfortunately, on Windows, this results in all '/'
characters being replaced with '\', which means that
no XSL resources can be found by the classloader. The
user sees blank pages.

Would it be problematic to change to using string
concatenation to build JAR resource paths instead of
File.toString()?

----------------------------------------------------------------------

You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

[n***@sourceforge.net]

Bugs item #513698, was opened at 2002-02-06 03:55
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

Category: Http Adapter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Glencross (chrisglencross)

Assigned to: Carlos Quiroz (tibu)

Summary: XSLTProcessor cannot read JARs on Win32

Initial Comment:
Using beta 2 (same result in beta 1).

Lines 287 and 291 use new File(this.path,
path).toString() to build the path to a resource in a
JAR file.

Unfortunately, on Windows, this results in all '/'
characters being replaced with '\', which means that
no XSL resources can be found by the classloader. The
user sees blank pages.

Would it be problematic to change to using string
concatenation to build JAR resource paths instead of
File.toString()?

----------------------------------------------------------------------

Comment By: Carlos Quiroz (tibu)

Date: 2002-02-06 05:18

Message:
Logged In: YES
user_id=64333

Thanks for pointing this. It will be fixed ASAP


----------------------------------------------------------------------

You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

[n***@sourceforge.net]

Bugs item #513698, was opened at 2002-02-06 03:55
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

Category: Http Adapter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Glencross (chrisglencross)
Assigned to: Carlos Quiroz (tibu)
Summary: XSLTProcessor cannot read JARs on Win32

Initial Comment:
Using beta 2 (same result in beta 1).

Lines 287 and 291 use new File(this.path,
path).toString() to build the path to a resource in a
JAR file.

Unfortunately, on Windows, this results in all '/'
characters being replaced with '\', which means that
no XSL resources can be found by the classloader. The
user sees blank pages.

Would it be problematic to change to using string
concatenation to build JAR resource paths instead of
File.toString()?

----------------------------------------------------------------------

Comment By: Chris Glencross (chrisglencross)

Date: 2002-02-06 05:30

Message:
Logged In: YES
user_id=337810

Slightly related:

Elsewhere in the file URLs are generated by prefixing a
file path with "file://". This only really works in Windows
if the file path already contains a leading "/", which
isn't conventional if a drive prefix is used.

I would suggest that new File(path).toURL() be used to
create the URL instead in a cross-platform manner.

----------------------------------------------------------------------

Comment By: Carlos Quiroz (tibu)
Date: 2002-02-06 05:18

Message:
Logged In: YES
user_id=64333

Thanks for pointing this. It will be fixed ASAP


----------------------------------------------------------------------

You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

[n***@sourceforge.net]

Bugs item #513698, was opened at 2002-02-06 03:55
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

Category: Http Adapter
Group: None

Status: Pending
Resolution: Fixed

Priority: 5
Submitted By: Chris Glencross (chrisglencross)
Assigned to: Carlos Quiroz (tibu)
Summary: XSLTProcessor cannot read JARs on Win32

Initial Comment:
Using beta 2 (same result in beta 1).

Lines 287 and 291 use new File(this.path,
path).toString() to build the path to a resource in a
JAR file.

Unfortunately, on Windows, this results in all '/'
characters being replaced with '\', which means that
no XSL resources can be found by the classloader. The
user sees blank pages.

Would it be problematic to change to using string
concatenation to build JAR resource paths instead of
File.toString()?

----------------------------------------------------------------------

Comment By: Carlos Quiroz (tibu)

Date: 2002-02-07 14:33

Message:
Logged In: YES
user_id=64333

Added suggested modification including a few extra checks.
Tested only in Linux, it will be kept as pending until it
is confirmed that it works in Windows


----------------------------------------------------------------------

Comment By: Chris Glencross (chrisglencross)
Date: 2002-02-06 05:30

Message:
Logged In: YES
user_id=337810

Slightly related:

Elsewhere in the file URLs are generated by prefixing a
file path with "file://". This only really works in Windows
if the file path already contains a leading "/", which
isn't conventional if a drive prefix is used.

I would suggest that new File(path).toURL() be used to
create the URL instead in a cross-platform manner.

----------------------------------------------------------------------

Comment By: Carlos Quiroz (tibu)
Date: 2002-02-06 05:18

Message:
Logged In: YES
user_id=64333

Thanks for pointing this. It will be fixed ASAP


----------------------------------------------------------------------

You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

[n***@sourceforge.net]

Bugs item #513698, was opened at 2002-02-06 03:55
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

Category: Http Adapter
Group: None
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: Chris Glencross (chrisglencross)
Assigned to: Carlos Quiroz (tibu)
Summary: XSLTProcessor cannot read JARs on Win32

Initial Comment:
Using beta 2 (same result in beta 1).

Lines 287 and 291 use new File(this.path,
path).toString() to build the path to a resource in a
JAR file.

Unfortunately, on Windows, this results in all '/'
characters being replaced with '\', which means that
no XSL resources can be found by the classloader. The
user sees blank pages.

Would it be problematic to change to using string
concatenation to build JAR resource paths instead of
File.toString()?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-12 05:08

Message:
Logged In: NO

I got the same problem and what I did was to replace all
the back slashes with slashes just by using File.toString
().replace('\','/'). It is not so elegant as your
suggestion but it works as well.

----------------------------------------------------------------------

Comment By: Carlos Quiroz (tibu)
Date: 2002-02-07 14:33

Message:
Logged In: YES
user_id=64333

Added suggested modification including a few extra checks.
Tested only in Linux, it will be kept as pending until it
is confirmed that it works in Windows


----------------------------------------------------------------------

Comment By: Chris Glencross (chrisglencross)
Date: 2002-02-06 05:30

Message:
Logged In: YES
user_id=337810

Slightly related:

Elsewhere in the file URLs are generated by prefixing a
file path with "file://". This only really works in Windows
if the file path already contains a leading "/", which
isn't conventional if a drive prefix is used.

I would suggest that new File(path).toURL() be used to
create the URL instead in a cross-platform manner.

----------------------------------------------------------------------

Comment By: Carlos Quiroz (tibu)
Date: 2002-02-06 05:18

Message:
Logged In: YES
user_id=64333

Thanks for pointing this. It will be fixed ASAP


----------------------------------------------------------------------

You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

[n***@sourceforge.net]

Bugs item #513698, was opened at 2002-02-06 03:55
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041

Category: Http Adapter
Group: None
Status: Pending
Resolution: Fixed
Priority: 5
Submitted By: Chris Glencross (chrisglencross)
Assigned to: Carlos Quiroz (tibu)
Summary: XSLTProcessor cannot read JARs on Win32

Initial Comment:
Using beta 2 (same result in beta 1).

Lines 287 and 291 use new File(this.path,
path).toString() to build the path to a resource in a
JAR file.

Unfortunately, on Windows, this results in all '/'
characters being replaced with '\', which means that
no XSL resources can be found by the classloader. The
user sees blank pages.

Would it be problematic to change to using string
concatenation to build JAR resource paths instead of
File.toString()?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-12 05:12

Message:
Logged In: NO

I got the same problem and what I did was to replace all
the back slashes with slashes just by using File.toString
().replace('\','/'). It is not so elegant as your
suggestion but it works as well.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-12 05:08

Message:
Logged In: NO

I got the same problem and what I did was to replace all
the back slashes with slashes just by using File.toString
().replace('\','/'). It is not so elegant as your
suggestion but it works as well.

----------------------------------------------------------------------

Comment By: Carlos Quiroz (tibu)
Date: 2002-02-07 14:33

Message:
Logged In: YES
user_id=64333

Added suggested modification including a few extra checks.
Tested only in Linux, it will be kept as pending until it
is confirmed that it works in Windows


----------------------------------------------------------------------

Comment By: Chris Glencross (chrisglencross)
Date: 2002-02-06 05:30

Message:
Logged In: YES
user_id=337810

Slightly related:

Elsewhere in the file URLs are generated by prefixing a
file path with "file://". This only really works in Windows
if the file path already contains a leading "/", which
isn't conventional if a drive prefix is used.

I would suggest that new File(path).toURL() be used to
create the URL instead in a cross-platform manner.

----------------------------------------------------------------------

Comment By: Carlos Quiroz (tibu)
Date: 2002-02-06 05:18

Message:
Logged In: YES
user_id=64333

Thanks for pointing this. It will be fixed ASAP


----------------------------------------------------------------------

You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041