[JBoss JIRA] (WFLY-3393) JSP 2 different tags called with same tag instance
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3393?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3393:
--------------------------------------
It is more likely to get fixed sooner if there is a reproducer I can use to examine the problem. Without a reproducer it is hard to estimate how long it will take.
> JSP 2 different tags called with same tag instance
> --------------------------------------------------
>
> Key: WFLY-3393
> URL: https://issues.jboss.org/browse/WFLY-3393
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
>
> When working with JSP tags on struts i can see that sometimes 2 diffrent tags with same type is called with the same instance.
> Example:
> JSP
> <jcv:text id="email" maxlength="255" property="valueObject.Email"/>
> <br>
> <jcv:text id="phone" maxlength="255" property="valueObject.Phone"/>
> TLD
> <tag>
> <name>text</name>
> <tagclass>tti.jcore.views.form.tag.JViewsTextTag</tagclass>
> ...
> </tag>
> I can see that the public int doStartTag() called for both with the same instance.
>
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1846) RELAY2: delay shutting down bridge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1846?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1846:
---------------------------
Fix Version/s: 3.5
> RELAY2: delay shutting down bridge
> ----------------------------------
>
> Key: JGRP-1846
> URL: https://issues.jboss.org/browse/JGRP-1846
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> A simple test that starts 2 sites x 2 nodes each and shuts them down in order shows a 1 second delay when shutting down the last node in the first site (B):
> {code:java}
> public void testCoordinatorShutdown() throws Exception {
> a=createNode(LON, "A", LON_CLUSTER, null);
> b=createNode(LON, "B", LON_CLUSTER, null);
> x=createNode(SFO, "X", SFO_CLUSTER, null);
> y=createNode(SFO, "Y", SFO_CLUSTER, null);
> Util.waitUntilAllChannelsHaveSameSize(10000, 100, a, b);
> Util.waitUntilAllChannelsHaveSameSize(10000, 100, x, y);
> waitForBridgeView(2, 20000, 100, a, x);
> a.close();
> Util.waitUntilAllChannelsHaveSameSize(10000, 100, b);
> b.close();
> waitForBridgeView(1, 20000, 100, x);
> x.close();
> y.close();
> }
> {code}
> And the relevant logs:
> {noformat}
> 13:51:30,017 DEBUG (Timer-2,sfo-cluster,X:) [GMS] _X:sfo: installing view [_A:lon|1] (2) [_A:lon, _X:sfo]
> 13:51:30,028 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|2] (1) [_X:sfo]
> 13:51:30,046 TRACE (Timer-2,lon-cluster,B:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global]
> 13:51:31,046 TRACE (Timer-2,global,_B:lon:) [SHARED_LOOPBACK] _B:lon: sending msg to _X:sfo, src=_B:lon, headers are GMS: GmsHeader[JOIN_REQ]: mbr=_B:lon, UNICAST3: DATA, seqno=1, first, SHARED_LOOPBACK: [cluster_name=global]
> 13:51:31,099 DEBUG (Incoming-2,global,_X:sfo:) [GMS] _X:sfo: installing view [_X:sfo|3] (2) [_X:sfo, _B:lon]
> {noformat}
> Note that while this happens on a background timer thread, the shutdown is delayed nonetheless because {{TP.destroy()}} waits at least 500ms for all the timer threads to finish ({{TimeScheduler3.stopRunning()}}. Perhaps that should change as well, so that timer threads are interrupted and finish immediately.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3393) JSP 2 different tags called with same tag instance
by roy mizrachi (JIRA)
[ https://issues.jboss.org/browse/WFLY-3393?page=com.atlassian.jira.plugin.... ]
roy mizrachi commented on WFLY-3393:
------------------------------------
HI Again,
This issue is very improtant to us and is a show stopper for us to migrate to jboss from weblogic.
Will this be resolved in the near future?
Thanks,
Roi
> JSP 2 different tags called with same tag instance
> --------------------------------------------------
>
> Key: WFLY-3393
> URL: https://issues.jboss.org/browse/WFLY-3393
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
>
> When working with JSP tags on struts i can see that sometimes 2 diffrent tags with same type is called with the same instance.
> Example:
> JSP
> <jcv:text id="email" maxlength="255" property="valueObject.Email"/>
> <br>
> <jcv:text id="phone" maxlength="255" property="valueObject.Phone"/>
> TLD
> <tag>
> <name>text</name>
> <tagclass>tti.jcore.views.form.tag.JViewsTextTag</tagclass>
> ...
> </tag>
> I can see that the public int doStartTag() called for both with the same instance.
>
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-1197) Port the legacy jmx-console to AS7
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/WFLY-1197?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on WFLY-1197:
-------------------------------------------
Hi [~MrEasy], I created separate repo here: https://github.com/altanis/wildfly-jmx-console. There was also a small bug regarding to escaping percent character. I get it working on fresh installation of JBoss 7.1.1. If you still encounter these problems, please let me know.
> Port the legacy jmx-console to AS7
> ----------------------------------
>
> Key: WFLY-1197
> URL: https://issues.jboss.org/browse/WFLY-1197
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMX
> Reporter: Dimitris Andreadis
> Assignee: Darran Lofthouse
> Labels: JMX, as7, jmx-console, management_security,, management_sso
> Attachments: jmx-console.war, jmx-console.war
>
>
> I've seen a few people asking for a port of the old jmx-console to AS7, for monitoring purposes, until equivalent functionality is available through the new GWT-based console.
> I've ported the old console in this branch:
> https://github.com/dandreadis/jboss-as/commits/jmx-console
> It only includes a new top-level directory 'jmx-console'. The directory is not build by default, and when you build it manually it does not alter the server configuration in any way, you need to manually copy the resulting target/jboss-as-jmx-console-VERSION.war to the server deployment directory (and rename it to jmx-console.war)
> If there is interest, it could be included in the AS7 distro in some top level 'legacy' directory so it is not deployed by default?
> The resulting .war is attached on this JIRA, in case someone wants to use it. It work just as well on AS 7.0.2 and the latest AS 7.1.x development branch.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (DROOLS-519) Accumulate CollectList does not preserve the insertion order
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-519:
-------------------------------------
Summary: Accumulate CollectList does not preserve the insertion order
Key: DROOLS-519
URL: https://issues.jboss.org/browse/DROOLS-519
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0.Beta4
Reporter: Davide Sottara
Assignee: Mark Proctor
Priority: Critical
In 5.x, acc / collectList preserves the order of insertion.
That is, if A1, A2 and A3 are inserted, a collectList will return 1,2,3
In 6.x, the order is reversed. That is, in the same scenario, a list
with 3,2,1 is generated.
While arguably a minor issue, collectList returns a list, that is an ordered
collection. The reversal of the order breaks the compatibility of preexising
applications (such as drools-mas)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3466) No error reported when remote handshake fails
by Paul Benedict (JIRA)
[ https://issues.jboss.org/browse/WFLY-3466?page=com.atlassian.jira.plugin.... ]
Paul Benedict commented on WFLY-3466:
-------------------------------------
I am not using any API(s) directly. This is all through standard container setup.
> No error reported when remote handshake fails
> ---------------------------------------------
>
> Key: WFLY-3466
> URL: https://issues.jboss.org/browse/WFLY-3466
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remoting
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Paul Benedict
> Assignee: David Lloyd
>
> When the destination server fails to respond and thus the remote handshake cannot be made, nothing gets reported in the client's log -- even when put on TRACE. I spent many days trying to get to the bottom of this. This abnormal condition is too important for it to go unreported.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3466) No error reported when remote handshake fails
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3466?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3466:
-----------------------------------
Can you be more specific? How are you connecting, what API(s) are you using?
> No error reported when remote handshake fails
> ---------------------------------------------
>
> Key: WFLY-3466
> URL: https://issues.jboss.org/browse/WFLY-3466
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remoting
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Paul Benedict
> Assignee: David Lloyd
>
> When the destination server fails to respond and thus the remote handshake cannot be made, nothing gets reported in the client's log -- even when put on TRACE. I spent many days trying to get to the bottom of this. This abnormal condition is too important for it to go unreported.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3389) Error Connecting to WildFly via JMX
by Rainier Ramos (JIRA)
[ https://issues.jboss.org/browse/WFLY-3389?page=com.atlassian.jira.plugin.... ]
Rainier Ramos commented on WFLY-3389:
-------------------------------------
I had the same issue and resolved it by running Eclipse in a Java7 VM. Add this to the top of your eclipse.ini:
-vm
/usr/lib/jvm/java-7-oracle/bin/java --> obviously, you'll need to replace this per your environment
> Error Connecting to WildFly via JMX
> -----------------------------------
>
> Key: WFLY-3389
> URL: https://issues.jboss.org/browse/WFLY-3389
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.CR1
> Environment: Windows 7 32 bit, behind a proxy that only lets IE through
> Reporter: R Veach
> Assignee: Darran Lofthouse
> Priority: Minor
> Attachments: console page.htm, eclipse error.txt, server.log
>
>
> When server is running through Eclipse Kepler, admin console is completely blank no error messages in the console and an Eclipse error dialog pops up.
> I tried running it outside eclipse using "standalone.bat" but get the same result. No error in the console, don't see the eclipse error anywhere, but the admin console doesn't show up.
> I have JBoss AS 7.1.1.Final and can access the console, but it may require a page refresh for it to fully display. Refreshing the page doesn't help in 8.1.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3467) Wildfly URI encoding (again..)
by Lars Pettersson (JIRA)
[ https://issues.jboss.org/browse/WFLY-3467?page=com.atlassian.jira.plugin.... ]
Lars Pettersson updated WFLY-3467:
----------------------------------
Description:
I have a very simple Servlet
@WebServlet("/HelloServlet")
public class HelloServlet extends HttpServlet
with a doGet method that prints and returns the "foo" parameter:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
String foo = request.getParameter("foo");
out.println("Hello " + foo);
System.out.println("Hello " + foo);
out.close();
}
When running jboss 7.1.1.Final this works fine. I can test with a simple curl script:
curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
where $'\xc3\xa5' is "aring" or "a with a ring", (å). I know the console can handle this, because echo $'\xc3\xa5' gives:
[slydell@localhost hello]$ echo $'\xc3\xa5'
å
[slydell@localhost hello]$
If I run the curl script on jboss 7.1.1.Final I get:
[slydell@localhost hello]$ curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
Hello bår
[slydell@localhost hello]$
and the jboss console output says:
09:18:19,483 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
I can change this output by adding
JAVA_OPTS="$JAVA_OPTS -Dorg.apache.catalina.connector.URI_ENCODING=UTF-8"
to the standalone.conf. With that flag I get:
09:20:57,780 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
But when I run the curl script on wildfly 8.1.0.Final I get different results. I know that the catalina flag has no effect on undertow, and I have also tried all the workarounds I've seen, e.g.
* implement a CharacterEncoding filter
* set encoding in jboss-web.xml
* set default-encoding in servlet-containter in the standalone.xml
* set encoding in the http-listener in the standalone.xml
None of these workarounds have any effect. I always get the same result:
09:22:42,330 INFO [stdout] (default task-1) Hello bￃﾥr
which does not look like anything I've seen in UTF-8 or ISO-8859-1.
If I could get the same output as I do in the jboss 7.1.1.Final (without the catalina flag) I would be very happy. The standard non-modified jboss 7.1.1 gave me this output:
09:31:11,723 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
So my question is, how do I modify/configure wildfly so that I get the same output as I do in the standard jboss 7.1.1.Final? I have tried the known workarounds, and they did not change any output.
was:
I have a very simple Servlet
@WebServlet("/HelloServlet")
public class HelloServlet extends HttpServlet
with a doGet method that prints and returns the "foo" parameter:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
String foo = request.getParameter("foo");
out.println("Hello " + foo);
System.out.println("Hello " + foo);
out.close();
}
When running jboss 7.1.1.Final this works fine. I can test with a simple curl script:
curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
where $'\xc3\xa5' is "aring" or "a with a ring", (å). I know the console can handle this, because echo $'\xc3\xa5' gives:
[slydell@localhost hello]$ echo $'\xc3\xa5'
å
[slydell@localhost hello]$
If I run the curl script on jboss 7.1.1.Final I get:
[slydell@localhost hello]$ curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
Hello bår
[slydell@localhost hello]$
and the jboss console output says:
09:18:19,483 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
I can change this output by adding
JAVA_OPTS="$JAVA_OPTS -Dorg.apache.catalina.connector.URI_ENCODING=UTF-8"
to the standalone.conf. With that flag I get:
09:20:57,780 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
But when I run the curl script on wildfly 8.1.0.Final I get different results. I know that the catalina flag has no effect on undertow, and I have also tried all the workarounds I've seen, e.g.
* implement a CharacterEncoding filter
* set encoding in jboss-web.xml
* set default-encoding in servlet-containter in the standalone.xml
* set encoding in the http-listener in the standalone.xml
None of these workarounds have any effect. I always get the same result:
09:22:42,330 INFO [stdout] (default task-1) Hello bￃﾥr
which does not look like anything I've seen in UTF-8 or ISO-8859-1.
If I could get the same output as I do in the jboss 7.1.1.Final (without the catalina flag) I would be very happy. The standard non-modified jboss 7.1.1 gave me this output:
09:31:11,723 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
So my question is, how do I modify/configure wildfly so that I get the same output as I do in the standard wildfly 7.1.1.Final? I have tried the known workarounds, and they did not change any output.
> Wildfly URI encoding (again..)
> ------------------------------
>
> Key: WFLY-3467
> URL: https://issues.jboss.org/browse/WFLY-3467
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Linux CentOS
> Reporter: Bob Slydell
> Assignee: Stuart Douglas
>
> I have a very simple Servlet
> @WebServlet("/HelloServlet")
> public class HelloServlet extends HttpServlet
> with a doGet method that prints and returns the "foo" parameter:
> protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> PrintWriter out = response.getWriter();
> String foo = request.getParameter("foo");
> out.println("Hello " + foo);
> System.out.println("Hello " + foo);
> out.close();
> }
> When running jboss 7.1.1.Final this works fine. I can test with a simple curl script:
> curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
> where $'\xc3\xa5' is "aring" or "a with a ring", (å). I know the console can handle this, because echo $'\xc3\xa5' gives:
> [slydell@localhost hello]$ echo $'\xc3\xa5'
> å
> [slydell@localhost hello]$
> If I run the curl script on jboss 7.1.1.Final I get:
> [slydell@localhost hello]$ curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
> Hello bår
> [slydell@localhost hello]$
> and the jboss console output says:
> 09:18:19,483 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
> I can change this output by adding
> JAVA_OPTS="$JAVA_OPTS -Dorg.apache.catalina.connector.URI_ENCODING=UTF-8"
> to the standalone.conf. With that flag I get:
> 09:20:57,780 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
> But when I run the curl script on wildfly 8.1.0.Final I get different results. I know that the catalina flag has no effect on undertow, and I have also tried all the workarounds I've seen, e.g.
> * implement a CharacterEncoding filter
> * set encoding in jboss-web.xml
> * set default-encoding in servlet-containter in the standalone.xml
> * set encoding in the http-listener in the standalone.xml
> None of these workarounds have any effect. I always get the same result:
> 09:22:42,330 INFO [stdout] (default task-1) Hello bￃﾥr
> which does not look like anything I've seen in UTF-8 or ISO-8859-1.
> If I could get the same output as I do in the jboss 7.1.1.Final (without the catalina flag) I would be very happy. The standard non-modified jboss 7.1.1 gave me this output:
> 09:31:11,723 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
> So my question is, how do I modify/configure wildfly so that I get the same output as I do in the standard jboss 7.1.1.Final? I have tried the known workarounds, and they did not change any output.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3467) Wildfly URI encoding (again..)
by Bob Slydell (JIRA)
Bob Slydell created WFLY-3467:
---------------------------------
Summary: Wildfly URI encoding (again..)
Key: WFLY-3467
URL: https://issues.jboss.org/browse/WFLY-3467
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.1.0.Final
Environment: Linux CentOS
Reporter: Bob Slydell
Assignee: Stuart Douglas
I have a very simple Servlet
@WebServlet("/HelloServlet")
public class HelloServlet extends HttpServlet
with a doGet method that prints and returns the "foo" parameter:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
String foo = request.getParameter("foo");
out.println("Hello " + foo);
System.out.println("Hello " + foo);
out.close();
}
When running jboss 7.1.1.Final this works fine. I can test with a simple curl script:
curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
where $'\xc3\xa5' is "aring" or "a with a ring", (å). I know the console can handle this, because echo $'\xc3\xa5' gives:
[slydell@localhost hello]$ echo $'\xc3\xa5'
å
[slydell@localhost hello]$
If I run the curl script on jboss 7.1.1.Final I get:
[slydell@localhost hello]$ curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
Hello bår
[slydell@localhost hello]$
and the jboss console output says:
09:18:19,483 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
I can change this output by adding
JAVA_OPTS="$JAVA_OPTS -Dorg.apache.catalina.connector.URI_ENCODING=UTF-8"
to the standalone.conf. With that flag I get:
09:20:57,780 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
But when I run the curl script on wildfly 8.1.0.Final I get different results. I know that the catalina flag has no effect on undertow, and I have also tried all the workarounds I've seen, e.g.
* implement a CharacterEncoding filter
* set encoding in jboss-web.xml
* set default-encoding in servlet-containter in the standalone.xml
* set encoding in the http-listener in the standalone.xml
None of these workarounds have any effect. I always get the same result:
09:22:42,330 INFO [stdout] (default task-1) Hello bￃﾥr
which does not look like anything I've seen in UTF-8 or ISO-8859-1.
If I could get the same output as I do in the jboss 7.1.1.Final (without the catalina flag) I would be very happy. The standard non-modified jboss 7.1.1 gave me this output:
09:31:11,723 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
So my question is, how do I modify/configure wildfly so that I get the same output as I do in the standard wildfly 7.1.1.Final? I have tried the known workarounds, and they did not change any output.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month