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