[JBoss JIRA] (WFCORE-563) Upgrade to Xerces 2.11.0
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFCORE-563?page=com.atlassian.jira.plugin... ]
Carlo de Wolf moved WFLY-3528 to WFCORE-563:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-563 (was: WFLY-3528)
Issue Type: Component Upgrade (was: Feature Request)
Affects Version/s: 1.0.0.Alpha19
(was: 8.1.0.Final)
Component/s: (was: Web Services)
> Upgrade to Xerces 2.11.0
> ------------------------
>
> Key: WFCORE-563
> URL: https://issues.jboss.org/browse/WFCORE-563
> Project: WildFly Core
> Issue Type: Component Upgrade
> Affects Versions: 1.0.0.Alpha19
> Environment: WildFly 8.1.0.Final, JDK 7, Ubuntu, Windows, Mac OS
> Reporter: Carlos Barragan
> Assignee: Carlo de Wolf
> Priority: Critical
> Attachments: stacktrace.txt
>
>
> Xerces 2.9.1 has a bug when parsing Times with "24" hrs.
> {code}
> DatatypeFactory.newInstance().newXMLGregorianCalendar("24:00:00Z");
> {code}
> We have this problem in one of our web services because we get request with the above time format.
> Xerces 2.11.0 does not contain that bug.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-562) Wrong order of elements in jboss-cli.xml
by Dominik Pospisil (JIRA)
Dominik Pospisil created WFCORE-562:
---------------------------------------
Summary: Wrong order of elements in jboss-cli.xml
Key: WFCORE-562
URL: https://issues.jboss.org/browse/WFCORE-562
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 1.0.0.Alpha19
Reporter: Dominik Pospisil
Assignee: Dominik Pospisil
File bin/jboss-cli.xml has an incorrect order of elements. <history> tag should be before <resolve-parameter-values> tag.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (REMJMX-84) Jboss JMX: Operation failed with status WAITING
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-84?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on REMJMX-84:
----------------------------------------
Firstly if you are a supported customer I would suggest raising a support case through the customer portal, the support engineers will be able to work with you to perform further diagnostics on exactly where time is being spent.
However, as a bug report the information supplied here up until this point is extremely vague - we have a generic error message that tells us a time out has occurred and a vague description as to how that error is being experienced.
If you are able to reproduce on a clean WildFly 8 installation and provide some clear steps as to how to reproduce this - ideally with a sample client then I can take a further look. But at this point the cause of your delay could just as easily be something specific to your own installation, for all I know garbage collection could be occurring at the time you get the intermittent time out.
Finally if you are not able to describe steps to reproduce a forum post may be the best way to ask for some community support in getting to the bottom of the delayed requests.
> Jboss JMX: Operation failed with status WAITING
> ------------------------------------------------
>
> Key: REMJMX-84
> URL: https://issues.jboss.org/browse/REMJMX-84
> Project: Remoting JMX
> Issue Type: Bug
> Environment: jboss-as-7.1.1.Final on windows server
> Reporter: Abhishek Apoorva
> Assignee: Darran Lofthouse
> Fix For: 2.0.1.CR1
>
>
> Version : jboss-as-7.1.1.Final on windows server
> I am getting below mentioned strange issue intermittently while fetching
> Jboss JMX Mbean.
> Can anyone help me to find the real cause of the issue? Secong thing is why it is coming intermittently either it should come always or it should not come at all.
> JMXConnectorFactory.connect(serviceURL, environment);
> While executing above mentioned line system is throwing below mentioned exception.
> {noformat}
> May 08 02:30:53:375 [DC#0, jboss] java.lang.RuntimeException: Operation failed with status WAITING
> at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:216)
> at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:143)
> at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:94)
> at javax.management.remote.JMXConnectorFactory.connect(Unknown Source)
> at com.nimsoft.nimbus.probe.application.jboss.JmxConnection.createConnection(JmxConnection.java:68)
> at com.nimsoft.nimbus.probe.application.jsr160.Entity.createConnection(Entity.java:1772)
> at com.nimsoft.nimbus.probe.application.jsr160.Entity.getValue(Entity.java:1567)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract.processMonitor(Extract.java:1324)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract.processResource(Extract.java:1908)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract$DataCollector.run(Extract.java:1158)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4382) Functionality to allow symbolic links
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4382?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-4382:
------------------------------
Component/s: Web (Undertow)
> Functionality to allow symbolic links
> -------------------------------------
>
> Key: WFLY-4382
> URL: https://issues.jboss.org/browse/WFLY-4382
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Erdal Yildiz
> Assignee: Jason Greene
> Priority: Minor
>
> There should be a possibility to configure that wildfly follows symbolic links.
> Example which describes the problem:
> $wildflyHome/welcome-content/test/index.html --> localhost:8080/test/index.html ==> works.
> $wildflyHome/welcome-content/symlink/index.html --> localhost:8080/symlink/index.html ==> doesn't work.
> "symlink" is the symbolic link which is created by
> ln -s /path/to/symlink $wildflyHome/welcome-content
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4382) Functionality to allow symbolic links
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4382?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-4382:
---------------------------------
Assignee: Tomaz Cerar (was: Jason Greene)
> Functionality to allow symbolic links
> -------------------------------------
>
> Key: WFLY-4382
> URL: https://issues.jboss.org/browse/WFLY-4382
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Erdal Yildiz
> Assignee: Tomaz Cerar
> Priority: Minor
>
> There should be a possibility to configure that wildfly follows symbolic links.
> Example which describes the problem:
> $wildflyHome/welcome-content/test/index.html --> localhost:8080/test/index.html ==> works.
> $wildflyHome/welcome-content/symlink/index.html --> localhost:8080/symlink/index.html ==> doesn't work.
> "symlink" is the symbolic link which is created by
> ln -s /path/to/symlink $wildflyHome/welcome-content
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1914:
--------------------------------
That would be terrific !
Note that I also sent out an email on jg-dev and our internal clustering list, to see if someone's willing to submit a PR. Therefore I suggest indicate that/if you're starting work on the fix, so other don't start duplicate work.
Cheers,
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Gleb Leonov (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Gleb Leonov commented on JGRP-1914:
-----------------------------------
I think that I know how to deal with this issue, so if I'll manage to fix it, I'll surely submit a PR.
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months