March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6663) Usability issue: 'Reload' operation in CLI returns information that another reload is required

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6663?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6663: ---------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> made a comment on [bug 900210|https://bugzilla.redhat.com/show_bug.cgi?id=900210] Jan, is this still an issue? I can't reproduce it and from my reading of the current code it shouldn't happen. If you can reproduce, please add instructions and assign back to me. Thanks. > Usability issue: 'Reload' operation in CLI returns information that another reload is required > ---------------------------------------------------------------------------------------------- > > Key: AS7-6663 > URL: https://issues.jboss.org/browse/AS7-6663 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP), 7.2.0.Alpha1 > Reporter: Brian Stansberry > Priority: Minor > > Jan Martiska reported: > Assume a server reload is required.. then you do this: > {code} > [standalone@localhost:9999 /] :reload > { > "outcome" => "success", > "response-headers" => {"process-state" => "reload-required"} > } > {code} > I think it is quite confusing that "reload-required" is returned from 'reload' operation. (if you do more operations, it will not appear again, only once). Is it possible to fix it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6663) Usability issue: 'Reload' operation in CLI returns information that another reload is required

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6663?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6663: ---------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 900210|https://bugzilla.redhat.com/show_bug.cgi?id=900210] from NEW to ASSIGNED > Usability issue: 'Reload' operation in CLI returns information that another reload is required > ---------------------------------------------------------------------------------------------- > > Key: AS7-6663 > URL: https://issues.jboss.org/browse/AS7-6663 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP), 7.2.0.Alpha1 > Reporter: Brian Stansberry > Priority: Minor > > Jan Martiska reported: > Assume a server reload is required.. then you do this: > {code} > [standalone@localhost:9999 /] :reload > { > "outcome" => "success", > "response-headers" => {"process-state" => "reload-required"} > } > {code} > I think it is quite confusing that "reload-required" is returned from 'reload' operation. (if you do more operations, it will not appear again, only once). Is it possible to fix it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6663) Usability issue: 'Reload' operation in CLI returns information that another reload is required

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6663?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6663: ---------------------------------- Fix Version/s: 8.0.0.Alpha1 > Usability issue: 'Reload' operation in CLI returns information that another reload is required > ---------------------------------------------------------------------------------------------- > > Key: AS7-6663 > URL: https://issues.jboss.org/browse/AS7-6663 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP), 7.2.0.Alpha1 > Reporter: Brian Stansberry > Priority: Minor > Fix For: 8.0.0.Alpha1 > > > Jan Martiska reported: > Assume a server reload is required.. then you do this: > {code} > [standalone@localhost:9999 /] :reload > { > "outcome" => "success", > "response-headers" => {"process-state" => "reload-required"} > } > {code} > I think it is quite confusing that "reload-required" is returned from 'reload' operation. (if you do more operations, it will not appear again, only once). Is it possible to fix it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-5582) JDK ORB Subsystem

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/AS7-5582?page=com.atlassian.jira.plugin.s... ] Eduardo Martins reassigned AS7-5582: ------------------------------------ Assignee: Stuart Douglas (was: Eduardo Martins) > JDK ORB Subsystem > ----------------- > > Key: AS7-5582 > URL: https://issues.jboss.org/browse/AS7-5582 > Project: Application Server 7 > Issue Type: Feature Request > Components: IIOP > Reporter: Dimitris Andreadis > Assignee: Stuart Douglas > > Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem. > AFAIK, most/all JDK ORBs are based on the Sun ORB. > Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6658) Include Infinispan CDI as a JBoss module

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/AS7-6658?page=com.atlassian.jira.plugin.s... ] Radoslav Husar commented on AS7-6658: ------------------------------------- A new Infinispan component JCACHE has been created in Jira: https://issues.jboss.org/browse/ISPN/component/12317268 > Include Infinispan CDI as a JBoss module > ---------------------------------------- > > Key: AS7-6658 > URL: https://issues.jboss.org/browse/AS7-6658 > Project: Application Server 7 > Issue Type: Enhancement > Components: Clustering > Reporter: Avelino Martins > Assignee: Radoslav Husar > Fix For: 8.0.0.Alpha1 > > > CDI has become an invaluable technology on any JavaEE project. I find hard to justify having to include infinispan-cdi as a compile dependency on every project that uses ISPN. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-66) It is impossible to switch off URL caching if https protocol is used

by Alessandro Lazarotti (JIRA)

[ https://issues.jboss.org/browse/DROOLS-66?page=com.atlassian.jira.plugin.... ] Alessandro Lazarotti closed DROOLS-66. -------------------------------------- > It is impossible to switch off URL caching if https protocol is used > -------------------------------------------------------------------- > > Key: DROOLS-66 > URL: https://issues.jboss.org/browse/DROOLS-66 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > Fix For: 6.0.0.Alpha1 > > > It is impossible to switch off URL caching if https protocol is used > When used https to load resources from HTTP, a conditional mistake try to cache the content even though CACHE_DIR is null: > // class org.drools.io.impl.UrlResource > public InputStream getInputStream() throws IOException { > (...) > if (lastMod > 0 && lastMod > lastRead) { > if (CACHE_DIR != null && url.getProtocol().equals("http") || url.getProtocol().equals("https")) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } > } > (...) > } > IF only "https" was evaluated as true - ((false && false) || true) - so the exit will be true, which should be not the expected behaviour > That code should be: > if (CACHE_DIR != null && (url.getProtocol().equals("http") || url.getProtocol().equals("https"))) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-65) Local Cache is not updated, case client is started before the server

by Alessandro Lazarotti (JIRA)

[ https://issues.jboss.org/browse/DROOLS-65?page=com.atlassian.jira.plugin.... ] Alessandro Lazarotti closed DROOLS-65. -------------------------------------- > Local Cache is not updated, case client is started before the server > -------------------------------------------------------------------- > > Key: DROOLS-65 > URL: https://issues.jboss.org/browse/DROOLS-65 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > Fix For: 6.0.0.Alpha1 > > > Local Cache is not updated, case client is started before the server > 1. Start Guvnor > 2. Any regular client application consumes some package with local cache configured (drools.resource.urlcache) > 3. Stop client and server > 4. Restart the client (it will work consuming data from loca cache) > 5. Restart the server and changes a rule from the package used by client application > 6. BUild the package > 7. Local cache still consume the package from the local cache which is never synchronized with the server > It works as expected case only the server is restarted or if server starts before the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-65) Local Cache is not updated, case client is started before the server

by Alessandro Lazarotti (JIRA)

[ https://issues.jboss.org/browse/DROOLS-65?page=com.atlassian.jira.plugin.... ] Alessandro Lazarotti resolved DROOLS-65. ---------------------------------------- Fix Version/s: 6.0.0.Alpha1 Resolution: Done merged in 5.3.x, 5.4.x, 5.5.x and master (6.0.x) branch > Local Cache is not updated, case client is started before the server > -------------------------------------------------------------------- > > Key: DROOLS-65 > URL: https://issues.jboss.org/browse/DROOLS-65 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > Fix For: 6.0.0.Alpha1 > > > Local Cache is not updated, case client is started before the server > 1. Start Guvnor > 2. Any regular client application consumes some package with local cache configured (drools.resource.urlcache) > 3. Stop client and server > 4. Restart the client (it will work consuming data from loca cache) > 5. Restart the server and changes a rule from the package used by client application > 6. BUild the package > 7. Local cache still consume the package from the local cache which is never synchronized with the server > It works as expected case only the server is restarted or if server starts before the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-66) It is impossible to switch off URL caching if https protocol is used

by Alessandro Lazarotti (JIRA)

[ https://issues.jboss.org/browse/DROOLS-66?page=com.atlassian.jira.plugin.... ] Alessandro Lazarotti resolved DROOLS-66. ---------------------------------------- Fix Version/s: 6.0.0.Alpha1 Resolution: Done merged in 5.3.x, 5.4.x, 5.5.x and master (6.0.x) branch > It is impossible to switch off URL caching if https protocol is used > -------------------------------------------------------------------- > > Key: DROOLS-66 > URL: https://issues.jboss.org/browse/DROOLS-66 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > Fix For: 6.0.0.Alpha1 > > > It is impossible to switch off URL caching if https protocol is used > When used https to load resources from HTTP, a conditional mistake try to cache the content even though CACHE_DIR is null: > // class org.drools.io.impl.UrlResource > public InputStream getInputStream() throws IOException { > (...) > if (lastMod > 0 && lastMod > lastRead) { > if (CACHE_DIR != null && url.getProtocol().equals("http") || url.getProtocol().equals("https")) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } > } > (...) > } > IF only "https" was evaluated as true - ((false && false) || true) - so the exit will be true, which should be not the expected behaviour > That code should be: > if (CACHE_DIR != null && (url.getProtocol().equals("http") || url.getProtocol().equals("https"))) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-66) It is impossible to switch off URL caching if https protocol is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-66?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on DROOLS-66: ----------------------------------------------- Alessandro Lazarotti <alazarot(a)redhat.com> changed the Status of [bug 913252|https://bugzilla.redhat.com/show_bug.cgi?id=913252] from NEW to MODIFIED > It is impossible to switch off URL caching if https protocol is used > -------------------------------------------------------------------- > > Key: DROOLS-66 > URL: https://issues.jboss.org/browse/DROOLS-66 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > > It is impossible to switch off URL caching if https protocol is used > When used https to load resources from HTTP, a conditional mistake try to cache the content even though CACHE_DIR is null: > // class org.drools.io.impl.UrlResource > public InputStream getInputStream() throws IOException { > (...) > if (lastMod > 0 && lastMod > lastRead) { > if (CACHE_DIR != null && url.getProtocol().equals("http") || url.getProtocol().equals("https")) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } > } > (...) > } > IF only "https" was evaluated as true - ((false && false) || true) - so the exit will be true, which should be not the expected behaviour > That code should be: > if (CACHE_DIR != null && (url.getProtocol().equals("http") || url.getProtocol().equals("https"))) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2013