May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1125) Google App Engine support: ClassLoader.getSystemClassLoader() throws exception

by Vlastimil Eliáš (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1125?page=com.atlassian.jira.plugi... ] Vlastimil Eliáš updated DROOLS-1125: ------------------------------------ Comment: was deleted (was: Xiong Zhi Ming <zxiong(a)redhat.com> changed the Status of [bug 1329093|https://bugzilla-qe-05.host.stage.eng.rdu2.redhat.com/show_bug.cg...] from POST to MODIFIED) > Google App Engine support: ClassLoader.getSystemClassLoader() throws exception > ------------------------------------------------------------------------------ > > Key: DROOLS-1125 > URL: https://issues.jboss.org/browse/DROOLS-1125 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > Class org.kie.internal.utils.ChainedProperties > Every call to get the System Class Loader > confClassLoader = ClassLoader.getSystemClassLoader(); (i.e. lines 133, 169) > raises an exception. > Todo: figure out which particular exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1125) Google App Engine support: ClassLoader.getSystemClassLoader() throws exception

by Vlastimil Eliáš (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1125?page=com.atlassian.jira.plugi... ] Vlastimil Eliáš updated DROOLS-1125: ------------------------------------ Comment: was deleted (was: Xiong Zhi Ming <zxiong(a)redhat.com> changed the Status of [bug 1329093|https://bugzilla-qe-05.host.stage.eng.rdu2.redhat.com/show_bug.cg...] from ASSIGNED to POST) > Google App Engine support: ClassLoader.getSystemClassLoader() throws exception > ------------------------------------------------------------------------------ > > Key: DROOLS-1125 > URL: https://issues.jboss.org/browse/DROOLS-1125 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > Class org.kie.internal.utils.ChainedProperties > Every call to get the System Class Loader > confClassLoader = ClassLoader.getSystemClassLoader(); (i.e. lines 133, 169) > raises an exception. > Todo: figure out which particular exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1125) Google App Engine support: ClassLoader.getSystemClassLoader() throws exception

by Vlastimil Eliáš (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1125?page=com.atlassian.jira.plugi... ] Vlastimil Eliáš updated DROOLS-1125: ------------------------------------ Comment: was deleted (was: Xiong Zhi Ming <zxiong(a)redhat.com> changed the Status of [bug 1329093|https://bugzilla-qe-05.host.stage.eng.rdu2.redhat.com/show_bug.cg...] from ON_QA to NEW) > Google App Engine support: ClassLoader.getSystemClassLoader() throws exception > ------------------------------------------------------------------------------ > > Key: DROOLS-1125 > URL: https://issues.jboss.org/browse/DROOLS-1125 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > Class org.kie.internal.utils.ChainedProperties > Every call to get the System Class Loader > confClassLoader = ClassLoader.getSystemClassLoader(); (i.e. lines 133, 169) > raises an exception. > Todo: figure out which particular exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1125) Google App Engine support: ClassLoader.getSystemClassLoader() throws exception

by Vlastimil Eliáš (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1125?page=com.atlassian.jira.plugi... ] Vlastimil Eliáš updated DROOLS-1125: ------------------------------------ Comment: was deleted (was: Xiong Zhi Ming <zxiong(a)redhat.com> changed the Status of [bug 1329093|https://bugzilla-qe-05.host.stage.eng.rdu2.redhat.com/show_bug.cg...] from NEW to ASSIGNED) > Google App Engine support: ClassLoader.getSystemClassLoader() throws exception > ------------------------------------------------------------------------------ > > Key: DROOLS-1125 > URL: https://issues.jboss.org/browse/DROOLS-1125 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > Class org.kie.internal.utils.ChainedProperties > Every call to get the System Class Loader > confClassLoader = ClassLoader.getSystemClassLoader(); (i.e. lines 133, 169) > raises an exception. > Todo: figure out which particular exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6659) Add log message indicating disabled <distributable/> flag from web-fragments

by Panagiotis Sotiropoulos (JIRA)

[ https://issues.jboss.org/browse/WFLY-6659?page=com.atlassian.jira.plugin.... ] Panagiotis Sotiropoulos closed WFLY-6659. ----------------------------------------- Resolution: Duplicate Issue > Add log message indicating disabled <distributable/> flag from web-fragments > ---------------------------------------------------------------------------- > > Key: WFLY-6659 > URL: https://issues.jboss.org/browse/WFLY-6659 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Panagiotis Sotiropoulos > Assignee: Stuart Douglas > Attachments: undistributable.war > > > If a web-fragment doesn't have distributable set, then replication is not enabled. This happens silently so it may be confusing to some users that are expecting replication to be enabled when they have set <distributable/> in their WEB-INF/web.xml. > Other third party libraries they included may have web-fragments without distributable set so it'd be nice to log a notification when this happens so that users are easily informed why replication was not enabled as they may have expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6659) Add log message indicating disabled <distributable/> flag from web-fragments

by Panagiotis Sotiropoulos (JIRA)

Panagiotis Sotiropoulos created WFLY-6659: --------------------------------------------- Summary: Add log message indicating disabled <distributable/> flag from web-fragments Key: WFLY-6659 URL: https://issues.jboss.org/browse/WFLY-6659 Project: WildFly Issue Type: Enhancement Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Panagiotis Sotiropoulos Assignee: Stuart Douglas If a web-fragment doesn't have distributable set, then replication is not enabled. This happens silently so it may be confusing to some users that are expecting replication to be enabled when they have set <distributable/> in their WEB-INF/web.xml. Other third party libraries they included may have web-fragments without distributable set so it'd be nice to log a notification when this happens so that users are easily informed why replication was not enabled as they may have expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1063) Remove dependency overrides in kie-infinispan

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1063?page=com.atlassian.jira.plugi... ] Petr Široký commented on DROOLS-1063: ------------------------------------- Most of the work has been already done (thanks [~marco.rietveld]!). For the time being, we need to overwrite Hibernate version as ISPN 8.x no longer works with Hibernate 4.x. This overwrite will be removed once we upgrade Hibernate also in IP BOM. > Remove dependency overrides in kie-infinispan > --------------------------------------------- > > Key: DROOLS-1063 > URL: https://issues.jboss.org/browse/DROOLS-1063 > Project: Drools > Issue Type: Task > Components: build > Affects Versions: 6.4.0.Beta1 > Reporter: Petr Široký > Assignee: Petr Široký > > kie-infinispan (https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-infi...) contains dependency overrides which are a very bad thing. We need to remove those. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6658) Saved rollout-plan 'name' or 'id' attribute discrepancy

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-6658?page=com.atlassian.jira.plugin.... ] Bartosz Spyrko-Śmietanko moved JBEAP-4746 to WFLY-6658: ------------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6658 (was: JBEAP-4746) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) (was: User Experience) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.ER6) > Saved rollout-plan 'name' or 'id' attribute discrepancy > ------------------------------------------------------- > > Key: WFLY-6658 > URL: https://issues.jboss.org/browse/WFLY-6658 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 10.0.0.Final > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Priority: Minor > > When using rollout plans for EAP deployment scenarios I can create my own named rollout-plan for ease of use. I can then apply rollout command later on, referring with name of my own rollout plan that should be used. There is minor discrepancy in the way I create and use such rollout plan though. > When I create rollout-plan, I use command like: > {code} > rollout-plan add --name=my-rollout-plan --content={rollout main-server-group(rolling-to-servers=false,max-failed-servers=1),other-server-group(rolling-to-servers=true,max-failure-percentage=20) rollback-across-groups=true} > {code} > - see {{--name}} attribute given to name my rollout plan > When I then refer to it I use following command: > {code} > deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan} > {code} > - see {{id}} attribute given to {{rollout}} header operation > Yes, this is really minor issue, but I think that these two attributes used in aforementioned commands should be unified (preferably to {{name}} instead of {{id}}) as user might be confused when using it. > Note: examples are used from our documentation. > Note: I do not know whether I am missing something but I was not able to retrieve more info how to use {{rollout}} header operation in deploy command directly in CLI. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1570) Saved rollout-plan 'name' or 'id' attribute discrepancy

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1570?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Śmietanko moved WFLY-6658 to WFCORE-1570: -------------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1570 (was: WFLY-6658) Component/s: CLI (was: CLI) Affects Version/s: 3.0.0.Alpha1 (was: 10.0.0.Final) > Saved rollout-plan 'name' or 'id' attribute discrepancy > ------------------------------------------------------- > > Key: WFCORE-1570 > URL: https://issues.jboss.org/browse/WFCORE-1570 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha1 > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Priority: Minor > > When using rollout plans for EAP deployment scenarios I can create my own named rollout-plan for ease of use. I can then apply rollout command later on, referring with name of my own rollout plan that should be used. There is minor discrepancy in the way I create and use such rollout plan though. > When I create rollout-plan, I use command like: > {code} > rollout-plan add --name=my-rollout-plan --content={rollout main-server-group(rolling-to-servers=false,max-failed-servers=1),other-server-group(rolling-to-servers=true,max-failure-percentage=20) rollback-across-groups=true} > {code} > - see {{--name}} attribute given to name my rollout plan > When I then refer to it I use following command: > {code} > deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan} > {code} > - see {{id}} attribute given to {{rollout}} header operation > Yes, this is really minor issue, but I think that these two attributes used in aforementioned commands should be unified (preferably to {{name}} instead of {{id}}) as user might be confused when using it. > Note: examples are used from our documentation. > Note: I do not know whether I am missing something but I was not able to retrieve more info how to use {{rollout}} header operation in deploy command directly in CLI. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-6173: ------------------------------------ I've also created an OmniFaces issue: https://github.com/omnifaces/omnifaces/issues/256 > Classes not unloaded after undeployment > --------------------------------------- > > Key: WFLY-6173 > URL: https://issues.jboss.org/browse/WFLY-6173 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 8.2.0.Final, 10.0.0.Final > Reporter: Joey Wang > Assignee: Martin Kouba > Priority: Blocker > Attachments: memory-leak.zip > > > I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. > Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances. > Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2016