[JBoss JIRA] (WFLY-3448) Session ID change with sub-directories using "/" context (virtual host)
by Ken H (JIRA)
[ https://issues.jboss.org/browse/WFLY-3448?page=com.atlassian.jira.plugin.... ]
Ken H edited comment on WFLY-3448 at 8/21/14 10:42 AM:
-------------------------------------------------------
I don't think the patch in pull request 6338 is right. I experienced the issue defined here on 8.1.0.Final, built master at 50a830205c and the behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x).
>From web.xml:
{code}
<welcome-file-list>
<welcome-file>/</welcome-file>
</welcome-file-list>
{code}
>From jboss-web.xml:
{code}
<jboss-web>
<context-root>/</context-root>
</jboss-web>
{code}
My app is packaged as a war, so no application.xml exists to define context-root.
I have reported this new behavior in WFLY-3758.
was (Author: steeltomato):
I don't think the patch in pull request 6338 is right. I experienced the issue defined here on 8.1.0.Final, built master at 50a830205c and the behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x).
>From web.xml:
{code}
<welcome-file-list>
<welcome-file>/</welcome-file>
</welcome-file-list>
{code}
>From jboss-web.xml:
{code}
<jboss-web>
<context-root>/</context-root>
</jboss-web>
{code}
My app is packaged as a war, so no application.xml exists to define context-root.
I would say this is not resolved, please reopen.
> Session ID change with sub-directories using "/" context (virtual host)
> -----------------------------------------------------------------------
>
> Key: WFLY-3448
> URL: https://issues.jboss.org/browse/WFLY-3448
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Wildfly 8.1.0 RC2
> Reporter: David Cabillic
> Assignee: Stuart Douglas
> Labels: sessionid, virtualhosts
> Fix For: 9.0.0.Beta1
>
>
> I used a virtual host in Wildfly like this :
> <host name="toto" alias="www.toto.com">
> <location name="/" handler="welcome-content"/>
> </host>
> When I try to access www.toto.com/sub/, a new cookie is created. It would be great with a "/sub" context but it is not for a "/" context.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3758) Unable to run JSF applications deployed to "/"
by Ken H (JIRA)
Ken H created WFLY-3758:
---------------------------
Summary: Unable to run JSF applications deployed to "/"
Key: WFLY-3758
URL: https://issues.jboss.org/browse/WFLY-3758
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 9.0.0.Beta1
Environment: WildFly master at 50a830205c, JDK 1.7
Reporter: Ken H
Assignee: Jason Greene
I don't think the patch in pull request 6338 is right. I experienced the issue defined in WLFY-3448 on 8.1.0.Final, then built master at 50a830205c and the new behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x).
>From web.xml:
{code}
<welcome-file-list>
<welcome-file>/</welcome-file>
</welcome-file-list>
{code}
>From jboss-web.xml:
{code}
<jboss-web>
<context-root>/</context-root>
</jboss-web>
{code}
My app is packaged as a war, so no application.xml exists to define context-root.
I would say this is a regression caused by the resolution to WLFY-3448.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3751) JGroups UNICAST protocol cannot be used due to IAE
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3751?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3751:
--------------------------------------
Actually -- we will drop all defaults that we are not actively using in any of the stacks.
> JGroups UNICAST protocol cannot be used due to IAE
> --------------------------------------------------
>
> Key: WFLY-3751
> URL: https://issues.jboss.org/browse/WFLY-3751
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 9.0.0.Beta1
>
>
> Because we provide a nonexistent property in our defaults file.
> {noformat}
> 22:52:37,571 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0006: Starting Services for CDI deployment: clusterbench-ee7.ear
> 22:52:37,661 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 2.2.3 (Final)
> 22:52:37,708 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0009: Starting weld service for deployment clusterbench-ee7.ear
> 22:52:38,351 WARN [org.jgroups.stack.Configurator] (MSC service thread 1-4) JGRP000014: UNICAST.setTimeout has been deprecated: not used anymore
> 22:52:38,352 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.jgroups.channel.web: org.jboss.msc.service.StartException in service jboss.jgroups.channel.web: java.lang.IllegalArgumentException: JGRP000001: configuration error: the following properties in org.jgroups.protocols.UNICAST are not recognized: {max_bytes=1m, stable_interval=5000}
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: java.lang.IllegalArgumentException: JGRP000001: configuration error: the following properties in org.jgroups.protocols.UNICAST are not recognized: {max_bytes=1m, stable_interval=5000}
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:849)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.MuxChannel.<init>(MuxChannel.java:37)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:81)
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:85)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3757) systemd script
by Jesper Pedersen (JIRA)
Jesper Pedersen created WFLY-3757:
-------------------------------------
Summary: systemd script
Key: WFLY-3757
URL: https://issues.jboss.org/browse/WFLY-3757
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Scripts
Reporter: Jesper Pedersen
Add a systemd script that can be used to setup WildFly as a service (wildfly.service)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (DROOLS-551) Incorrect serialization of Drools STREAM KieSession with expirable events causes NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-551?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-551:
------------------------------------------------
Lukáš Petrovický <lpetrovi(a)redhat.com> changed the Status of [bug 1130937|https://bugzilla.redhat.com/show_bug.cgi?id=1130937] from MODIFIED to CLOSED
> Incorrect serialization of Drools STREAM KieSession with expirable events causes NPE
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-551
> URL: https://issues.jboss.org/browse/DROOLS-551
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.CR2
> Environment: Mac OS X 10.9.2, Oracle HotSpot 1.7.0_60, JBoss BRMS 6.0.2.GA
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
> Priority: Critical
> Labels: backport-to-6.0.x
> Fix For: 6.1.0.Final
>
>
> There is an issue in Drools 6, both in PHREAK and RETEOO mode, which causes NPEs to be thrown when a session is serialized and deserialized.
> The problem occurs when running a stateful KieSession in STREAM mode and using Events with @expires annotations. When you insert an event with an @expires annotation, and you explicitly retract that Event again from the engine (i.e. KieSession.delete), and after that serialize the session, you end up with an invalid serialized session.
> When you later deserialize the session, and immediately serialize it again, a NPE is thrown at: org.drools.core.reteoo.ObjectTypeNode$ExpireJobContextTimerOutputMarshaller.serialize(ObjectTypeNode.java:669). When you deserialize the session and then advance the pseudo clock to a moment where the original event (which we've already retracted from the working memory) should have expired, a NPE is thrown at: org.drools.core.common.AbstractWorkingMemory$WorkingMemoryReteExpireAction.execute(AbstractWorkingMemory.java:1524)
> So, it seems that when the Event is explicitly retracted with KieSesion.delete(event), the event is removed from the WM, but the Expiry Timer Job is not. That ExpiryJob gets serialized with a 'null' fact handle, which does not give issues on de-serialization, but on the next serialization of the session, or when an action is peformed that triggers the expire action (i.e. move the pseudo-clock).
> A reproducer can be found here: http://www.github.com/DuncanDoyle/DroolsSerializationIssue . To reproduce:
> - git clone http://www.github.com/DuncanDoyle/DroolsSerializationIssue
> - cd DroolsSerializationIssue/DroolSerializationIssue
> - mvn clean test -P phreak (runs the test with Drools in PHREAK mode)
> - mvn clean test -P reteoo (runs the test with Drools in RETEOO mode)
> In both modes 2 of the 3 tests produce an NPE.
> Cheers,
> Duncan
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-972) EJB calendar timer Sunday calculation problem in certain locales
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-972?page=com.atlassian.jira.plugin.s... ]
Tomasz Adamski reassigned WFLY-972:
-----------------------------------
Assignee: Cheng Fang (was: Tomasz Adamski)
> EJB calendar timer Sunday calculation problem in certain locales
> ----------------------------------------------------------------
>
> Key: WFLY-972
> URL: https://issues.jboss.org/browse/WFLY-972
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Environment: JDK 6 & 7
> Reporter: Cheng Fang
> Assignee: Cheng Fang
>
> My ejb class contains this timeout method:
> {code:java}
> @Schedule(dayOfWeek="Sun", persistent=false)
> private void sunday(Timer t) {
> }
> {code}
> When calling this timer.getNextTimeout(), it returned the Sunday after next Sunday (expecting next Sunday) when running on certain locales (it_IT, es_PE, etc). It works as expected on other locales like en_US.
> I added -Duser.language=it -Duser.country=IT to JAVA_OPTS when starting standalone server to use that locale.
> Seems to be a JDK bug. There could be some differences how dates are calculated in different locales, but shouldn't be that big like skip one Sunday. Today is Wed.
> One workaround is "to use locale.English when instantiating GregorianCalendar in the following classes." I tried it on 7.2 with it_IT, and got the expected Sunday.
> {noformat}
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/CalendarBasedTimeout.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/util/CalendarUtil.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/CalendarTimerTask.java
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-972) EJB calendar timer Sunday calculation problem in certain locales
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-972?page=com.atlassian.jira.plugin.s... ]
Tomasz Adamski edited comment on WFLY-972 at 8/21/14 9:48 AM:
--------------------------------------------------------------
Cannot reproduce error.
I'm using the following code:
{code:java}
@Resource
private TimerService timerService;
@Schedule(dayOfWeek="Sun", persistent=false)
private void sunday(Timer t) {
}
public String checkTimer() {
Timer timer=timerService.getTimers().iterator().next();
return "Next invocation for locale "+Locale.getDefault()+" is "+timer.getNextTimeout().toString();
}
{code}
Results:
* without setting locale: Next invocation for locale pl_PL is Sun Aug 24 00:00:00 CEST 2014
* -Duser.language=en -Duser.country=US: Next invocation for locale en_US is Sun Aug 24 00:00:00 CEST 2014
* -Duser.language=it -Duser.country=IT: Next invocation for locale it_IT is Sun Aug 24 00:00:00 CEST 2014
* -Duser.language=es -Duser.country=PE: Next invocation for locale es_PE is Sun Aug 24 00:00:00 CEST 2014
was (Author: tomekadamski):
Cannot reproduce error.
I'm using the following code:
{code:java}
@Resource
private TimerService timerService;
@Schedule(dayOfWeek="Sun", persistent=false)
private void sunday(Timer t) {
}
public String checkTimer() {
Timer timer=timerService.getTimers().iterator().next();
return "Next invocation for locale "+Locale.getDefault()+" is "+timer.getNextTimeout().toString();
}
{code}
Results:
* without settings locale: Next invocation for locale pl_PL is Sun Aug 24 00:00:00 CEST 2014
* -Duser.language=en -Duser.country=US: Next invocation for locale en_US is Sun Aug 24 00:00:00 CEST 2014
* -Duser.language=it -Duser.country=IT: Next invocation for locale it_IT is Sun Aug 24 00:00:00 CEST 2014
* -Duser.language=es -Duser.country=PE: Next invocation for locale es_PE is Sun Aug 24 00:00:00 CEST 2014
> EJB calendar timer Sunday calculation problem in certain locales
> ----------------------------------------------------------------
>
> Key: WFLY-972
> URL: https://issues.jboss.org/browse/WFLY-972
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Environment: JDK 6 & 7
> Reporter: Cheng Fang
> Assignee: Tomasz Adamski
>
> My ejb class contains this timeout method:
> {code:java}
> @Schedule(dayOfWeek="Sun", persistent=false)
> private void sunday(Timer t) {
> }
> {code}
> When calling this timer.getNextTimeout(), it returned the Sunday after next Sunday (expecting next Sunday) when running on certain locales (it_IT, es_PE, etc). It works as expected on other locales like en_US.
> I added -Duser.language=it -Duser.country=IT to JAVA_OPTS when starting standalone server to use that locale.
> Seems to be a JDK bug. There could be some differences how dates are calculated in different locales, but shouldn't be that big like skip one Sunday. Today is Wed.
> One workaround is "to use locale.English when instantiating GregorianCalendar in the following classes." I tried it on 7.2 with it_IT, and got the expected Sunday.
> {noformat}
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/CalendarBasedTimeout.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/util/CalendarUtil.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/CalendarTimerTask.java
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-972) EJB calendar timer Sunday calculation problem in certain locales
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-972?page=com.atlassian.jira.plugin.s... ]
Tomasz Adamski commented on WFLY-972:
-------------------------------------
Cannot reproduce error.
I'm using the following code:
{code:java}
@Resource
private TimerService timerService;
@Schedule(dayOfWeek="Sun", persistent=false)
private void sunday(Timer t) {
}
public String checkTimer() {
Timer timer=timerService.getTimers().iterator().next();
return "Next invocation for locale "+Locale.getDefault()+" is "+timer.getNextTimeout().toString();
}
{code}
Results:
* without settings locale: Next invocation for locale pl_PL is Sun Aug 24 00:00:00 CEST 2014
* -Duser.language=en -Duser.country=US: Next invocation for locale en_US is Sun Aug 24 00:00:00 CEST 2014
* -Duser.language=it -Duser.country=IT: Next invocation for locale it_IT is Sun Aug 24 00:00:00 CEST 2014
* -Duser.language=es -Duser.country=PE: Next invocation for locale es_PE is Sun Aug 24 00:00:00 CEST 2014
> EJB calendar timer Sunday calculation problem in certain locales
> ----------------------------------------------------------------
>
> Key: WFLY-972
> URL: https://issues.jboss.org/browse/WFLY-972
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Environment: JDK 6 & 7
> Reporter: Cheng Fang
> Assignee: Tomasz Adamski
>
> My ejb class contains this timeout method:
> {code:java}
> @Schedule(dayOfWeek="Sun", persistent=false)
> private void sunday(Timer t) {
> }
> {code}
> When calling this timer.getNextTimeout(), it returned the Sunday after next Sunday (expecting next Sunday) when running on certain locales (it_IT, es_PE, etc). It works as expected on other locales like en_US.
> I added -Duser.language=it -Duser.country=IT to JAVA_OPTS when starting standalone server to use that locale.
> Seems to be a JDK bug. There could be some differences how dates are calculated in different locales, but shouldn't be that big like skip one Sunday. Today is Wed.
> One workaround is "to use locale.English when instantiating GregorianCalendar in the following classes." I tried it on 7.2 with it_IT, and got the expected Sunday.
> {noformat}
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/CalendarBasedTimeout.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/util/CalendarUtil.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/CalendarTimerTask.java
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months