August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3706) Inconsistent DMR response structure

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3706?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-3706: ---------------------------------------- Do you have any more info on what the conditions were when this happened? Testing against master, the EAP 6.x branch and an EAP 6.2.2 build I have I get this: ``` [domain@localhost:9999 /] /profile=full/subsystem=ejb3/service=*:read-resource-description { "outcome" => "failed", "failure-description" => "JBAS014883: No resource definition is registered for address [ (\"profile\" => \"full\"), (\"subsystem\" => \"ejb3\"), (\"service\" => \"*\") ]", "rolled-back" => true } ``` Was the 'rbac' provider enabled? Maybe that matters. My EAP 6.x branch may be a a week or so out of date; I'll update and rebuild in case that matters. > 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)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3707) ":read-log-file" op throws OutOfMemoryError for big values of parameter "lines"

by Harald Pehl (JIRA)

Harald Pehl created WFLY-3707: --------------------------------- Summary: ":read-log-file" op throws OutOfMemoryError for big values of parameter "lines" Key: WFLY-3707 URL: https://issues.jboss.org/browse/WFLY-3707 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Reporter: Harald Pehl Assignee: James Perkins When passing big values for parameter "line" of the ":read-log-file" operation the servers throws an OutOfMemoryError. Maybe the parameter should be limited to a reasonable max-value. If #lines(log-file) < parameter(lines) no OOME should happen at all. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1201) Port JDBC resource adapter to JCA 1.6

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1201?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1201. ------------------------------------ Resolution: Done > Port JDBC resource adapter to JCA 1.6 > ------------------------------------- > > Key: JBJCA-1201 > URL: https://issues.jboss.org/browse/JBJCA-1201 > Project: IronJacamar > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Deployer, JDBC > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.2.0.Beta4 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1201) Port JDBC resource adapter to JCA 1.6

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1201: -------------------------------------- Summary: Port JDBC resource adapter to JCA 1.6 Key: JBJCA-1201 URL: https://issues.jboss.org/browse/JBJCA-1201 Project: IronJacamar Issue Type: Task Security Level: Public (Everyone can see) Components: Deployer, JDBC Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.2.0.Beta4 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 2 months

1
0
0 / 0

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

11 years, 2 months

1
0
0 / 0

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

11 years, 2 months

1
0
0 / 0

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

11 years, 2 months

1
0
0 / 0

[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 commented on LOGMGR-101: ----------------------------------- [~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)

11 years, 2 months

1
0
0 / 0

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

11 years, 2 months

1
0
0 / 0

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

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014