[JBoss JIRA] (JBVFS-200) FileURLConnection fails on relative URLs working on stock Java handler
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/JBVFS-200?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov edited comment on JBVFS-200 at 12/18/14 8:15 PM:
----------------------------------------------------------------
PR: https://github.com/jbossas/jboss-vfs/pull/23
was (Author: arcivanov):
https://github.com/jbossas/jboss-vfs/pull/23
> FileURLConnection fails on relative URLs working on stock Java handler
> ----------------------------------------------------------------------
>
> Key: JBVFS-200
> URL: https://issues.jboss.org/browse/JBVFS-200
> Project: JBoss VFS
> Issue Type: Bug
> Components: Release
> Affects Versions: 3.2.5.Final
> Reporter: Arcadiy Ivanov
> Assignee: Tomaz Cerar
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> A URL "file:./target/bundleA.txt" will not be handled appropriately by FileURLConnection resulting in the following exception:
> {noformat}
> java.lang.IllegalArgumentException: VFS000021: path must not be null
> at org.jboss.vfs.VFS.getChild(VFS.java:175)
> at org.jboss.vfs.VFS.getChild(VFS.java:163)
> at org.jboss.vfs.protocol.FileURLConnection.<init>(FileURLConnection.java:51)
> at org.jboss.vfs.protocol.FileURLStreamHandler.openConnection(FileURLStreamHandler.java:38)
> at java.net.URL.openConnection(URL.java:972)
> at java.net.URL.openStream(URL.java:1038)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.getResourceContent(FileBasedRepositoryStorage.java:225)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.createResourceInternal(FileBasedRepositoryStorage.java:201)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addContentResource(FileBasedRepositoryStorage.java:140)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResourceInternal(FileBasedRepositoryStorage.java:122)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResource(FileBasedRepositoryStorage.java:107)
> {noformat}
> The reason is that in the following code
> {noformat}
> public static VirtualFile getChild(URI uri) {
> return getChild(uri.getPath());
> }
> {noformat}
> {{uri.getPath()}} will return {{null}} due to URI being constructed from URL not being parsed as hierarchical only evaluating to "scheme-specific-part".
> This behavior is different from a stock Java file URL handler that will accept "file:./target/bundleA.txt" and handle it appropriately.
> A possible fix would be to call {{uri.getPath()}} first and if that returns {{null}}, fallback onto {{uri.getSchemeSpecificPart()}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (JBVFS-200) FileURLConnection fails on relative URLs working on stock Java handler
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/JBVFS-200?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated JBVFS-200:
---------------------------------
Workaround Description: (was: This is not really a workaround but URL of type file://./target/bundleA.txt would be parsed by URI constructor as hierarchical and would have getPath(). So if the URL format can be mandated externally, the use of the authority section "//" can be used to get around this bug.)
Workaround: (was: Workaround Exists)
> FileURLConnection fails on relative URLs working on stock Java handler
> ----------------------------------------------------------------------
>
> Key: JBVFS-200
> URL: https://issues.jboss.org/browse/JBVFS-200
> Project: JBoss VFS
> Issue Type: Bug
> Components: Release
> Affects Versions: 3.2.5.Final
> Reporter: Arcadiy Ivanov
> Assignee: Tomaz Cerar
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> A URL "file:./target/bundleA.txt" will not be handled appropriately by FileURLConnection resulting in the following exception:
> {noformat}
> java.lang.IllegalArgumentException: VFS000021: path must not be null
> at org.jboss.vfs.VFS.getChild(VFS.java:175)
> at org.jboss.vfs.VFS.getChild(VFS.java:163)
> at org.jboss.vfs.protocol.FileURLConnection.<init>(FileURLConnection.java:51)
> at org.jboss.vfs.protocol.FileURLStreamHandler.openConnection(FileURLStreamHandler.java:38)
> at java.net.URL.openConnection(URL.java:972)
> at java.net.URL.openStream(URL.java:1038)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.getResourceContent(FileBasedRepositoryStorage.java:225)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.createResourceInternal(FileBasedRepositoryStorage.java:201)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addContentResource(FileBasedRepositoryStorage.java:140)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResourceInternal(FileBasedRepositoryStorage.java:122)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResource(FileBasedRepositoryStorage.java:107)
> {noformat}
> The reason is that in the following code
> {noformat}
> public static VirtualFile getChild(URI uri) {
> return getChild(uri.getPath());
> }
> {noformat}
> {{uri.getPath()}} will return {{null}} due to URI being constructed from URL not being parsed as hierarchical only evaluating to "scheme-specific-part".
> This behavior is different from a stock Java file URL handler that will accept "file:./target/bundleA.txt" and handle it appropriately.
> A possible fix would be to call {{uri.getPath()}} first and if that returns {{null}}, fallback onto {{uri.getSchemeSpecificPart()}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (JBVFS-200) FileURLConnection fails on relative URLs working on stock Java handler
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/JBVFS-200?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated JBVFS-200:
---------------------------------
Description:
A URL "file:./target/bundleA.txt" will not be handled appropriately by FileURLConnection resulting in the following exception:
{noformat}
java.lang.IllegalArgumentException: VFS000021: path must not be null
at org.jboss.vfs.VFS.getChild(VFS.java:175)
at org.jboss.vfs.VFS.getChild(VFS.java:163)
at org.jboss.vfs.protocol.FileURLConnection.<init>(FileURLConnection.java:51)
at org.jboss.vfs.protocol.FileURLStreamHandler.openConnection(FileURLStreamHandler.java:38)
at java.net.URL.openConnection(URL.java:972)
at java.net.URL.openStream(URL.java:1038)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.getResourceContent(FileBasedRepositoryStorage.java:225)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.createResourceInternal(FileBasedRepositoryStorage.java:201)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addContentResource(FileBasedRepositoryStorage.java:140)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResourceInternal(FileBasedRepositoryStorage.java:122)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResource(FileBasedRepositoryStorage.java:107)
{noformat}
The reason is that in the following code
{noformat}
public static VirtualFile getChild(URI uri) {
return getChild(uri.getPath());
}
{noformat}
{{uri.getPath()}} will return {{null}} due to URI being constructed from URL not being parsed as hierarchical only evaluating to "scheme-specific-part".
This behavior is different from a stock Java file URL handler that will accept "file:./target/bundleA.txt" and handle it appropriately.
A possible fix would be to call {{uri.getPath()}} first and if that returns {{null}}, fallback onto {{uri.getSchemeSpecificPart()}}.
was:
A URL "file:./target/bundleA.txt" will not be handled appropriately by FileURLConnection resulting in the following exception:
{noformat}
java.lang.IllegalArgumentException: VFS000021: path must not be null
at org.jboss.vfs.VFS.getChild(VFS.java:175)
at org.jboss.vfs.VFS.getChild(VFS.java:163)
at org.jboss.vfs.protocol.FileURLConnection.<init>(FileURLConnection.java:51)
at org.jboss.vfs.protocol.FileURLStreamHandler.openConnection(FileURLStreamHandler.java:38)
at java.net.URL.openConnection(URL.java:972)
at java.net.URL.openStream(URL.java:1038)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.getResourceContent(FileBasedRepositoryStorage.java:225)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.createResourceInternal(FileBasedRepositoryStorage.java:201)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addContentResource(FileBasedRepositoryStorage.java:140)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResourceInternal(FileBasedRepositoryStorage.java:122)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResource(FileBasedRepositoryStorage.java:107)
{noformat}
The reason is that in the following code
{noformat}
public static VirtualFile getChild(URI uri) {
return getChild(uri.getPath());
}
{noformat}
{{uri.getPath()}} will return {{null}}.
This behavior is different from a stock Java file URL handler that will accept "file:./target/bundleA.txt" and handle appropriately.
A possible workaround would be to call {{uri.getPath()}} first and if that returns {{null}}, fallback onto {{uri.getSchemeSpecificPart()}}.
> FileURLConnection fails on relative URLs working on stock Java handler
> ----------------------------------------------------------------------
>
> Key: JBVFS-200
> URL: https://issues.jboss.org/browse/JBVFS-200
> Project: JBoss VFS
> Issue Type: Bug
> Components: Release
> Affects Versions: 3.2.5.Final
> Reporter: Arcadiy Ivanov
> Assignee: Tomaz Cerar
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> A URL "file:./target/bundleA.txt" will not be handled appropriately by FileURLConnection resulting in the following exception:
> {noformat}
> java.lang.IllegalArgumentException: VFS000021: path must not be null
> at org.jboss.vfs.VFS.getChild(VFS.java:175)
> at org.jboss.vfs.VFS.getChild(VFS.java:163)
> at org.jboss.vfs.protocol.FileURLConnection.<init>(FileURLConnection.java:51)
> at org.jboss.vfs.protocol.FileURLStreamHandler.openConnection(FileURLStreamHandler.java:38)
> at java.net.URL.openConnection(URL.java:972)
> at java.net.URL.openStream(URL.java:1038)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.getResourceContent(FileBasedRepositoryStorage.java:225)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.createResourceInternal(FileBasedRepositoryStorage.java:201)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addContentResource(FileBasedRepositoryStorage.java:140)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResourceInternal(FileBasedRepositoryStorage.java:122)
> at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResource(FileBasedRepositoryStorage.java:107)
> {noformat}
> The reason is that in the following code
> {noformat}
> public static VirtualFile getChild(URI uri) {
> return getChild(uri.getPath());
> }
> {noformat}
> {{uri.getPath()}} will return {{null}} due to URI being constructed from URL not being parsed as hierarchical only evaluating to "scheme-specific-part".
> This behavior is different from a stock Java file URL handler that will accept "file:./target/bundleA.txt" and handle it appropriately.
> A possible fix would be to call {{uri.getPath()}} first and if that returns {{null}}, fallback onto {{uri.getSchemeSpecificPart()}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (JBVFS-200) FileURLConnection fails on relative URLs working on stock Java handler
by Arcadiy Ivanov (JIRA)
Arcadiy Ivanov created JBVFS-200:
------------------------------------
Summary: FileURLConnection fails on relative URLs working on stock Java handler
Key: JBVFS-200
URL: https://issues.jboss.org/browse/JBVFS-200
Project: JBoss VFS
Issue Type: Bug
Components: Release
Affects Versions: 3.2.5.Final
Reporter: Arcadiy Ivanov
Assignee: Tomaz Cerar
A URL "file:./target/bundleA.txt" will not be handled appropriately by FileURLConnection resulting in the following exception:
{noformat}
java.lang.IllegalArgumentException: VFS000021: path must not be null
at org.jboss.vfs.VFS.getChild(VFS.java:175)
at org.jboss.vfs.VFS.getChild(VFS.java:163)
at org.jboss.vfs.protocol.FileURLConnection.<init>(FileURLConnection.java:51)
at org.jboss.vfs.protocol.FileURLStreamHandler.openConnection(FileURLStreamHandler.java:38)
at java.net.URL.openConnection(URL.java:972)
at java.net.URL.openStream(URL.java:1038)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.getResourceContent(FileBasedRepositoryStorage.java:225)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.createResourceInternal(FileBasedRepositoryStorage.java:201)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addContentResource(FileBasedRepositoryStorage.java:140)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResourceInternal(FileBasedRepositoryStorage.java:122)
at org.jboss.osgi.repository.spi.FileBasedRepositoryStorage.addResource(FileBasedRepositoryStorage.java:107)
{noformat}
The reason is that in the following code
{noformat}
public static VirtualFile getChild(URI uri) {
return getChild(uri.getPath());
}
{noformat}
{{uri.getPath()}} will return {{null}}.
This behavior is different from a stock Java file URL handler that will accept "file:./target/bundleA.txt" and handle appropriately.
A possible workaround would be to call {{uri.getPath()}} first and if that returns {{null}}, fallback onto {{uri.getSchemeSpecificPart()}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rafael Benevides (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rafael Benevides commented on WFLY-4171:
----------------------------------------
Thanks [~fbricon] for the comments over the commit. They are really useful. I'll fix what I can and check what is related to the Quickstarts itself. I opened WFLY-4190 (Banner) and WFLY-4191 (cheatsheet.xml) ref to your comment.
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rafael Benevides (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rafael Benevides commented on WFLY-4171:
----------------------------------------
As for EAP Archetypes, it is synched with the Quickstarts, so it should be fixed there first.
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (DROOLS-516) 6.1.0.beta4 and identified a rule pattern inducing memory leaks
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-516?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-516:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1160162, https://bugzilla.redhat.com/show_bug.cgi?id=1175905 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1160162)
> 6.1.0.beta4 and identified a rule pattern inducing memory leaks
> ---------------------------------------------------------------
>
> Key: DROOLS-516
> URL: https://issues.jboss.org/browse/DROOLS-516
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Beta3, 6.1.0.Beta4
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Labels: backport-to-6.0.x
> Fix For: 6.1.0.Final
>
> Attachments: 20140604.anotherleak.zip, 20140604.anotherleak_erratacorrige.zip, Java_VisualVM_2014-06-05_11-38-12.png, Java_VisualVM_2014-06-05_11-43-06.png
>
>
> Ciao I'm using 6.1.0.beta4 and I identified in my application a rule pattern inducing memory leaks. I will attach rule, screenshots, and javacode to replicate the issue.
> Steps to replicate identification of issue:
> * IF the rule {{After No data received within the last 1 hour Error, now resumed}} is included, memory leaks happens, and pretty quickly.
> * IF such rule is commented out, application do manage to keep alive.
> Same problem happens even on 6.1.0.beta3 - I did not test with previous versions.
> Thanks a lot in advance,
> Ciao
> Matteo
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years