[JBoss JIRA] (JBBUILD-738) Wrong link in the web
by David Hladky (JIRA)
David Hladky created JBBUILD-738:
------------------------------------
Summary: Wrong link in the web
Key: JBBUILD-738
URL: https://issues.jboss.org/browse/JBBUILD-738
Project: JBoss Build System
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: David Hladky
Assignee: Paul Gier
I checked the links mentioned in ORG-2187. I browsed the web page and it is wrong there as well. It is not clear what are the proper links so I am opening a ticket here.
For more details see ORG-2187
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (WFLY-2524) logging-profile works for a servlet, but doesn't for a JSP
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2524?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2524:
-----------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1031448|https://bugzilla.redhat.com/show_bug.cgi?id=1031448] from NEW to ASSIGNED
> logging-profile works for a servlet, but doesn't for a JSP
> ----------------------------------------------------------
>
> Key: WFLY-2524
> URL: https://issues.jboss.org/browse/WFLY-2524
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 8.0.0.Beta1
> Reporter: Osamu Nagano
> Assignee: James Perkins
> Attachments: logone.zip
>
>
> Suppose the following logging-profile has been set in logging subsystem, and a web app has a proper entry in its MANIFEST.MF ({{Logging-Profile: logone}}). Then all messages via "com.example.logone" logger should go into a file, logone.log. It does so with a logger got in a servlet, but it doesn't work a logger got in a JSP.
> {code}
> <logging-profiles>
> <logging-profile name="logone">
> <file-handler name="logone">
> <level name="INFO"/>
> <file relative-to="jboss.server.log.dir" path="logone.log"/>
> </file-handler>
> <logger category="com.example.logone">
> <level name="INFO"/>
> </logger>
> <root-logger>
> <level name="INFO"/>
> <handlers>
> <handler name="logone"/>
> </handlers>
> </root-logger>
> </logging-profile>
> </logging-profiles>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (LOGMGR-101) Allow SyslogHandler to automatically try a reconnect
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-101?page=com.atlassian.jira.plugin... ]
Kabir Khan edited comment on LOGMGR-101 at 8/4/14 5:16 AM:
-----------------------------------------------------------
[~jamezp] Yes, I handled it in the WIldFly layer, see linked WFLY issue
was (Author: kabirkhan):
[~jamezp] Yes, I handled it in the WIldFly layer, see attached WFLY issue
> Allow SyslogHandler to automatically try a reconnect
> ----------------------------------------------------
>
> Key: LOGMGR-101
> URL: https://issues.jboss.org/browse/LOGMGR-101
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.5.2.Final
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently the {{SyslogHandler}} does not attempt to reconnect if the connection is dropped. Some logic around trying a reconnect should be added.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (WFLY-3575) Parameterize subsystem version in xsite/jgroups testsuite xslt stylesheet
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3575?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3575:
---------------------------------
Fix Version/s: 9.0.0.Beta1
> Parameterize subsystem version in xsite/jgroups testsuite xslt stylesheet
> -------------------------------------------------------------------------
>
> Key: WFLY-3575
> URL: https://issues.jboss.org/browse/WFLY-3575
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Fix For: 9.0.0.Beta1
>
>
> I wasted a good couple of hours today trying to figure out why my changes broke the xsite tests. It turns out that the xslt scripts have the subsystem schema version hardcoded, and I had created a new schema version.
> We should parameterize this, in the same way as the addCacheContainer.xsl stylesheet does.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (WFLY-1357) XSLT scripts for integration tests failing silently
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1357?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-1357:
--------------------------------------
{quote}
We need to have a general mechanism in place to work around the need to hardcode namespace versions when the namespace version is general and not specific. This needs to be applied to most XSLT scripts.
{quote}
Most transformations now ignore the concrete version (mostly rbac being an exception here), the remaining jgroups/infinispan done in WFLY-3575.
> XSLT scripts for integration tests failing silently
> ---------------------------------------------------
>
> Key: WFLY-1357
> URL: https://issues.jboss.org/browse/WFLY-1357
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Environment: Wildfly integration tests
> Reporter: Richard Achmatowicz
> Assignee: Ondrej Zizka
>
> We use XSLT scripts to build custom Wildfly distributions for testing.
> Hard-coding of Wildfly subsystem namespace versions with no corresponding update to the scripts when schema versions change is causing XSLT scripts to be executed but silently not carry out the intended changes, resulting in broken test cases, of which no one is aware.
> For example:
> <xsl:stylesheet xmlns:jgroups="urn:jboss:domain:jgroups:1.1"
> <xsl:template match="//jgroups:subsystem">
> // do something
> </xsl:template>
> <xsl:stylesheet>
> will do nothing when executed against a 2.0 jgroups schema.
> We need to have a general mechanism in place to work around the need to hardcode namespace versions when the namespace version is general and not specific. This needs to be applied to most XSLT scripts.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (WFLY-3706) Inconsistent DMR response structure
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-3706?page=com.atlassian.jira.plugin.... ]
Heiko Braun edited comment on WFLY-3706 at 8/4/14 4:16 AM:
-----------------------------------------------------------
Take a look at the response structure : outcome:success > result > outcome:failed
> Inconsistent DMR response structure
> -----------------------------------
>
> Key: WFLY-3706
> URL: https://issues.jboss.org/browse/WFLY-3706
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
>
> {noformat}
> {
> "address" => [
> ("profile" => "full"),
> ("subsystem" => "ejb3"),
> ("service" => "*")
> ],
> "operation" => "read-resource-description"
> }
> {
> "outcome" => "success",
> "result" => {
> "outcome" => "failed",
> "failure-description" => "JBAS014883: No resource definition is registered for address [
> (\"profile\" => \"full\"),
> (\"subsystem\" => \"ejb3\"),
> (\"service\" => \"*\")
> ]",
> "rolled-back" => true
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (WFLY-3706) Inconsistent DMR response structure
by Heiko Braun (JIRA)
Heiko Braun created WFLY-3706:
---------------------------------
Summary: Inconsistent DMR response structure
Key: WFLY-3706
URL: https://issues.jboss.org/browse/WFLY-3706
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
{noformat}
{
"address" => [
("profile" => "full"),
("subsystem" => "ejb3"),
("service" => "*")
],
"operation" => "read-resource-description"
}
{
"outcome" => "success",
"result" => {
"outcome" => "failed",
"failure-description" => "JBAS014883: No resource definition is registered for address [
(\"profile\" => \"full\"),
(\"subsystem\" => \"ejb3\"),
(\"service\" => \"*\")
]",
"rolled-back" => true
}
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months