February 2015 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-2245) ResourceFactory : creating a resource from a file

by Jerome B (JIRA)

[ https://issues.jboss.org/browse/FORGE-2245?page=com.atlassian.jira.plugin... ] Jerome B commented on FORGE-2245: --------------------------------- Hello Lincoln, Indeed, file within a file :-/ I'm biased as I used zips as FS. My bad. > ResourceFactory : creating a resource from a file > ------------------------------------------------- > > Key: FORGE-2245 > URL: https://issues.jboss.org/browse/FORGE-2245 > Project: Forge > Issue Type: Bug > Components: Resources > Affects Versions: 2.13.1.Final > Environment: w764, java 7 > Reporter: Jerome B > Fix For: 2.x Future > > > As I was trying to use a file contained in the JAR of my addon, I used this (intuitive) code > URL voilaURL = getClass().getClassLoader().getResource("voila.txt"); > File f = new File(voilaURL.toExternalForm()); > Resource<?> resource = rfactory.create(f); // KO > FileResource fresource = rfactory.create(FileResource.class, f); // KO > both last two line lead to a FileResource which, in debug is displayed as this form > [PROJECT_ROOT][Correct full path of file in jar] > D:\workspace_addons\ADDONS\jar:file:\C:\Users\me\.forge\addons\fr-company-addons-ADDONS213b-1-0-1-SNAPSHOT\ADDONS213b-1.0.1-SNAPSHOT-forge-addon.jar!\voila.txt > Then, those FileResources when used with the templateFactory > Template template = tfactory.create(resource,FreemarkerTemplate.class); > lead to an error like "template does not exist" > Hint?: The toString value is wrong but the path of the file within FileResource is ok > See https://developer.jboss.org/thread/252367 for more data -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2259) Furnace should support disabling strict loading of addons based on API version

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-2259?page=com.atlassian.jira.plugin... ] Lincoln Baxter III closed FORGE-2259. ------------------------------------- Fix Version/s: 2.15.0.Final Resolution: Done > Furnace should support disabling strict loading of addons based on API version > ------------------------------------------------------------------------------ > > Key: FORGE-2259 > URL: https://issues.jboss.org/browse/FORGE-2259 > Project: Forge > Issue Type: Feature Request > Components: Furnace (Container) > Affects Versions: 2.14.0.Final > Reporter: Lincoln Baxter III > Assignee: Lincoln Baxter III > Fix For: 2.15.0.Final > > > {code} > /** > * Set this {@link Furnace} instance to use strict {@link Version} checking when loading addons. If enabled, addons > * with an {@link Furnace} API version higher than the current {@link Furnace} runtime version will not be loaded. If > * disabled, addons will be loaded regardless of the {@link Furnace} runtime version on which they depend. (Defaults > * to <code>true</code>.) > */ > public void setStrictMode(boolean strict); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2259) Furnace should support disabling strict loading of addons based on API version

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-2259?page=com.atlassian.jira.plugin... ] Lincoln Baxter III reassigned FORGE-2259: ----------------------------------------- Assignee: Lincoln Baxter III > Furnace should support disabling strict loading of addons based on API version > ------------------------------------------------------------------------------ > > Key: FORGE-2259 > URL: https://issues.jboss.org/browse/FORGE-2259 > Project: Forge > Issue Type: Feature Request > Components: Furnace (Container) > Affects Versions: 2.14.0.Final > Reporter: Lincoln Baxter III > Assignee: Lincoln Baxter III > > {code} > /** > * Set this {@link Furnace} instance to use strict {@link Version} checking when loading addons. If enabled, addons > * with an {@link Furnace} API version higher than the current {@link Furnace} runtime version will not be loaded. If > * disabled, addons will be loaded regardless of the {@link Furnace} runtime version on which they depend. (Defaults > * to <code>true</code>.) > */ > public void setStrictMode(boolean strict); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2259) Furnace should support disabling strict loading of addons based on API version

by Lincoln Baxter III (JIRA)

Lincoln Baxter III created FORGE-2259: ----------------------------------------- Summary: Furnace should support disabling strict loading of addons based on API version Key: FORGE-2259 URL: https://issues.jboss.org/browse/FORGE-2259 Project: Forge Issue Type: Feature Request Components: Furnace (Container) Affects Versions: 2.14.0.Final Reporter: Lincoln Baxter III {code} /** * Set this {@link Furnace} instance to use strict {@link Version} checking when loading addons. If enabled, addons * with an {@link Furnace} API version higher than the current {@link Furnace} runtime version will not be loaded. If * disabled, addons will be loaded regardless of the {@link Furnace} runtime version on which they depend. (Defaults * to <code>true</code>.) */ public void setStrictMode(boolean strict); {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2241) Configuration.clearProperty() does not work for multilevel subsets

by Daniel Cunha (soro) (JIRA)

[ https://issues.jboss.org/browse/FORGE-2241?page=com.atlassian.jira.plugin... ] Daniel Cunha (soro) updated FORGE-2241: --------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/forge/core/pull/538 > Configuration.clearProperty() does not work for multilevel subsets > ------------------------------------------------------------------ > > Key: FORGE-2241 > URL: https://issues.jboss.org/browse/FORGE-2241 > Project: Forge > Issue Type: Bug > Components: Configuration > Affects Versions: 2.14.0.Final > Reporter: George Gastaldi > Assignee: Daniel Cunha (soro) > Fix For: 2.x Future > > > Having: > {code:java} > @Inject > Configuration config; > @Inject > @Subset("subset.subset") > private Configuration subSubsetConfiguration; > {code} > The following test should pass: > {code:java} > @Test > public void testSubSubsetConfigurationClearProperty() throws Exception > { > configuration.clear(); > configuration.setProperty("subset.subset.A", "Value"); > assertTrue(subSubsetConfiguration.getKeys().hasNext()); > subSubsetConfiguration.clearProperty("A"); > assertFalse(subSubsetConfiguration.getKeys().hasNext()); > assertFalse(configuration.getKeys().hasNext()); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-1790) Make adding addon deps easier in getDeployment().

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1790?page=com.atlassian.jira.plugin... ] Lincoln Baxter III closed FORGE-1790. ------------------------------------- Fix Version/s: 2.15.0.Final (was: 2.x Future) Resolution: Done > Make adding addon deps easier in getDeployment(). > ------------------------------------------------- > > Key: FORGE-1790 > URL: https://issues.jboss.org/browse/FORGE-1790 > Project: Forge > Issue Type: Feature Request > Components: Test Harness > Affects Versions: 2.13.1.Final > Reporter: Ondrej Zizka > Assignee: Lincoln Baxter III > Fix For: 2.15.0.Final > > > Currently, the deps need to be stated twice - once in annotations, and then in getDeployment(). If getDeployment() wasn't static, one could get that using reflection. But Arquillian needs getDeployment static. > This also limits usage of subclassing, because subclass can't add dependencies to it's parent. > Would be nice to come up with some solution to this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-1790) Make adding addon deps easier in getDeployment().

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-1790?page=com.atlassian.jira.plugin... ] George Gastaldi reassigned FORGE-1790: -------------------------------------- Assignee: Lincoln Baxter III (was: George Gastaldi) > Make adding addon deps easier in getDeployment(). > ------------------------------------------------- > > Key: FORGE-1790 > URL: https://issues.jboss.org/browse/FORGE-1790 > Project: Forge > Issue Type: Feature Request > Components: Test Harness > Affects Versions: 2.13.1.Final > Reporter: Ondrej Zizka > Assignee: Lincoln Baxter III > Fix For: 2.x Future > > > Currently, the deps need to be stated twice - once in annotations, and then in getDeployment(). If getDeployment() wasn't static, one could get that using reflection. But Arquillian needs getDeployment static. > This also limits usage of subclassing, because subclass can't add dependencies to it's parent. > Would be nice to come up with some solution to this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2200) Unable to fully remove addon

by Jerome B (JIRA)

[ https://issues.jboss.org/browse/FORGE-2200?page=com.atlassian.jira.plugin... ] Jerome B commented on FORGE-2200: --------------------------------- I confirm this issue. Have it w/ 2.13 , 2.13.1 and 2.14 on windows platform. I used sysinternal process explorer. it confirms it's Eclipse's javaws process that has a grip on the jar file Its a pita, because the build is indicated as successful, and the addon installed My 2 workarounds 1/ In Eclipse, do File/Restart (beware not to have forge console autostarting or you have to be quick to delete) OR 2/ Increase the version number (I copy the good one into an xml comment) > Unable to fully remove addon > ---------------------------- > > Key: FORGE-2200 > URL: https://issues.jboss.org/browse/FORGE-2200 > Project: Forge > Issue Type: Bug > Components: Addon Development, Windows > Affects Versions: 2.13.0.Final > Environment: Eclipse CLI > Reporter: Michael Schwartz > Priority: Minor > Fix For: 2.x Future > > > as reported here: https://developer.jboss.org/thread/251850 > While developing addon's it is important to constantly redeploying the addon without changing the version number for each deploy. Currently this is not possible without closing/opening eclipse between each redeploy. After a while I found the following: > When executing "addon-remove" in Eclipse Luna the specified addon gets removed in the installed.xml file in the user's .forge directory. > The corresponding class-files in .forge directory however are still there and cannot be deleted under windows which is an indicator of an open file pointer. > When stopping forge console the directory still cannot be deleted. One have to close eclipse in order to delete the directory. > I assume that this is the cause of not being able to update the addon without exiting eclipse. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2241) Configuration.clearProperty() does not work for multilevel subsets

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-2241?page=com.atlassian.jira.plugin... ] George Gastaldi commented on FORGE-2241: ---------------------------------------- If there are no values in the superset keys, then I believe that the normal behavior should be to remove the empty entries. So in this case, {{configuration.getKeys()}} will be empty. > Configuration.clearProperty() does not work for multilevel subsets > ------------------------------------------------------------------ > > Key: FORGE-2241 > URL: https://issues.jboss.org/browse/FORGE-2241 > Project: Forge > Issue Type: Bug > Components: Configuration > Affects Versions: 2.14.0.Final > Reporter: George Gastaldi > Assignee: Daniel Cunha (soro) > Fix For: 2.x Future > > > Having: > {code:java} > @Inject > Configuration config; > @Inject > @Subset("subset.subset") > private Configuration subSubsetConfiguration; > {code} > The following test should pass: > {code:java} > @Test > public void testSubSubsetConfigurationClearProperty() throws Exception > { > configuration.clear(); > configuration.setProperty("subset.subset.A", "Value"); > assertTrue(subSubsetConfiguration.getKeys().hasNext()); > subSubsetConfiguration.clearProperty("A"); > assertFalse(subSubsetConfiguration.getKeys().hasNext()); > assertFalse(configuration.getKeys().hasNext()); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (FORGE-2241) Configuration.clearProperty() does not work for multilevel subsets

by Daniel Cunha (soro) (JIRA)

[ https://issues.jboss.org/browse/FORGE-2241?page=com.atlassian.jira.plugin... ] Daniel Cunha (soro) commented on FORGE-2241: -------------------------------------------- [~gastaldi] this case: subSubsetConfiguration.clearProperty("A"); // I removed A in my subset assertFalse(subSubsetConfiguration.getKeys().hasNext()); // Ok, my subset has nothing assertFalse(configuration.getKeys().hasNext()); // This case, I'll have the empty subset or not? > Configuration.clearProperty() does not work for multilevel subsets > ------------------------------------------------------------------ > > Key: FORGE-2241 > URL: https://issues.jboss.org/browse/FORGE-2241 > Project: Forge > Issue Type: Bug > Components: Configuration > Affects Versions: 2.14.0.Final > Reporter: George Gastaldi > Assignee: Daniel Cunha (soro) > Fix For: 2.x Future > > > Having: > {code:java} > @Inject > Configuration config; > @Inject > @Subset("subset.subset") > private Configuration subSubsetConfiguration; > {code} > The following test should pass: > {code:java} > @Test > public void testSubSubsetConfigurationClearProperty() throws Exception > { > configuration.clear(); > configuration.setProperty("subset.subset.A", "Value"); > assertTrue(subSubsetConfiguration.getKeys().hasNext()); > subSubsetConfiguration.clearProperty("A"); > assertFalse(subSubsetConfiguration.getKeys().hasNext()); > assertFalse(configuration.getKeys().hasNext()); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues February 2015