[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
[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
[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
[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
[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