December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1384) Objects in a List is not correctly unmarshalled by JSONMarshaller

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1384?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1384: ------------------------------------- Assignee: Maciej Swiderski (was: Edson Tirelli) > Objects in a List is not correctly unmarshalled by JSONMarshaller > ----------------------------------------------------------------- > > Key: DROOLS-1384 > URL: https://issues.jboss.org/browse/DROOLS-1384 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.0.0.Beta4 > Reporter: Toshiya Kobayashi > Assignee: Maciej Swiderski > Labels: support > > When JSONMarshaller marshalls and unmarshalls an object which has a List and the List contains custom class objects, the objects inside the List are instantiated but their properties are not populated. > For example) > Before marshall: > {noformat} > PojoA [name=A, pojoBList=[PojoB [name=B1, pojoCList=[PojoC [name=C1], PojoC [name=C2]]], PojoB [name=B2, pojoCList=[PojoC [name=C3]]]], stringList=[Hello, Bye]] > {noformat} > After marshall+unmarshall: > {noformat} > PojoA [name=A, pojoBList=[PojoB [name=null, pojoCList=null], PojoB [name=null, pojoCList=null]], stringList=[Hello, Bye]] > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1384) Objects in a List is not correctly unmarshalled by JSONMarshaller

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1384?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi updated DROOLS-1384: -------------------------------------- Git Pull Request: https://github.com/droolsjbpm/droolsjbpm-integration/pull/764 > Objects in a List is not correctly unmarshalled by JSONMarshaller > ----------------------------------------------------------------- > > Key: DROOLS-1384 > URL: https://issues.jboss.org/browse/DROOLS-1384 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.0.0.Beta4 > Reporter: Toshiya Kobayashi > Assignee: Edson Tirelli > Labels: support > > When JSONMarshaller marshalls and unmarshalls an object which has a List and the List contains custom class objects, the objects inside the List are instantiated but their properties are not populated. > For example) > Before marshall: > {noformat} > PojoA [name=A, pojoBList=[PojoB [name=B1, pojoCList=[PojoC [name=C1], PojoC [name=C2]]], PojoB [name=B2, pojoCList=[PojoC [name=C3]]]], stringList=[Hello, Bye]] > {noformat} > After marshall+unmarshall: > {noformat} > PojoA [name=A, pojoBList=[PojoB [name=null, pojoCList=null], PojoB [name=null, pojoCList=null]], stringList=[Hello, Bye]] > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1384) Objects in a List is not correctly unmarshalled by JSONMarshaller

by Toshiya Kobayashi (JIRA)

Toshiya Kobayashi created DROOLS-1384: ----------------------------------------- Summary: Objects in a List is not correctly unmarshalled by JSONMarshaller Key: DROOLS-1384 URL: https://issues.jboss.org/browse/DROOLS-1384 Project: Drools Issue Type: Bug Components: kie server Affects Versions: 7.0.0.Beta4 Reporter: Toshiya Kobayashi Assignee: Edson Tirelli When JSONMarshaller marshalls and unmarshalls an object which has a List and the List contains custom class objects, the objects inside the List are instantiated but their properties are not populated. For example) Before marshall: {noformat} PojoA [name=A, pojoBList=[PojoB [name=B1, pojoCList=[PojoC [name=C1], PojoC [name=C2]]], PojoB [name=B2, pojoCList=[PojoC [name=C3]]]], stringList=[Hello, Bye]] {noformat} After marshall+unmarshall: {noformat} PojoA [name=A, pojoBList=[PojoB [name=null, pojoCList=null], PojoB [name=null, pojoCList=null]], stringList=[Hello, Bye]] {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2137) [GSS](7.1.0) NPE thrown during application redeployment, slaves taken offline

by Brad Maxwell (JIRA)

Brad Maxwell created WFCORE-2137: ------------------------------------ Summary: [GSS](7.1.0) NPE thrown during application redeployment, slaves taken offline Key: WFCORE-2137 URL: https://issues.jboss.org/browse/WFCORE-2137 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brad Maxwell Assignee: ehsavoie Hugonnet Fix For: 3.0.0.Alpha2 We have some development Wildfly 10.0.0 servers running as slaves in a domain that frequently have WAR files redeployed. We have noticed that these slaves will often go offline after a redeployment of WAR files with the following stack trace: {code} 2016-05-06 05:05:51,306 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 1012) WFLYCTL0190: Step handler org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler@3f68226b for operation {"operation" => "full-replace-deployment","name" => "whatever.war","enabled" => true,"content" => [{"hash" => bytes { 0x5d, 0x12, 0x18, 0x2b, 0x1c, 0x86, 0x71, 0x27, 0x08, 0x3d, 0xf1, 0x75, 0x08, 0x29, 0xa6, 0x49, 0x1f, 0x16, 0xe8, 0x22 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "802ab616-dd2c-4081-a79c-c4d54e14c384","push-to-servers" => undefined},"address" => [],"runtime-name" => undefined} at address [] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException at org.jboss.as.repository.LocalDeploymentFileRepository.deleteDeployment(LocalDeploymentFileRepository.java:59) at org.jboss.as.host.controller.RemoteDomainConnectionService$RemoteFileRepository.deleteDeployment(RemoteDomainConnectionService.java:756) at org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler$1.handleResult(DeploymentFullReplaceHandler.java:181) at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384) at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366) at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328) at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311) at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:360) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} This error will usually only happen for 2 out of the 4 identically configured slaves, and seems to happen randomly, although frequently enough. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2136) Using management CLI with client configuration still prompts for username/password

by Zach Rhoads (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2136?page=com.atlassian.jira.plugi... ] Zach Rhoads reassigned WFCORE-2136: ----------------------------------- Assignee: Darran Lofthouse > Using management CLI with client configuration still prompts for username/password > ---------------------------------------------------------------------------------- > > Key: WFCORE-2136 > URL: https://issues.jboss.org/browse/WFCORE-2136 > Project: WildFly Core > Issue Type: Bug > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > > When configuring the wildfly management cli to use an elytron client config file, server still prompts for username password. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2136) Using management CLI with client configuration still prompts for username/password

by Zach Rhoads (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2136?page=com.atlassian.jira.plugi... ] Zach Rhoads updated WFCORE-2136: -------------------------------- Steps to Reproduce: configure management interface {code} /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"}) /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm}],default-realm=exampleFsRealm,permission-mapper=default-permission-mapper) /subsystem=elytron/http-authentication-factory=example-fs-http-auth:add(http-server-mechanism-factory=global,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=exampleApplicationDomain}]}]) /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleManagementRealm}]}]) /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth) reload {code} create custom-config.xml {code:xml} <configuration> <authentication-client xmlns="urn:elytron:1.0"> <authentication-rules> <rule use-configuration="configuration1"> <match-host name="localhost" /> </rule> </authentication-rules> <authentication-configurations> <configuration name="configuration1"> <allow-sasl-mechanisms names="DIGEST-MD5" /> <use-service-loader-providers /> <set-user-name name="user1" /> <credentials> <clear-password password="password123" /> </credentials> <set-mechanism-realm name="exampleManagementRealm" /> </configuration> </authentication-configurations> </authentication-client> </configuration> {code} attempt to connect using custom-config.xml {code} ./jboss-cli.sh -c -Dwildfly.config.url=/path/to/custom-config.xml --controller=localhost:9990 {code} responds prompting for username {code} Authenticating against security realm: exampleManagementRealm Username: {code} was: configure management interface {code} /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"}) /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm}],default-realm=exampleFsRealm,permission-mapper=default-permission-mapper) /subsystem=elytron/http-authentication-factory=example-fs-http-auth:add(http-server-mechanism-factory=global,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=exampleApplicationDomain}]}]) /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleManagementRealm}]}]) /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth) reload {code} create custom-config.xml {code:xml} <configuration> <authentication-client xmlns="urn:elytron:1.0"> <authentication-rules> <rule use-configuration="configuration1"> <match-host name="localhost" /> </rule> </authentication-rules> <authentication-configurations> <configuration name="configuration1"> <allow-sasl-mechanisms names="DIGEST-MD5" /> <use-service-loader-providers /> <set-user-name name="user1" /> <credentials> <clear-password password="password123" /> </credentials> <set-mechanism-realm name="exampleManagementRealm" /> </configuration> </authentication-configurations> </authentication-client> </configuration> {code} attempt to connect using custom-config.xml {code} ./jboss-cli.sh -c -Dwildfly.config.url=/path/to/custom-config.xml --controller=localhost:9990 Authenticating against security realm: exampleManagementRealm Username: {code} > Using management CLI with client configuration still prompts for username/password > ---------------------------------------------------------------------------------- > > Key: WFCORE-2136 > URL: https://issues.jboss.org/browse/WFCORE-2136 > Project: WildFly Core > Issue Type: Bug > Reporter: Zach Rhoads > > When configuring the wildfly management cli to use an elytron client config file, server still prompts for username password. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2136) Using management CLI with client configuration still prompts for username/password

by Zach Rhoads (JIRA)

Zach Rhoads created WFCORE-2136: ----------------------------------- Summary: Using management CLI with client configuration still prompts for username/password Key: WFCORE-2136 URL: https://issues.jboss.org/browse/WFCORE-2136 Project: WildFly Core Issue Type: Bug Reporter: Zach Rhoads When configuring the wildfly management cli to use an elytron client config file, server still prompts for username password. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2135) Upgrade xnio to 3.4.3.Final

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2135?page=com.atlassian.jira.plugi... ] Kabir Khan moved JBEAP-7972 to WFCORE-2135: ------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2135 (was: JBEAP-7972) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Remoting (was: Remoting) > Upgrade xnio to 3.4.3.Final > --------------------------- > > Key: WFCORE-2135 > URL: https://issues.jboss.org/browse/WFCORE-2135 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Kabir Khan > Assignee: Kabir Khan > > This is needed to expose the stats required for EAP7-616 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-854) OAuth2SaslServer is missing authorization and mechanism information

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-854?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-854: --------------------------- Summary: OAuth2SaslServer is missing authorization and mechanism information (was: OAuth2SaslServer is missing authorization) > OAuth2SaslServer is missing authorization and mechanism information > ------------------------------------------------------------------- > > Key: ELY-854 > URL: https://issues.jboss.org/browse/ELY-854 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.1.0.Beta18 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta19 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-853) OAuth2CredentialSource must handle BearerTokenCredential only

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-853?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-853: --------------------------- Summary: OAuth2CredentialSource must handle BearerTokenCredential only (was: OAuth2CredentialSource must handle only BearerTokenCredential) > OAuth2CredentialSource must handle BearerTokenCredential only > ------------------------------------------------------------- > > Key: ELY-853 > URL: https://issues.jboss.org/browse/ELY-853 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Affects Versions: 1.1.0.Beta18 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta19 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2016