[JBoss JIRA] (WFLY-3724) Batch jobs don't receive partition-specific parameters
by Ari Silvan (JIRA)
Ari Silvan created WFLY-3724:
--------------------------------
Summary: Batch jobs don't receive partition-specific parameters
Key: WFLY-3724
URL: https://issues.jboss.org/browse/WFLY-3724
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Batch
Affects Versions: 8.1.0.Final
Environment: Windows 7 Home Premium Service Pack 1 64-bit + JDK8u11 + WildFly 8.1.0 Final
Reporter: Ari Silvan
Assignee: Jason Greene
When defining a batch job chunk step to run as partitions, ItemReader doesn't receive the partition-specific parameters specified by an implementation of the PartitionPlan interface. Parameters are null. See steps to reproduce for further details.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBJCA-1204) WrappedConnection.invalidate()
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1204:
--------------------------------------
Summary: WrappedConnection.invalidate()
Key: JBJCA-1204
URL: https://issues.jboss.org/browse/JBJCA-1204
Project: IronJacamar
Issue Type: Task
Security Level: Public (Everyone can see)
Components: JDBC
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.0.Beta4
Provide an
{noformat}
public void invalidate() throws SQLException
{noformat}
method, that closes the connection with an error.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFCORE-47) Enable operation arguments to accept special value characters
by James Perkins (JIRA)
James Perkins created WFCORE-47:
-----------------------------------
Summary: Enable operation arguments to accept special value characters
Key: WFCORE-47
URL: https://issues.jboss.org/browse/WFCORE-47
Project: WildFly Core
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: CLI
Reporter: James Perkins
Assignee: Alexey Loubyansky
Priority: Minor
In CLI passing an argument {{\n}} to an operation strips the leading {{\}} from the string. This can be averted by adding an extra {{\}}, {{\\n}}, but then the second {{\}} and the {{n}} are treated as separate characters instead of a single newline character.
It would be nice if CLI could recognize these special characters and treat them as the special character. One idea might be to use something like the [{{java.util.Formatter}}|http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html] and expect values like {{%n}} instead of the {{\n}}. Either way really works though.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3464) Nonexistent ldap group causes authentication to fail in security-realm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3464?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3464:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1105677, https://bugzilla.redhat.com/show_bug.cgi?id=1105619, https://bugzilla.redhat.com/show_bug.cgi?id=1127938, https://bugzilla.redhat.com/show_bug.cgi?id=1128176 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1105677, https://bugzilla.redhat.com/show_bug.cgi?id=1105619, https://bugzilla.redhat.com/show_bug.cgi?id=1127938)
> Nonexistent ldap group causes authentication to fail in security-realm
> -----------------------------------------------------------------------
>
> Key: WFLY-3464
> URL: https://issues.jboss.org/browse/WFLY-3464
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> The LdapGroupSearcher code will fail if it tries to lookup a group that
> does not exist on the local ldap server.
> This can happen when the ldap systems are configured as trusted domains.
> Even though the security-realm is not configured to use the trusted domain
> (it is configured to only look at a single ldap server), the
> user's entry on one ldap server could point at a group that exists on
> the other (trusted) ldap server.
> The LdapGroupSearcher code attempts to lookup this role and it fails. This
> failure is sent back to the http server which results in an HTTP 500 error
> and leaves the user with no way to authenticate/login.
> There is currently not a way to tell the group searcher code to ignore the
> group/role that cannot be found.
> 2014-06-06 12:44:39,819 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Group found with distinguishedName=cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com
> 2014-06-06 12:44:39,821 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Failure supplementing Subject: javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com'
> at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3112) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1332) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:127) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:256) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:191) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:223) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:200) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:155) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:120) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:110) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:57) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3719) Missing <uri> in the tld files causes NullPointerException during deployment on WildFly
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3719?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma commented on WFLY-3719:
-------------------------------------------
Sent a pull request for Null Checking,
https://github.com/wildfly/wildfly/pull/6590
> Missing <uri> in the tld files causes NullPointerException during deployment on WildFly
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3719
> URL: https://issues.jboss.org/browse/WFLY-3719
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Stuart Douglas
> Attachments: TagClassDemo.war
>
>
> - If The TLD file has missing *<uri>* tag in it then rather than validating WildFly throws NullPointerException.
> *WEB-INF/custom.tld*
> {code}
> <taglib>
> <tlib-version>1.0</tlib-version>
> <jsp-version>2.0</jsp-version>
> <!--uri>test</uri-->
> <short-name>Example TLD with Body</short-name>
> <tag>
> <name>Hello</name>
> <tag-class>tags.HelloTag</tag-class>
> <body-content>scriptless</body-content>
> </tag>
> </taglib>
> {code}
> - During deployment of a war containing above TLD causes following NullPointerException on WildFly:
> {code}
> 13:15:25,857 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [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_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createTldsInfo(UndertowDeploymentInfoService.java:1028)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:552)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252)
> 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]
> ... 3 more
> 13:15:25,865 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3723) setting the local to english in CLI commands on non-english systems does not produce english output
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3723?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3723:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1128132
> setting the local to english in CLI commands on non-english systems does not produce english output
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-3723
> URL: https://issues.jboss.org/browse/WFLY-3723
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Localization
> Affects Versions: 8.1.0.Final
> Environment: Tested on MacOS running in German
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> A German (or french etc...) system must be used to reproduce.
> It is likely this is not limited to MacOS, but I do not have a non-english Linux system available
> An out of the box install of wildfly/EAP:
> Without configuration, the log file is in German as expected.
> Using these CLI comands:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> german
> :read-operation-description(name=stop-servers,locale=fr_FR) -> french
> So we cannot get the CLI to produce english output
> when configuring JAVA_OPTS in domain.conf with:
> JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8
> The log is now in English -> works as expected; and:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> english
> So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked)
> I presume this is because English is the default locale.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3723) setting the local to english in CLI commands on non-english systems does not produce english output
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-3723?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne updated WFLY-3723:
-------------------------------
Component/s: Localization
(was: CLI)
> setting the local to english in CLI commands on non-english systems does not produce english output
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-3723
> URL: https://issues.jboss.org/browse/WFLY-3723
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Localization
> Affects Versions: 8.1.0.Final
> Environment: Tested on MacOS running in German
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> A German (or french etc...) system must be used to reproduce.
> It is likely this is not limited to MacOS, but I do not have a non-english Linux system available
> An out of the box install of wildfly/EAP:
> Without configuration, the log file is in German as expected.
> Using these CLI comands:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> german
> :read-operation-description(name=stop-servers,locale=fr_FR) -> french
> So we cannot get the CLI to produce english output
> when configuring JAVA_OPTS in domain.conf with:
> JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8
> The log is now in English -> works as expected; and:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> english
> So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked)
> I presume this is because English is the default locale.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3723) setting the local to english in CLI commands on non-english systems does not produce english output
by Tom Fonteyne (JIRA)
Tom Fonteyne created WFLY-3723:
----------------------------------
Summary: setting the local to english in CLI commands on non-english systems does not produce english output
Key: WFLY-3723
URL: https://issues.jboss.org/browse/WFLY-3723
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 8.1.0.Final
Environment: Tested on MacOS running in German
Reporter: Tom Fonteyne
Assignee: Alexey Loubyansky
Priority: Minor
A German (or french etc...) system must be used to reproduce.
It is likely this is not limited to MacOS, but I do not have a non-english Linux system available
An out of the box install of wildfly/EAP:
Without configuration, the log file is in German as expected.
Using these CLI comands:
:read-operation-description(name=stop-servers,locale=de_DE) -> german
:read-operation-description(name=stop-servers,locale=en_US) -> german
:read-operation-description(name=stop-servers,locale=fr_FR) -> french
So we cannot get the CLI to produce english output
when configuring JAVA_OPTS in domain.conf with:
JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8
The log is now in English -> works as expected; and:
:read-operation-description(name=stop-servers,locale=de_DE) -> german
:read-operation-description(name=stop-servers,locale=en_US) -> english
So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked)
I presume this is because English is the default locale.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months