February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2020) Remove demos and tests packages from final artifact

by Mathieu Lachance (JIRA)

Mathieu Lachance created JGRP-2020: -------------------------------------- Summary: Remove demos and tests packages from final artifact Key: JGRP-2020 URL: https://issues.jboss.org/browse/JGRP-2020 Project: JGroups Issue Type: Enhancement Affects Versions: 3.6.6 Environment: Wildfly 10.0.0.Final Reporter: Mathieu Lachance Assignee: Bela Ban Would it be possible to remove unecessary (I assume) demos and tests packages from the final built artifact. Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6274) Please improve deployment logging

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6274?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-6274: ----------------------------------- Unless someone has a quick fix for this, I think this falls squarely under the deployment revamp work in my queue. > Please improve deployment logging > --------------------------------- > > Key: WFLY-6274 > URL: https://issues.jboss.org/browse/WFLY-6274 > Project: WildFly > Issue Type: Feature Request > Reporter: Rick Wagner > Assignee: David Lloyd > > Wildfly attempts to deploy mal-formed artifacts and does not provide useful feedback to the user. (In fact, it provides feedback that hints that things are ok, when really they are not.) > As an example, deploying a flawed XML descriptor (targeted at no particular Wildfly subsystem) brings this: > 08:30:37,675 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015876: Starting deployment of "bogus.xml" (runtime-name: "bogus.xml") > 08:30:38,085 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015859: Deployed "bogus.xml" (runtime-name : "bogus.xml") > If the user is attempting to make use of a Wildfly subsystem (say Wildlfy-Camel) but has an unacceptable descriptor, no useful feedback is provided. The user will think their application is 'deployed' (as logged) when really it has been ignored. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6274) Please improve deployment logging

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6274?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned WFLY-6274: --------------------------------- Assignee: David Lloyd (was: Jason Greene) > Please improve deployment logging > --------------------------------- > > Key: WFLY-6274 > URL: https://issues.jboss.org/browse/WFLY-6274 > Project: WildFly > Issue Type: Feature Request > Reporter: Rick Wagner > Assignee: David Lloyd > > Wildfly attempts to deploy mal-formed artifacts and does not provide useful feedback to the user. (In fact, it provides feedback that hints that things are ok, when really they are not.) > As an example, deploying a flawed XML descriptor (targeted at no particular Wildfly subsystem) brings this: > 08:30:37,675 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015876: Starting deployment of "bogus.xml" (runtime-name: "bogus.xml") > 08:30:38,085 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015859: Deployed "bogus.xml" (runtime-name : "bogus.xml") > If the user is attempting to make use of a Wildfly subsystem (say Wildlfy-Camel) but has an unacceptable descriptor, no useful feedback is provided. The user will think their application is 'deployed' (as logged) when really it has been ignored. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-521) setting the local to english in CLI commands on non-english systems does not produce english output

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-521?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-521: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1128132|https://bugzilla.redhat.com/show_bug.cgi?id=1128132] from MODIFIED to ON_QA > setting the local to english in CLI commands on non-english systems does not produce english output > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-521 > URL: https://issues.jboss.org/browse/WFCORE-521 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Environment: Tested on MacOS running in German > Reporter: Tom Fonteyne > Assignee: Romain Pelisse > Priority: Minor > Fix For: 1.0.0.Alpha16 > > > A German (or french etc...) system must be used to reproduce. > It is likely this is not limited to MacOS, but I do not have a non-english Linux system available > An out of the box install of wildfly/EAP: > Without configuration, the log file is in German as expected. > Using these CLI comands: > :read-operation-description(name=stop-servers,locale=de_DE) -> german > :read-operation-description(name=stop-servers,locale=en_US) -> german > :read-operation-description(name=stop-servers,locale=fr_FR) -> french > So we cannot get the CLI to produce english output > when configuring JAVA_OPTS in domain.conf with: > JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8 > The log is now in English -> works as expected; and: > :read-operation-description(name=stop-servers,locale=de_DE) -> german > :read-operation-description(name=stop-servers,locale=en_US) -> english > So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked) > I presume this is because English is the default locale. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1062) Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1062?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1062: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1265170|https://bugzilla.redhat.com/show_bug.cgi?id=1265170] from MODIFIED to ON_QA > Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option. > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1062 > URL: https://issues.jboss.org/browse/WFCORE-1062 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > Fix For: 2.0.0.CR8 > > > Host controller started with --backup option deletes the deployments from the domain/data/content folder after approximately 10 mins. > The deployment is restored or recreated if the HostController is started. > Version-Release number of selected component (if applicable): 6.4.x > How reproducible: > Steps to Reproduce: > > 1. Setup domaincontroller > 2. Setup hostcontroller > 3. Start domaincontroller > 4. Start hostcontroller with --backup option. > 5. deploy an application using cli or admin console > ./jboss-cli.sh --connect --controller=x.x.x.x:9999 --command='deploy /PathToApp/App.war --server-groups=main-server-group' > 6. deployments are available under $JBOSS_HOME/domain/data/content > 7. Wait for approximately 10 minutes > 8. Cached deployments are deleted on hostcontroller (domain/data/content is empty). Following is the logging seen on the console : > ++++++++++++++ > [Host Controller] 14:20:40,439 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014903: Content /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249 is obsolete and will be removed > [Host Controller] 14:20:40,440 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014901: Content removed from location /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249/content > ++++++++++++++ > 9. After restarting the Host Controller, the deployment is restored and the cached deployment can now be seen under the Host Controller's domain/data/content folder. > Actual results: Deployment folder form domain/data/content folder gets deleted after approx 10 mins and are restored if the Host Controller is restarted > Expected results: The cached deplpyments folder should never be removed from the HostController's domain/data/content folder. > Additional info: This does not affect the availability of the application since the applications are also availbale with the assigned server's under their data/content folder. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5995) Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5995?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5995: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1298651|https://bugzilla.redhat.com/show_bug.cgi?id=1298651] from MODIFIED to ON_QA > Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-5995 > URL: https://issues.jboss.org/browse/WFLY-5995 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.1.Final, 9.0.2.Final, 10.0.0.CR5 > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Labels: timers, timerservice > Fix For: 10.0.0.Final > > > If a scheduled timer should be created with the following parameters: > ScheduleExpression[second=0 minute=0/5 hour=20-22 dayOfWeek=* dayOfMonth=* month=* year=* start=Thu Jan 14 09:45:35 GMT+1 2016] > The first schedule should be > Thu Jan 17 20:00:20 GMT+1 2016 > but is calculated as > Sun Jan 17 20:45:35 GMT+1 2016 > The minutes are not correctly set according to the schedule and the given start date. > This happen for seconds/minutes if the ScheduleExpression limit the range. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1288) installing CP over one-off fails if the modules patched by the one-off are not patched in the CP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1288?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1288: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1295999|https://bugzilla.redhat.com/show_bug.cgi?id=1295999] from MODIFIED to ON_QA > installing CP over one-off fails if the modules patched by the one-off are not patched in the CP > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1288 > URL: https://issues.jboss.org/browse/WFCORE-1288 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 1.0.1.Final > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Priority: Critical > Fix For: 2.0.8.Final > > > If a CP is installed over active one-off patches, the patch application may fail if the CP does not contain updates for the modules that were patched by the one-offs. > Normally, CP patches accumulate the one-off patches released since the previous CP which is, probably, why this bug has not been discovered for a long time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1311) emptyManagedConnectionPool can cause dead lock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1311?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1311: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1310671|https://bugzilla.redhat.com/show_bug.cgi?id=1310671] from MODIFIED to ON_QA > emptyManagedConnectionPool can cause dead lock > ---------------------------------------------- > > Key: JBJCA-1311 > URL: https://issues.jboss.org/browse/JBJCA-1311 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: WildFly/IronJacamar 1.3.2.Final, 1.0.35.Final, 1.2.6.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: WildFly/IronJacamar 1.3.3.Final, 1.0.36.Final, 1.2.7.Final > > > Can happen in scenarios where multiple credentials are used for the pool (PoolByCri / PoolByCRIAndSubject) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-313) Deadlock in WsRemoteEndpointImplServer.onWritePossible

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-313?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-313: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1299057|https://bugzilla.redhat.com/show_bug.cgi?id=1299057] from MODIFIED to ON_QA > Deadlock in WsRemoteEndpointImplServer.onWritePossible > ------------------------------------------------------ > > Key: JBWEB-313 > URL: https://issues.jboss.org/browse/JBWEB-313 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.5.0.GA > Environment: JBoss EAP 6.4.5 > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > Attachments: JBWEB-313.patch > > > A deadlock is possible in WsRemoteEndpointImplServer.onWritePossible: > {code} > http-/0.0.0.0:8080-1": > at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:93) > - waiting to lock <0x00000006dee6a1a8> (a java.nio.HeapByteBuffer) > - locked <0x00000006dee6a200> (a java.lang.Object) > at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:243) > at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:605) > at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) > at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) > at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) > at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:252) > at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) > at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) > at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) > at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:232) > at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) > at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:939) > - locked <0x00000006deeeb9c0> (a java.lang.Object) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.apache.tomcat.util.net.NioEndpoint$DefaultThreadFactory$1$1.run(NioEndpoint.java:1249) > at java.lang.Thread.run(Thread.java:745) > "EJB default - 1": > at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:81) > - waiting to lock <0x00000006dee6a200> (a java.lang.Object) > at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:76) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:444) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:334) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write(WsRemoteEndpointImplBase.java:741) > - locked <0x00000006dee6a1a8> (a java.nio.HeapByteBuffer) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:239) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:182) > at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2948) Welcome file does not work for *.jsf

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2948?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2948: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1256325|https://bugzilla.redhat.com/show_bug.cgi?id=1256325] from MODIFIED to ON_QA > Welcome file does not work for *.jsf > -------------------------------------- > > Key: WFLY-2948 > URL: https://issues.jboss.org/browse/WFLY-2948 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Gulam Samdani > Assignee: Remy Maucherat > Priority: Minor > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Welcome file does not work for *.jsf > -------------------------------------------------------- > same problem not exists in Wildfly Beta but wildfly 8 final /cr1 gives this error ... > > problem : > > http://localhost:8080/hello ------------------------------ NO works*** > @http://localhost:8080/hello/index.jsf ------------- it works fine > ======================================= > <welcome-file-list> > > <welcome-file>index.jsf</welcome-file> > > </welcome-file-list> > <servlet> > <servlet-name>Faces Servlet</servlet-name> > <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > <servlet-mapping> > <servlet-name>Faces Servlet</servlet-name> > <url-pattern>*.jsf</url-pattern> > </servlet-mapping> > </web-app> > ------------------------------------------------- > Reproduce this error : > https://community.jboss.org/message/857300 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 February 2016