September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6263) Apostrophe in an attribute with multiple EL parts breaks function lookup

by Helmut Seruega (JIRA)

[ https://issues.jboss.org/browse/WFLY-6263?page=com.atlassian.jira.plugin.... ] Helmut Seruega commented on WFLY-6263: -------------------------------------- same problem here with WildFly 10.1.0.Final > Apostrophe in an attribute with multiple EL parts breaks function lookup > ------------------------------------------------------------------------ > > Key: WFLY-6263 > URL: https://issues.jboss.org/browse/WFLY-6263 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Paul Pogonyshev > Assignee: Jason Greene > Priority: Critical > Attachments: jastow-bug.war.zip, jastow.diff > > > Certain EL pieces result in unexplained org.apache.jasper.JasperException "contains invalid expression(s)" (the exception _does not_ explain what is invalid). After lots of tries, I have narrowed it down: 1) there must be several EL pieces in one string; 2) there must be an apostrophe in between. > This looks very similar to bug WFLY-4455. It breaks several pages in our application, blocking upgrade to WildFly 10. > Example is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7218) Unable to setup CLIENT_CERT authentication with elytron.

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7218?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6206 to WFLY-7218: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7218 (was: JBEAP-6206) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR5) > Unable to setup CLIENT_CERT authentication with elytron. > -------------------------------------------------------- > > Key: WFLY-7218 > URL: https://issues.jboss.org/browse/WFLY-7218 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > Following Zach's notes on [How to setup 2 way TLS|https://gitlab.cee.redhat.com/zrhoads/kbase/blob/master/eap71.elytron...] I am unable to setup it properly. User is not requested by browser for specifying client certificate and get access to application without certificate. > In log you there is: > 1. Server send request for certificate > {code} > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) *** CertificateRequest > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Types: RSA, DSS, ECDSA > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Authorities: > ^[[0m^[[0m13:55:33,310 INFO [stdout] (default task-1) <CN=client> > {code} > 2. And client responds with empty certificate chain. Without asking for certificate > {code} > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** Certificate chain > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) <Empty> > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** > {code} > I am attaching: > * server.log - server log with -Djavax.net.debug=all turn on. > * 2wayTLS.pcap - wireshark recording of port 8443 > * secured-app - tested application -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-631 at 9/26/16 8:35 AM: --------------------------------------------------------- The problem is: * Subsystem does not know if Permission should have a name (depends on class name) * The Permission doesnt know anything about subsystem attributes (like target-name) Ideas: * Catch IllegalArgumentException in subsystem and if message/attribute match "name" (Permission param), rewrite to "target-name" (attribute in subsystem) ? was (Author: honza889): The error message mean parameter *name* of *AbstractNamedPermission*. The problem is: * Subsystem does not know if Permission should have a name (depends on class name) * The Permission doesnt know anything about subsystem attributes (like target-name) Ideas: * Catch IllegalArgumentException in subsystem and if message/attribute match "name" (Permission param), rewrite to "target-name" (attribute in subsystem) ? > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: ELY-631 > URL: https://issues.jboss.org/browse/ELY-631 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-631 at 9/26/16 8:32 AM: --------------------------------------------------------- The error message mean parameter *name* of *AbstractNamedPermission*. The problem is: * Subsystem does not know if Permission should have a name (depends on class name) * The Permission doesnt know anything about subsystem attributes (like target-name) Ideas: * Catch IllegalArgumentException in subsystem and if message/attribute match "name" (Permission param), rewrite to "target-name" (attribute in subsystem) ? was (Author: honza889): The error message mean parameter *name* of *AbstractNamedPermission*. The problem is: * Subsystem does not know if Permission should have a name (depends on class name) * The Permission doesnt know anything about subsystem attributes Ideas: * Catch IllegalArgumentException in subsystem and if message/attribute match "name" (Permission param), rewrite to "target-name" (attribute in subsystem) ? > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: ELY-631 > URL: https://issues.jboss.org/browse/ELY-631 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-631 at 9/26/16 8:31 AM: --------------------------------------------------------- The error message mean parameter *name* of *AbstractNamedPermission*. The problem is: * Subsystem does not know if Permission should have a name (depends on class name) * The Permission doesnt know anything about subsystem attributes Ideas: * Catch IllegalArgumentException in subsystem and if message/attribute match "name" (Permission param), rewrite to "target-name" (attribute in subsystem) ? was (Author: honza889): Note: The error message mean parameter *name* of *AbstractNamedPermission*. > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: ELY-631 > URL: https://issues.jboss.org/browse/ELY-631 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1824) Can not parse object attributes that contains a Properties attribute

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFCORE-1824: ----------------------------------- Summary: Can not parse object attributes that contains a Properties attribute Key: WFCORE-1824 URL: https://issues.jboss.org/browse/WFCORE-1824 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha8 Reporter: Jeff Mesnil Assignee: Brian Stansberry My resource defines an attribute which is a LIST of OBJECT that corresponds to a class (class name + module) and Properties that are passed to the created instance: {noformat} private static final String CLASS = "class"; private static final String MODULE = "module"; public static final PropertiesAttributeDefinition PROPERTIES = new PropertiesAttributeDefinition.Builder("properties", true) .setAllowExpression(true) .build(); public static final ObjectTypeAttributeDefinition PROCESS_STATE_LISTENER = ObjectTypeAttributeDefinition.Builder.of("process-state-listener", SimpleAttributeDefinitionBuilder.create(CLASS, ModelType.STRING, false) .setAllowExpression(false) .build(), SimpleAttributeDefinitionBuilder.create(MODULE, ModelType.STRING, false) .setAllowExpression(false) .build(), PROPERTIES) .setRestartAllServices() .setAllowNull(true) .build(); public static final AttributeDefinition PROCESS_STATE_LISTENERS = ObjectListAttributeDefinition.Builder.of("listeners", PROCESS_STATE_LISTENER) .setAllowNull(false) .setRuntimeServiceNotRequired() .build(); {noformat} I can create the resource from the CLI: {noformat} /subsystem=core-management/service=process-state-listeners:add(listeners=[{class=org.foo.Listener, module=org.foo,, properties = {foo = true, bar = ${bar.prop:2}}}]) {"outcome" => "success"} {noformat} And the resource and its attribute is properly marshalled to the XML configuration: {noformat} <process-state-listeners> <listeners> <process-state-listener class="org.foo.Listener" module="org.foo"> <properties> <property name="foo" value="true"/> <property name="bar" value="${bar.prop:2}"/> </properties> </process-state-listener> </listeners> </process-state-listeners> {noformat} However the resource can not be parsed and it fails with the exception: {noformat} boss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) ... 3 more 09:45:00,537 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.{noformat} The code in org.jboss.as.controller.AttributeParser#parseElement:197 to parse a list of objects assumes that the object's value are all represented by XML attributes. In my case, that's not correct as the "properties" attribute is represented by XML elements. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-631 at 9/26/16 8:23 AM: --------------------------------------------------------- Note: The error message mean parameter *name* of *AbstractNamedPermission*. was (Author: honza889): Note: The error message mean parameter *name* of *AbstractNameOnlyPermission*. > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: ELY-631 > URL: https://issues.jboss.org/browse/ELY-631 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-631: -------------------------------- Note: The error message mean parameter *name* of *AbstractNameOnlyPermission*. > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: ELY-631 > URL: https://issues.jboss.org/browse/ELY-631 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7203) Elytron - inconsistency between DMR and XSD representation of regex-name-validating-rewriter

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7203?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7203: ---------------------------------- Match should be optional - it has default value. (in both - XSD and in model) > Elytron - inconsistency between DMR and XSD representation of regex-name-validating-rewriter > -------------------------------------------------------------------------------------------- > > Key: WFLY-7203 > URL: https://issues.jboss.org/browse/WFLY-7203 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Tymel > Assignee: Darran Lofthouse > Priority: Optional > > There is an inconsistency between DMR and XSD representation of {{regex-name-validating-rewriter}}. > According to XSD[1] is {{match}} attribute optional. On the other hand DMR[2] says that {{match}} attribute is mandatory (_"nillable" => false_). > {{Match}} attribute is currently required if user adds a new regex-name-validating-rewriter. Is it an intentional behaviour or should {{match}} be optional (=according to XSD definition)? > [1] https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... > [2] {{/subsystem=elytron:read-resource-description(recursive=true)}} > {code} > "regex-name-validating-rewriter" => { > "description" => "A regular expression based Name Rewriter which uses the regular expression to validate the name.", > "model-description" => {"*" => { > "description" => "A regular expression based Name Rewriter which uses the regular expression to validate the name.", > "capabilities" => [{ > "name" => "org.wildfly.security.name-rewriter", > "dynamic" => true > }], > "attributes" => { > "match" => { > "type" => BOOLEAN, > "description" => "Should names that match the pattern be rejected or names that don't", > "expressions-allowed" => true, > "nillable" => false, > "default" => true, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "pattern" => { > "type" => STRING, > "description" => "The regular expression to use to locate the portion of the name to be replaced.", > "expressions-allowed" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > } > }, > "operations" => undefined, > "notifications" => undefined, > "children" => {} > }} > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1823) ConnectDialog uses JDK internal sun.tools.jconsole.Utilities.ensureContrast

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFCORE-1823: ----------------------------------------- Summary: ConnectDialog uses JDK internal sun.tools.jconsole.Utilities.ensureContrast Key: WFCORE-1823 URL: https://issues.jboss.org/browse/WFCORE-1823 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Rostislav Svoboda Assignee: Bartosz Baranowski Fix For: 3.0.0.Alpha8 ConnectDialog uses sun.tools.jconsole.Utilities.ensureContrast JDK internal API (jdk.jconsole) https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/java/org... ensureContrast logic could be ported to util method and dependency on JDK method removed http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7217) Adapt servlet-security example to use Elytron

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-7217?page=com.atlassian.jira.plugin.... ] Ingo Weiss moved JBEAP-6201 to WFLY-7217: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7217 (was: JBEAP-6201) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Documentation (was: Quickstarts) > Adapt servlet-security example to use Elytron > --------------------------------------------- > > Key: WFLY-7217 > URL: https://issues.jboss.org/browse/WFLY-7217 > Project: WildFly > Issue Type: Bug > Components: Documentation > Reporter: Ingo Weiss > Assignee: Sande Gilda > Priority: Minor > Original Estimate: 2 hours > Remaining Estimate: 2 hours > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7194) Simplify creation of trust/key-manager in elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7194?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7194: ---------------------------------- *Part 3* was already done as part of other PR. *Part 4* - password is required by KeyManager, on the other side it will be deprecated and replaced "as to be supplied by the vault". For now I can set it required, can be made optional when the vault alternative will be implemented. > Simplify creation of trust/key-manager in elytron > ------------------------------------------------- > > Key: WFLY-7194 > URL: https://issues.jboss.org/browse/WFLY-7194 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > > If I want to setup TLS [1], I have to create key manager with CLI command > {code} > /subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509") > {code} > 1. It seems to me {{algorithm}} can be optional. If not set {{TrustManagerFactory.getDefaultAlgorithm()}} can be used. > 2. Also, please, enhance xsd/model documentation with clear statement that this {{password}} attribute is in fact "key password" . Or probably better rename attribute from {{password}} to {{key-password}} to make it absolutely clear to everyone. > 3. {{key-store}} attribute is declared optional in xsd . In model it is properly declared as required. Please change XSD to express it is required. > {code} > <xs:attribute name="key-store" type="xs:string" use="optional"> > <xs:annotation> > <xs:documentation> > Reference to the KeyStore to use with the KeyManager. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > 4.{{password}} attribute is optional, probably should be required > {code} > "password" => { > "type" => STRING, > "description" => "The password to use when initialising the underlying KeyManagerFactory.", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "deprecated" => { > "since" => "1.0.0", > "reason" => "Will be updated to use proper CredentialStore references." > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7216) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final

by Lin Gao (JIRA)

Lin Gao created WFLY-7216: ----------------------------- Summary: Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final Key: WFLY-7216 URL: https://issues.jboss.org/browse/WFLY-7216 Project: WildFly Issue Type: Bug Components: JCA Affects Versions: 10.1.0.Final Reporter: Lin Gao Assignee: Lin Gao My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section. The stacktrace points to here: * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb... * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a... h3. The work-around h3. Wildfly 10.1.0.Final Datasource configuration via CLI {code} # No parameter to set a connection property value. {code} h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml) Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}} {code:xml} <subsystem xmlns="urn:jboss:domain:datasources:4.0"> <datasources> <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS"> <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url> <connection-property name="databaseName">myapp</connection-property> <driver>postgres</driver> <security> <user-name>myapp</user-name> <password>myapp</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> </validation> </datasource> <drivers> <driver name="postgres" module="org.postgres"> <driver-class>org.postgresql.Driver</driver-class> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class> </driver> </drivers> </datasources> </subsystem> {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ] Marek Kopecký commented on WFLY-7210: ------------------------------------- Upgrade of show-resources operation is covered by WFLY-7024. I recommend to close this jira as duplicite of WFLY-7024. > Expose JAX-RS resources as children of the subsystem > ---------------------------------------------------- > > Key: WFLY-7210 > URL: https://issues.jboss.org/browse/WFLY-7210 > Project: WildFly > Issue Type: Feature Request > Components: REST > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Stuart Douglas > Attachments: hal-jaxrs.png > > > Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment: > [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean) > This makes it specially easy to navigate trough the web console (attached screenshot). > To read JAX-RS resources, the command would be: > [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources() > I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1680) RDMA based transport

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1680?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1680: -------------------------------- Look into accelio [1] / JXIO [2] [1] www.github.com/accelio [2] https://github.com/accelio/JXIO > RDMA based transport > -------------------- > > Key: JGRP-1680 > URL: https://issues.jboss.org/browse/JGRP-1680 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.1 > > > Investigate whether an RDMA based transport makes sense. > Advantages: > * Speed, low latency (TCP/IP is bypassed entirely) > * Low CPU usage > Disadvantages: > * JNI/C code > ** Such a transport implementation would have to live outside of the JGroups repo > ** Maintainability nightmare: the C code would also have to be ported to various OSes > *** Investigate Java based libs (IBM's jVerbs) and C based libs (Apache Portable Runtime?) > * High memory use, growing with cluster size: similarly to TCP, a 'group multicast' would involve N-1 sends. RDMA requires a Queue Pair (QP) for each destination. Each QP requires pinned memory (receive and send buffer), so each node would have to reserve (pin) N-1 memory buffers [1] > ** OTOH, we may not use many group multicasts, e.g. with Infinispan's partial replication (DIST mode) > * High cost of RDMA adapters, NICs and wiring: only a very small fraction of users would run such a transport. > [1] http://www.hpcwire.com/hpcwire/2006-08-18/a_critique_of_rdma-1.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct

by Dietrich Schmidt (JIRA)

[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ] Dietrich Schmidt commented on WFLY-7101: ---------------------------------------- I'd be happy to get feedback: is this a bug or not? > Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct > -------------------------------------------------------------- > > Key: WFLY-7101 > URL: https://issues.jboss.org/browse/WFLY-7101 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Environment: Wildfly 10.1.0 running under Windows 10 with Java 1.8.0_91 > Reporter: Dietrich Schmidt > Assignee: Jason Greene > Attachments: Verklemmung.zip > > > Wildfly 8.2.0 and 10.0.0 work fine with a Singleton Bean, which has a @Postconstruct method and in this method several threads are created with the ManagedExecutorService. These threads call a method in another Singleton EJB, which has been injected. > This call is blocked in Wildfly 10.1.0 until the Prostconstruct thread has ended. > I assume that the behaviour of Wildfly 8.2.0 + 10.0.0 is correct and the behaviour of Wildfly 10.1.0 is a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7215) Reintroduce JNDI over HTTP/HTTPS capability

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7215: ------------------------------------ Summary: Reintroduce JNDI over HTTP/HTTPS capability Key: WFLY-7215 URL: https://issues.jboss.org/browse/WFLY-7215 Project: WildFly Issue Type: Feature Request Reporter: Stuart Douglas Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1331) Use connection-url to get database connection when connection properties for datasource-class is empty

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1331?page=com.atlassian.jira.plugin... ] Lin Gao commented on JBJCA-1331: -------------------------------- PR sent at: https://github.com/ironjacamar/ironjacamar/pull/575 > Use connection-url to get database connection when connection properties for datasource-class is empty > ------------------------------------------------------------------------------------------------------ > > Key: JBJCA-1331 > URL: https://issues.jboss.org/browse/JBJCA-1331 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Affects Versions: WildFly/IronJacamar 1.3.4.Final > Reporter: Lin Gao > Assignee: Lin Gao > > Fixes of JBJCA-1312 will fail the old configuration where the connection-url is used. > In the compatibility point of view, we should try to use {{connection-url}} & {{driver-class}} to get the database connection if the connection properties are empty && datasource-class != null. A warning message should be printed to encourage users to use DataSource for database connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1331) Use connection-url to get database connection when connection properties for datasource-class is empty

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1331?page=com.atlassian.jira.plugin... ] Lin Gao updated JBJCA-1331: --------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/575 > Use connection-url to get database connection when connection properties for datasource-class is empty > ------------------------------------------------------------------------------------------------------ > > Key: JBJCA-1331 > URL: https://issues.jboss.org/browse/JBJCA-1331 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Affects Versions: WildFly/IronJacamar 1.3.4.Final > Reporter: Lin Gao > Assignee: Lin Gao > > Fixes of JBJCA-1312 will fail the old configuration where the connection-url is used. > In the compatibility point of view, we should try to use {{connection-url}} & {{driver-class}} to get the database connection if the connection properties are empty && datasource-class != null. A warning message should be printed to encourage users to use DataSource for database connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7213) IllegalStateException to run test-connection-in-pool() for datasource with same jndi-name as previous failed datasource

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7213?page=com.atlassian.jira.plugin.... ] Lin Gao deleted WFLY-7213: -------------------------- > IllegalStateException to run test-connection-in-pool() for datasource with same jndi-name as previous failed datasource > ----------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7213 > URL: https://issues.jboss.org/browse/WFLY-7213 > Project: WildFly > Issue Type: Bug > Reporter: Lin Gao > Assignee: Jesper Pedersen > > If a DataSource was failed to be added, like adding a DataSource using {{datasource-class}} without specifying any {{connection-properties}}: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or adding a DataSource using {{driver-class}} without specifying {{connection-url}}: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > It can be corrected afterwards by specifying correct information with same {{jndi-name}}, like: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:xxx") > {code} > after the DataSource created, the {{test-connection-in-pool()}} operation will fail with {{IllegalStateException}} > {code:} > /subsystem=datasources/data-source=XXX:test-connection-in-pool() > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7214) Warning of IllegalStateException on test-connection-pool for DataSources added after previous failure addition

by Lin Gao (JIRA)

Lin Gao created WFLY-7214: ----------------------------- Summary: Warning of IllegalStateException on test-connection-pool for DataSources added after previous failure addition Key: WFLY-7214 URL: https://issues.jboss.org/browse/WFLY-7214 Project: WildFly Issue Type: Bug Components: JCA Reporter: Lin Gao Assignee: Jesper Pedersen When a data-source was failed to be added either because of missing connection-properties: {code:} /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) {code} or missing of connection-url: {code:} /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) {code} , it can be added by correcting the information, like: {code:} [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") {"outcome" => "success"} {code} But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7213) IllegalStateException to run test-connection-in-pool() for datasource with same jndi-name as previous failed datasource

by Lin Gao (JIRA)

Lin Gao created WFLY-7213: ----------------------------- Summary: IllegalStateException to run test-connection-in-pool() for datasource with same jndi-name as previous failed datasource Key: WFLY-7213 URL: https://issues.jboss.org/browse/WFLY-7213 Project: WildFly Issue Type: Bug Components: JCA Reporter: Lin Gao Assignee: Jesper Pedersen If a DataSource was failed to be added, like adding a DataSource using {{datasource-class}} without specifying any {{connection-properties}}: {code:} /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) {code} or adding a DataSource using {{driver-class}} without specifying {{connection-url}}: {code:} /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) {code} It can be corrected afterwards by specifying correct information with same {{jndi-name}}, like: {code:} /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:xxx") {code} after the DataSource created, the {{test-connection-in-pool()}} operation will fail with {{IllegalStateException}} {code:} /subsystem=datasources/data-source=XXX:test-connection-in-pool() {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7212. ---------------------------------- Resolution: Rejected You need to set the transaction timeout with UserTranaction.setTransactionTimeout > Cannot use BMT in @Schedule service > ----------------------------------- > > Key: WFLY-7212 > URL: https://issues.jboss.org/browse/WFLY-7212 > Project: WildFly > Issue Type: Feature Request > Components: EE, EJB, Transactions > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5. > Reporter: Karl Nicholas > Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction > > When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes. > Here is a simple piece of code that doesn't work: > {code:java} > @EJB private TestFiveMinuteBatch testFiveMinuteBatch; > @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day > public void updateTest() { > testFiveMinuteBatch.test(); > } > @Stateless > @TransactionManagement(TransactionManagementType.BEAN) > public class TestFiveMinuteBatch { > @Resource private UserTransaction tx; > public void test() { > for ( int i=0; i < 6; ++i ) { > System.out.println("Minute: " + i); > try { > Thread.sleep(60000); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > } > } > {code} > After 5 minutes I get this warning: > {noformat} > 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN > 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e > 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5 > {noformat} > After service terminates I get this error: > {noformat} > 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e > 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) > at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) > at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64) > at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53) > at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215) > at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497) > 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) > Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) > ... 38 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned WFLY-7212: ----------------------------------- Assignee: (was: Tom Jenkinson) > Cannot use BMT in @Schedule service > ----------------------------------- > > Key: WFLY-7212 > URL: https://issues.jboss.org/browse/WFLY-7212 > Project: WildFly > Issue Type: Feature Request > Components: EE, EJB, Transactions > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5. > Reporter: Karl Nicholas > Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction > > When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes. > Here is a simple piece of code that doesn't work: > {code:java} > @EJB private TestFiveMinuteBatch testFiveMinuteBatch; > @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day > public void updateTest() { > testFiveMinuteBatch.test(); > } > @Stateless > @TransactionManagement(TransactionManagementType.BEAN) > public class TestFiveMinuteBatch { > @Resource private UserTransaction tx; > public void test() { > for ( int i=0; i < 6; ++i ) { > System.out.println("Minute: " + i); > try { > Thread.sleep(60000); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > } > } > {code} > After 5 minutes I get this warning: > {noformat} > 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN > 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e > 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5 > {noformat} > After service terminates I get this error: > {noformat} > 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e > 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) > at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) > at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64) > at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53) > at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215) > at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497) > 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) > Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) > ... 38 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service

by Karl Nicholas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ] Karl Nicholas updated WFLY-7212: -------------------------------- Description: When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes. Here is a simple piece of code that doesn't work: {code:java} @EJB private TestFiveMinuteBatch testFiveMinuteBatch; @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day public void updateTest() { testFiveMinuteBatch.test(); } @Stateless @TransactionManagement(TransactionManagementType.BEAN) public class TestFiveMinuteBatch { @Resource private UserTransaction tx; public void test() { for ( int i=0; i < 6; ++i ) { System.out.println("Minute: " + i); try { Thread.sleep(60000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } } {code} After 5 minutes I get this warning: {noformat} 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5 {noformat} After service terminates I get this error: {noformat} 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53) at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157) at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215) at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497) 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) Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) ... 38 more {noformat} was: When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes. Here is a simple piece of code that doesn't work: {code:java} @EJB private TestFiveMinuteBatch testFiveMinuteBatch; @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day public void updateTest() { testFiveMinuteBatch.test(); } @Stateless @TransactionManagement(TransactionManagementType.BEAN) public class TestFiveMinuteBatch { @Resource private UserTransaction tx; public void test() { for ( int i=0; i < 6; ++i ) { System.out.println("Minute: " + i); try { Thread.sleep(60000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } } {code} After 5 minutes I get this warning: {noformat} 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5 {noformat} After service terminates I get this error: {noformat} 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53) at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157) at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215) at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497) 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) Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) ... 38 more {noformat} Labels: arjuna ejb scheduled scheduled_tasks transaction (was: ejb scheduled scheduled_tasks transaction) > Cannot use BMT in @Schedule service > ----------------------------------- > > Key: WFLY-7212 > URL: https://issues.jboss.org/browse/WFLY-7212 > Project: WildFly > Issue Type: Feature Request > Components: EE, EJB, Transactions > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5. > Reporter: Karl Nicholas > Assignee: Tom Jenkinson > Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction > > When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes. > Here is a simple piece of code that doesn't work: > {code:java} > @EJB private TestFiveMinuteBatch testFiveMinuteBatch; > @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day > public void updateTest() { > testFiveMinuteBatch.test(); > } > @Stateless > @TransactionManagement(TransactionManagementType.BEAN) > public class TestFiveMinuteBatch { > @Resource private UserTransaction tx; > public void test() { > for ( int i=0; i < 6; ++i ) { > System.out.println("Minute: " + i); > try { > Thread.sleep(60000); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > } > } > {code} > After 5 minutes I get this warning: > {noformat} > 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN > 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e > 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5 > {noformat} > After service terminates I get this error: > {noformat} > 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e > 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) > at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) > at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64) > at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53) > at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215) > at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497) > 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) > Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) > ... 38 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service

by Karl Nicholas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ] Karl Nicholas updated WFLY-7212: -------------------------------- Description: When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes. Here is a simple piece of code that doesn't work: {code:java} @EJB private TestFiveMinuteBatch testFiveMinuteBatch; @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day public void updateTest() { testFiveMinuteBatch.test(); } @Stateless @TransactionManagement(TransactionManagementType.BEAN) public class TestFiveMinuteBatch { @Resource private UserTransaction tx; public void test() { for ( int i=0; i < 6; ++i ) { System.out.println("Minute: " + i); try { Thread.sleep(60000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } } {code} After 5 minutes I get this warning: {noformat} 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5 {noformat} After service terminates I get this error: {noformat} 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53) at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157) at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215) at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497) 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) Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) ... 38 more {noformat} was: When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes. Here is a simple piece of code that doesn't work: @EJB private TestFiveMinuteBatch testFiveMinuteBatch; @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day public void updateTest() { testFiveMinuteBatch.test(); } @Stateless @TransactionManagement(TransactionManagementType.BEAN) public class TestFiveMinuteBatch { @Resource private UserTransaction tx; public void test() { for ( int i=0; i < 6; ++i ) { System.out.println("Minute: " + i); try { Thread.sleep(60000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } } After 5 minutes I get this warning: > 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN > 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper > Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5 After service terminates I get this error: > 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53) at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157) at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215) at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497) 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) Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) ... 38 more > Cannot use BMT in @Schedule service > ----------------------------------- > > Key: WFLY-7212 > URL: https://issues.jboss.org/browse/WFLY-7212 > Project: WildFly > Issue Type: Feature Request > Components: EE, EJB, Transactions > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5. > Reporter: Karl Nicholas > Assignee: Tom Jenkinson > Labels: ejb, scheduled, scheduled_tasks, transaction > > When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes. > Here is a simple piece of code that doesn't work: > {code:java} > @EJB private TestFiveMinuteBatch testFiveMinuteBatch; > @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day > public void updateTest() { > testFiveMinuteBatch.test(); > } > @Stateless > @TransactionManagement(TransactionManagementType.BEAN) > public class TestFiveMinuteBatch { > @Resource private UserTransaction tx; > public void test() { > for ( int i=0; i < 6; ++i ) { > System.out.println("Minute: " + i); > try { > Thread.sleep(60000); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > } > } > {code} > After 5 minutes I get this warning: > {noformat} > 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state > RUN > 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e > 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5 > {noformat} > After service terminates I get this error: > {noformat} > 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e > 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) > at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) > at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64) > at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53) > at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215) > at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497) > 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) > Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) > ... 38 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service

by Karl Nicholas (JIRA)

Karl Nicholas created WFLY-7212: ----------------------------------- Summary: Cannot use BMT in @Schedule service Key: WFLY-7212 URL: https://issues.jboss.org/browse/WFLY-7212 Project: WildFly Issue Type: Feature Request Components: EE, EJB, Transactions Affects Versions: 10.1.0.Final, 10.0.0.Final Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5. Reporter: Karl Nicholas Assignee: Tom Jenkinson When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes. Here is a simple piece of code that doesn't work: @EJB private TestFiveMinuteBatch testFiveMinuteBatch; @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day public void updateTest() { testFiveMinuteBatch.test(); } @Stateless @TransactionManagement(TransactionManagementType.BEAN) public class TestFiveMinuteBatch { @Resource private UserTransaction tx; public void test() { for ( int i=0; i < 6; ++i ) { System.out.println("Minute: " + i); try { Thread.sleep(60000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } } After 5 minutes I get this warning: > 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN > 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper > Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5 After service terminates I get this error: > 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117) at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64) at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53) at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157) at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215) at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497) 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) Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) ... 38 more -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1822) Address thread safety of CredentialReference

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1822: ---------------------------------------- Summary: Address thread safety of CredentialReference Key: WFCORE-1822 URL: https://issues.jboss.org/browse/WFCORE-1822 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Peter Skopek Fix For: 3.0.0.Alpha9 Following on from the comments in this pull requests some minor follow up is required regarding thread safety of CredentialReference: - https://github.com/wildfly/wildfly-core/pull/1816 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7211) IndexOutOfBoundsException following cache topology change

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7211: ---------------------------------- Summary: IndexOutOfBoundsException following cache topology change Key: WFLY-7211 URL: https://issues.jboss.org/browse/WFLY-7211 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR5 Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Minor Seen only once so far in failover tests - HA Singleton deployment scenarios. Is probably closely related to JBEAP-2254 as it occured during the events described there, namely: - redeploy will fail - This node will no longer operate as the singleton provider - *IndexOutOfBoundsException* appears, see the stacktrace below - the node is re-elected as the singleton provider and the deployment starts successfully Stacktrace: {code} [JBossINF] [0m[31m05:51:00,920 ERROR [org.jgroups.protocols.pbcast.GMS] (Incoming-14,ee,perf19) JGRP000027: failed passing message up: java.lang.RuntimeException: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.IndexOutOfBoundsException] while invoking method [public void org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator.calculateRank(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent)] on listener instance: org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator@3118031c [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:689) [JBossINF] at org.jgroups.JChannel.up(JChannel.java:738) [JBossINF] at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:123) [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:374) [JBossINF] at org.jgroups.protocols.FORK.up(FORK.java:118) [JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:394) [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:394) [JBossINF] at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:735) [JBossINF] at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:244) [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:925) [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:412) [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) [JBossINF] at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474) [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:982) [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912) [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846) [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618) [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) [JBossINF] at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200) [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) [JBossINF] at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:295) [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1577) [JBossINF] at org.jgroups.protocols.TP$3.run(TP.java:1511) [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [JBossINF] at java.lang.Thread.run(Thread.java:745) [JBossINF] Caused by: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.IndexOutOfBoundsException] while invoking method [public void org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator.calculateRank(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent)] on listener instance: org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator@3118031c [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:291) [JBossINF] at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:21) [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309) [JBossINF] at org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl.notifyViewChange(CacheManagerNotifierImpl.java:88) [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$NotifyViewChange.emitNotification(JGroupsTransport.java:774) [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.viewAccepted(JGroupsTransport.java:850) [JBossINF] at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:605) [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:686) [JBossINF] ... 27 more [JBossINF] Caused by: java.lang.IndexOutOfBoundsException: Index: 0 [JBossINF] at org.infinispan.commons.util.InfinispanCollections$EmptyList.get(InfinispanCollections.java:115) [JBossINF] at org.infinispan.container.versioning.NumericVersionGenerator.findAddressRank(NumericVersionGenerator.java:115) [JBossINF] at org.infinispan.container.versioning.NumericVersionGenerator.calculateRank(NumericVersionGenerator.java:101) [JBossINF] at org.infinispan.container.versioning.NumericVersionGenerator$RankCalculator.calculateRank(NumericVersionGenerator.java:126) [JBossINF] at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [JBossINF] at java.lang.reflect.Method.invoke(Method.java:497) [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286) [JBossINF] ... 34 more {code} Link: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-singl... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem

by Guillermo González de Agüero (JIRA)

Guillermo González de Agüero created WFLY-7210: -------------------------------------------------- Summary: Expose JAX-RS resources as children of the subsystem Key: WFLY-7210 URL: https://issues.jboss.org/browse/WFLY-7210 Project: WildFly Issue Type: Feature Request Components: REST Affects Versions: 10.1.0.Final Reporter: Guillermo González de Agüero Assignee: Stuart Douglas Attachments: hal-jaxrs.png Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment: [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean) This makes it specially easy to navigate trough the web console (attached screenshot). To read JAX-RS resources, the command would be: [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources() I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7133) Automatically define resource adapter for deployed RARs

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/WFLY-7133?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero commented on WFLY-7133: ---------------------------------------------------- [~jthoennes] Yes, but you have to manually define it in the subsystem in order to see it. And for that you have to manually configure it. And if it comes with an ironjacamar.xml, it doesn't make sense to manually reconfigure it, potentially with different and wrong settings. But I guess what I requested is not technically viable at all. If the adapter would be created at deployment time, it would also need to be deleted when undeploying. Doesn't seem very robust. I created the ticket before checking how the JDBC drivers par work. After that I realized that the new operation I mention could do the trick. I've created WFLY-7209 for that. > Automatically define resource adapter for deployed RARs > ------------------------------------------------------- > > Key: WFLY-7133 > URL: https://issues.jboss.org/browse/WFLY-7133 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Jesper Pedersen > > Deploying a RAR file enables the resource adapter for the server, but in order to configure it, you must manually add it to the Resource Adapters subsystem. This is error prone (you can put in invalid "archive name" for the resource adapter and it doesn't complaint) and little user friendly. > From a user perspective and from what can be read from the documentation (https://docs.jboss.org/author/display/WFLY10/Resource+adapters), it seems like the resource adapter is not enabled unless you explicitly define it. > It would be very simpler if RA deployments would be detected and registered as it's done for deployed JDBC drivers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7209) Operation to list installed Resource Adapters

by Guillermo González de Agüero (JIRA)

Guillermo González de Agüero created WFLY-7209: -------------------------------------------------- Summary: Operation to list installed Resource Adapters Key: WFLY-7209 URL: https://issues.jboss.org/browse/WFLY-7209 Project: WildFly Issue Type: Feature Request Components: JCA Reporter: Guillermo González de Agüero Assignee: Jesper Pedersen Fix For: 10.1.0.Final Currently there's no way to list all the installed Resource Adapters. Only configured resource adapters can be queried. However, they are automatically enabled at deployment time. I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them. The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list() -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4763) Include org.jboss.invocation in group ids that are synced to Maven central

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-4763?page=com.atlassian.jira.plugin.... ] jaikiran pai resolved WFLY-4763. -------------------------------- Resolution: Done I now see this artifact in Maven central https://repo1.maven.org/maven2/org/jboss/invocation/jboss-invocation/, marking this as resolved. > Include org.jboss.invocation in group ids that are synced to Maven central > -------------------------------------------------------------------------- > > Key: WFLY-4763 > URL: https://issues.jboss.org/browse/WFLY-4763 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Reporter: jaikiran pai > Assignee: Paul Gier > > The jboss-invocation module under the org.jboss.invocation group (https://github.com/jbossas/jboss-invocation/ - project home) isn't available in Maven central unlike most of the other org.jboss projects. > jboss-invocation is part of WildFly dependencies. Please include the org.jboss.invocation group id in the groups that are synced to Maven central. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7120) NPE in SessionManagerStatsHandler

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7120?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-7120: -------------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) Tomaz, could you look into this and make sure JBEAP-6026 gets in the right state or a new one is opened if there's further change? > NPE in SessionManagerStatsHandler > --------------------------------- > > Key: WFLY-7120 > URL: https://issues.jboss.org/browse/WFLY-7120 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > [~matlach] reports an NPE when SessionManagerStatsHandler tries to use the ServiceController for a no-longer present deployment. See https://github.com/wildfly/wildfly/pull/9189 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7202) generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7202?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7202: ----------------------------------------------- Tom Ross <tom.ross(a)redhat.com> changed the Status of [bug 1378723|https://bugzilla.redhat.com/show_bug.cgi?id=1378723] from NEW to ASSIGNED > generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type > ------------------------------------------------------------------------------------------------ > > Key: WFLY-7202 > URL: https://issues.jboss.org/browse/WFLY-7202 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: Tom Ross > Assignee: Tom Ross > > The code snippet shows that the method returns wrong type. > {noformat} > public String getSessionDefaultType() { > if (type == JmsConnectionFactory.AGNOSTIC) > return "agnostic"; > else if (type == JmsConnectionFactory.QUEUE) > return TOPIC_TYPE; > else > return QUEUE_TYPE; > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1821) Failures in ModuleOpsCompletionTestCase

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1821: ---------------------------------------- Summary: Failures in ModuleOpsCompletionTestCase Key: WFCORE-1821 URL: https://issues.jboss.org/browse/WFCORE-1821 Project: WildFly Core Issue Type: Bug Components: Test Suite Reporter: Brian Stansberry Assignee: ehsavoie Hugonnet Failed tests: ModuleOpsCompletionTestCase.testModuleAddCompletionSuggestions:56->testSuggestion:146->testSuggestion:153 expected:<[org, ibm, io, javax, org, sun]> but was:<[ibm, io, javax, org, sun]> There's already a PR that's probably meant to fix this but it isn't passing CI. I'm going to @Ignore this test. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1820) Use MRR-driven capability registration for the management interface capabilities

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1820: ---------------------------------------- Summary: Use MRR-driven capability registration for the management interface capabilities Key: WFCORE-1820 URL: https://issues.jboss.org/browse/WFCORE-1820 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Currently the registration of runtime capabilities for the management interfaces is being done in the add handlers instead of by the MRR. This is fragile as it's non-standard and makes it more difficult to add other capabilities, since registering via the handler turns off registration via the MRR. WFCORE-1819 is needed to fix this. This is arguably a bug but I'll call it an enhancement for now. It's just making the code better. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1819) Allow collections kept by SimpleResourceDefinition.Parameters to be appended

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1819: ---------------------------------------- Summary: Allow collections kept by SimpleResourceDefinition.Parameters to be appended Key: WFCORE-1819 URL: https://issues.jboss.org/browse/WFCORE-1819 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry The Parameters object is meant to be built with a builder and then passed into SimpleResourceDefinition constructors. It is useful for scenarios where RD's are based on subclassing to let the superclass *add* items to the passed in set of access constraints, capabilities and incorporating capabilities instead of forcing the subclass constructor itself to manually read existing values, create new collections with added values, and then re-set the overall collection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-642) Investigate Elytron and gssproxy interoperability

by Bilge Ozpeynirci (JIRA)

Bilge Ozpeynirci created ELY-642: ------------------------------------ Summary: Investigate Elytron and gssproxy interoperability Key: ELY-642 URL: https://issues.jboss.org/browse/ELY-642 Project: WildFly Elytron Issue Type: Task Components: SASL Reporter: Bilge Ozpeynirci Assignee: Peter Skopek Fix For: 2.0.0.Alpha1 Investigate Elytron and gssproxy interoperability. https://fedorahosted.org/gss-proxy/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1817) upgrade Xerces to 2.11.0.SP5

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1817?page=com.atlassian.jira.plugi... ] Scott Marlow closed WFCORE-1817. -------------------------------- > upgrade Xerces to 2.11.0.SP5 > ---------------------------- > > Key: WFCORE-1817 > URL: https://issues.jboss.org/browse/WFCORE-1817 > Project: WildFly Core > Issue Type: Task > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 3.0.0.Alpha9, 2.2.1.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1817) upgrade Xerces to 2.11.0.SP5

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1817?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1817: ---------------------------------------- Assignee: Scott Marlow Resolution: Done > upgrade Xerces to 2.11.0.SP5 > ---------------------------- > > Key: WFCORE-1817 > URL: https://issues.jboss.org/browse/WFCORE-1817 > Project: WildFly Core > Issue Type: Task > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 3.0.0.Alpha9, 2.2.1.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7133) Automatically define resource adapter for deployed RARs

by Thönnes Thönnes (JIRA)

[ https://issues.jboss.org/browse/WFLY-7133?page=com.atlassian.jira.plugin.... ] Thönnes Thönnes commented on WFLY-7133: --------------------------------------- [~ggam], in the documentation I also read that automatic configuration can be done: {quote} Automatic activation of resource adapter archives A resource adapter archive can be automatically activated with a configuration by including an META-INF/ironjacamar.xml in the archive. The schema can be found at http://docs.jboss.org/ironjacamar/schema/ironjacamar_1_0.xsd {quote} This works fine for me. But with regard to a list of available resource adapter to get an overview and to fine tune configuration -- I completely agree with you. But then the ticket title is misleading. > Automatically define resource adapter for deployed RARs > ------------------------------------------------------- > > Key: WFLY-7133 > URL: https://issues.jboss.org/browse/WFLY-7133 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Jesper Pedersen > > Deploying a RAR file enables the resource adapter for the server, but in order to configure it, you must manually add it to the Resource Adapters subsystem. This is error prone (you can put in invalid "archive name" for the resource adapter and it doesn't complaint) and little user friendly. > From a user perspective and from what can be read from the documentation (https://docs.jboss.org/author/display/WFLY10/Resource+adapters), it seems like the resource adapter is not enabled unless you explicitly define it. > It would be very simpler if RA deployments would be detected and registered as it's done for deployed JDBC drivers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFCORE-644: ----------------------------------------- [~aloubyansky] FYI I have taken this one as the Elytron changes make Elytron client configuration usable within the CLI and there we can perform advanced SSL configuration to cover this kind of scenario. > jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores > ----------------------------------------------------------------------------------- > > Key: WFCORE-644 > URL: https://issues.jboss.org/browse/WFCORE-644 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Derek Horton > Assignee: Darran Lofthouse > > The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file. > This is problematic when the JVM is running in FIPS mode. > The cli throws the following exception on startup: > $ ./bin/jboss-cli.sh > org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541) > at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126) > at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89) > at javax.net.ssl.SSLContext.init(SSLContext.java:283) > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537) > ... 11 more > It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file: > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11" > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFCORE-644: --------------------------------------- Assignee: Darran Lofthouse (was: Alexey Loubyansky) > jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores > ----------------------------------------------------------------------------------- > > Key: WFCORE-644 > URL: https://issues.jboss.org/browse/WFCORE-644 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Derek Horton > Assignee: Darran Lofthouse > > The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file. > This is problematic when the JVM is running in FIPS mode. > The cli throws the following exception on startup: > $ ./bin/jboss-cli.sh > org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541) > at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126) > at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89) > at javax.net.ssl.SSLContext.init(SSLContext.java:283) > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537) > ... 11 more > It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file: > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11" > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1817) upgrade Xerces to 2.11.0.SP5

by Scott Marlow (JIRA)

Scott Marlow created WFCORE-1817: ------------------------------------ Summary: upgrade Xerces to 2.11.0.SP5 Key: WFCORE-1817 URL: https://issues.jboss.org/browse/WFCORE-1817 Project: WildFly Core Issue Type: Task Reporter: Scott Marlow Fix For: 3.0.0.Alpha9, 2.2.1.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1774?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1774: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1825 > Use core-service=capability-registry to provide tab completion suggestions for model reference attributes > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1774 > URL: https://issues.jboss.org/browse/WFCORE-1774 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Brian Stansberry > Assignee: Jean-Francois Denise > > A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion. > [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though: > 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding". > 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added. > That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability: > {code} > [standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding) > { > "outcome" => "success", > "result" => ["/socket-binding-group=*/socket-binding=*"] > } > {code} > That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=* > 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion. > HAL may be doing something slightly different from what I describe; they have concrete experience. > It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself. > [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1619) Bad artifact resolution in wildfly-logging module

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1619?page=com.atlassian.jira.plugi... ] Tomaz Cerar closed WFCORE-1619. ------------------------------- Fix Version/s: 3.0.0.Alpha8 Resolution: Out of Date I cannot reproduce this. If you can reproduce it with recent code, please reopen it. > Bad artifact resolution in wildfly-logging module > ------------------------------------------------- > > Key: WFCORE-1619 > URL: https://issues.jboss.org/browse/WFCORE-1619 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Test Suite > Reporter: Carlo de Wolf > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 3.0.0.Alpha8 > > > The test doesn't use project artifact resolution, but global artifact resolution. While the project hasn't been published yet. > {noformat} > Tests run: 14, Failures: 0, Errors: 6, Skipped: 3, Time elapsed: 21.024 sec <<< FAILURE! - in org.jboss.as.logging.LoggingSubsystemTestCase > testTransformersEAP620(org.jboss.as.logging.LoggingSubsystemTestCase) Time elapsed: 8.508 sec <<< ERROR! > java.lang.RuntimeException: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.wildfly.core:wildfly-subsystem-test-framework:jar:2.1.6.Final-redhat-SNAPSHOT in product-repository (https://maven.repository.redhat.com/nexus/content/groups/product-techprev...) > at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39) > at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355) > at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) > at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581) > at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223) > at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294) > at org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:138) > at org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197) > at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:839) > at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:724) > at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:691) > at org.jboss.as.logging.LoggingSubsystemTestCase.testEapTransformer(LoggingSubsystemTestCase.java:281) > at org.jboss.as.logging.LoggingSubsystemTestCase.testTransformersEAP620(LoggingSubsystemTestCase.java:130) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7208) Integration with transactions during the graceful shutdown

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-7208?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated WFLY-7208: ---------------------------------- Description: During the graceful shutdown Web Services subsystem should consult XTS subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of WS-AT or WS-BA transaction and return the outcome. (was: During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome.) > Integration with transactions during the graceful shutdown > ---------------------------------------------------------- > > Key: WFLY-7208 > URL: https://issues.jboss.org/browse/WFLY-7208 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Reporter: Gytis Trikleris > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > During the graceful shutdown Web Services subsystem should consult XTS subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of WS-AT or WS-BA transaction and return the outcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7208) Integration with transactions during the graceful shutdown

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-7208?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on WFLY-7208: --------------------------------------- Relevant transactions JIRA issue hasn't reached the design phase, so there is no possible SPI interface. However, because of the issue being critical and time for release running shorter, I'm raising this issue now in case you need to do any analysis in your part. > Integration with transactions during the graceful shutdown > ---------------------------------------------------------- > > Key: WFLY-7208 > URL: https://issues.jboss.org/browse/WFLY-7208 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Reporter: Gytis Trikleris > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > During the graceful shutdown Web Services subsystem should consult XTS subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of WS-AT or WS-BA transaction and return the outcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7208) Integration with transactions during the graceful shutdown

by Gytis Trikleris (JIRA)

Gytis Trikleris created WFLY-7208: ------------------------------------- Summary: Integration with transactions during the graceful shutdown Key: WFLY-7208 URL: https://issues.jboss.org/browse/WFLY-7208 Project: WildFly Issue Type: Feature Request Components: EJB Reporter: Gytis Trikleris Priority: Critical Fix For: 11.0.0.Alpha1 During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7208) Integration with transactions during the graceful shutdown

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-7208?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated WFLY-7208: ---------------------------------- Component/s: Web Services (was: EJB) > Integration with transactions during the graceful shutdown > ---------------------------------------------------------- > > Key: WFLY-7208 > URL: https://issues.jboss.org/browse/WFLY-7208 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Reporter: Gytis Trikleris > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7207) Integration with transactions during the graceful shutdown

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-7207?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on WFLY-7207: --------------------------------------- Relevant transactions JIRA issue hasn't reached the design phase, so there is no possible SPI interface. However, because of the issue being critical and time for release running shorter, I'm raising this issue now in case you need to do any analysis in your part. > Integration with transactions during the graceful shutdown > ---------------------------------------------------------- > > Key: WFLY-7207 > URL: https://issues.jboss.org/browse/WFLY-7207 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Gytis Trikleris > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7207) Integration with transactions during the graceful shutdown

by Gytis Trikleris (JIRA)

Gytis Trikleris created WFLY-7207: ------------------------------------- Summary: Integration with transactions during the graceful shutdown Key: WFLY-7207 URL: https://issues.jboss.org/browse/WFLY-7207 Project: WildFly Issue Type: Feature Request Components: EJB Reporter: Gytis Trikleris Priority: Critical Fix For: 11.0.0.Alpha1 During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1018) PeriodicSizeRotatingFileHandler's are always replaced during boot

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1018?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1018: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1266360|https://bugzilla.redhat.com/show_bug.cgi?id=1266360] from MODIFIED to ON_QA > PeriodicSizeRotatingFileHandler's are always replaced during boot > ----------------------------------------------------------------- > > Key: WFCORE-1018 > URL: https://issues.jboss.org/browse/WFCORE-1018 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7206) Graceful Shutdown and Quiescing for Transactions

by Gytis Trikleris (JIRA)

Gytis Trikleris created WFLY-7206: ------------------------------------- Summary: Graceful Shutdown and Quiescing for Transactions Key: WFLY-7206 URL: https://issues.jboss.org/browse/WFLY-7206 Project: WildFly Issue Type: Feature Request Components: Server, Transactions, Web Console, XTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Critical Fix For: 11.0.0.Alpha1 * During the quiesce period - the server component will not accept new requests. * Components of the server will support controlled shutdown or quiescence - ie. In-flight transactions and requests will be serviced before the shutdown. This also implies eing able to control all request paths - HTTP (via mod_cluster), JMS and RMI (via smart proxies). * The Quiesce operation will accept a timeout which will indicate the maximum period that a shutdown will wait for in-flight requests / transactions to complete. After the timeout expires the server component will shutdown immediately. * It applies to servers that are started with all supported server profiles (i.e. default, default-ha, full and full-ha) in both standalone and domain modes. * In a clustered environment if a node in cluster is on graceful shutdown, the other node(s) in the cluster should not log warnings, but infos (or debug or nothing) because this is a normal situation (Ref: PRODMGT-815) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7205) Enhance coverage of transaction timeout test cases

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created WFLY-7205: ------------------------------------- Summary: Enhance coverage of transaction timeout test cases Key: WFLY-7205 URL: https://issues.jboss.org/browse/WFLY-7205 Project: WildFly Issue Type: Enhancement Components: Test Suite Affects Versions: 10.1.0.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor There is not much tests which checks behaviour of CMT/BMT EJBs when transaction timeout occurs. There should be more such tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7130) PersistenceProperty specified in @PersistenceContext should be passed to the created EntityManager

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7130?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-7130. ------------------------------ > PersistenceProperty specified in @PersistenceContext should be passed to the created EntityManager > --------------------------------------------------------------------------------------------------- > > Key: WFLY-7130 > URL: https://issues.jboss.org/browse/WFLY-7130 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: JBoss AS7 7.1.1.Final, 10.1.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > > While working on the unit test for WFLY-7075, I noticed that PersistenceContext properties are not being passed correctly to the Injected EntityManager, we should fix that. > For Example: > {quote} > @PersistenceContext(type = PersistenceContextType.TRANSACTION, unitName = "mypc", properties={@PersistenceProperty(name="wildfly.jpa.allowjoinedunsync", value="true")}) > private EntityManager allowjoinedunsyncEm; > {quote} > Is passing an incorrect form of the property values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-7075. ------------------------------ > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7108?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-7108. ------------------------------ > UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7108 > URL: https://issues.jboss.org/browse/WFLY-7108 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7142) check for SynchronizationType.UNSYNCHRONIZED when processing persistence unit / context references from deployment descriptors

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7142?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-7142. ------------------------------ > check for SynchronizationType.UNSYNCHRONIZED when processing persistence unit / context references from deployment descriptors > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-7142 > URL: https://issues.jboss.org/browse/WFLY-7142 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > > See org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceContextRefs() which should check for SynchronizationType.UNSYNCHRONIZED. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1815) It's not possible to re-add extension

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1815?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-1815: ----------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) > It's not possible to re-add extension > -------------------------------------- > > Key: WFCORE-1815 > URL: https://issues.jboss.org/browse/WFCORE-1815 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha8 > Reporter: Martin Simka > Assignee: Tomaz Cerar > > {noformat} > [standalone@localhost:9990 /] /subsystem=ejb3:remove > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] reload > [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:remove > {"outcome" => "success"} > [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:add > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3'", > "rolled-back" => true > } > {noformat} > {noformat} > 13:46:48,278 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.jboss.as.ejb3")]): java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3' > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:222) > at org.jboss.as.controller.extension.ExtensionRegistry$DeploymentManagementResourceRegistration.registerSubModel(ExtensionRegistry.java:922) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerDeploymentModel(ExtensionRegistry.java:700) > at org.jboss.as.ejb3.subsystem.EJB3Extension.initialize(EJB3Extension.java:91) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > {noformat} > the error with logging subsystem, I didn't try other subsystems > reload after extension:remove helps -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1815) It's not possible to re-add extension

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1815?page=com.atlassian.jira.plugi... ] Tomaz Cerar commented on WFCORE-1815: ------------------------------------- I think it is similar problem to what we had in WFCORE-1785 > It's not possible to re-add extension > -------------------------------------- > > Key: WFCORE-1815 > URL: https://issues.jboss.org/browse/WFCORE-1815 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha8 > Reporter: Martin Simka > Assignee: Brian Stansberry > > {noformat} > [standalone@localhost:9990 /] /subsystem=ejb3:remove > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone@localhost:9990 /] reload > [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:remove > {"outcome" => "success"} > [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:add > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3'", > "rolled-back" => true > } > {noformat} > {noformat} > 13:46:48,278 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.jboss.as.ejb3")]): java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3' > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:222) > at org.jboss.as.controller.extension.ExtensionRegistry$DeploymentManagementResourceRegistration.registerSubModel(ExtensionRegistry.java:922) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerDeploymentModel(ExtensionRegistry.java:700) > at org.jboss.as.ejb3.subsystem.EJB3Extension.initialize(EJB3Extension.java:91) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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) > {noformat} > the error with logging subsystem, I didn't try other subsystems > reload after extension:remove helps -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7192) 'name' attribute missing in XSD while required by web subsystem parser

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-7192?page=com.atlassian.jira.plugin.... ] Kabir Khan resolved WFLY-7192. ------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Done > 'name' attribute missing in XSD while required by web subsystem parser > ---------------------------------------------------------------------- > > Key: WFLY-7192 > URL: https://issues.jboss.org/browse/WFLY-7192 > Project: WildFly > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > Labels: downstream_dependency > Fix For: 11.0.0.Alpha1 > > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1365939 , originaly reported by [~paramjindal] > While configuring the global valve using the following article : > https://access.redhat.com/solutions/379813 > It is mandatory that the "name" attribute of valve must match the "auth-method" that is specified in the "WEB-INF/web.xml". > So "name" attribute is mandatory to configure this valve. > but it is not mentioned in the schema of valve as shown below : > {code:xml} > <xs:element name="valve"> > <xs:complexType> > <xs:sequence> > <xs:element name="param" minOccurs="0" maxOccurs="unbounded" type="paramType" /> > </xs:sequence> > <xs:attribute name="class-name" type="xs:string" use="required" /> > <xs:attribute name="module" type="xs:string" use="required" /> > <xs:attribute name="enabled" default="true" type="xs:boolean" /> > </xs:complexType> > </xs:element> > {code} > Version-Release number of selected component (if applicable): -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-7143: ----------------------------- Git Pull Request: https://github.com/wildfly-security/elytron-subsystem/pull/230 (was: https://github.com/wildfly-security/elytron-subsystem/pull/230, https://github.com/wildfly-security/wildfly-elytron/pull/496) > Unsafe Elytron role/permission mapping > -------------------------------------- > > Key: WFLY-7143 > URL: https://issues.jboss.org/browse/WFLY-7143 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > > Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. > The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. > {code:xml} > <mappers> > <simple-permission-mapper name="login-permission-mapper"> > <permission-mapping roles="All"> > <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> > </permission-mapping> > </simple-permission-mapper> > <constant-role-mapper name="constant-roles" roles="All"/> > </mappers> > {code} > We have to make the default server configuration secure for users. > *Suggestions for improvement:* > * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles > * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7204) Unsafe Elytron role/permission mapping

by Jan Kalina (JIRA)

Jan Kalina created WFLY-7204: -------------------------------- Summary: Unsafe Elytron role/permission mapping Key: WFLY-7204 URL: https://issues.jboss.org/browse/WFLY-7204 Project: WildFly Issue Type: Bug Components: Security Reporter: Jan Kalina Assignee: Jan Kalina Priority: Blocker Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. {code:xml} <mappers> <simple-permission-mapper name="login-permission-mapper"> <permission-mapping roles="All"> <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> </permission-mapping> </simple-permission-mapper> <constant-role-mapper name="constant-roles" roles="All"/> </mappers> {code} We have to make the default server configuration secure for users. *Suggestions for improvement:* * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-641) Unsafe Elytron role/permission mapping

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-641?page=com.atlassian.jira.plugin.sy... ] Jan Kalina moved WFLY-7204 to ELY-641: -------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-641 (was: WFLY-7204) Component/s: (was: Security) > Unsafe Elytron role/permission mapping > -------------------------------------- > > Key: ELY-641 > URL: https://issues.jboss.org/browse/ELY-641 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > > Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then. > The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role. > {code:xml} > <mappers> > <simple-permission-mapper name="login-permission-mapper"> > <permission-mapping roles="All"> > <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/> > </permission-mapping> > </simple-permission-mapper> > <constant-role-mapper name="constant-roles" roles="All"/> > </mappers> > {code} > We have to make the default server configuration secure for users. > *Suggestions for improvement:* > * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles > * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-640) Elytron 1.0 branch has mixed licenses

by David Lloyd (JIRA)

David Lloyd created ELY-640: ------------------------------- Summary: Elytron 1.0 branch has mixed licenses Key: ELY-640 URL: https://issues.jboss.org/browse/ELY-640 Project: WildFly Elytron Issue Type: Bug Affects Versions: 1.0.3.Final Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.0.4.CR1 Just fix up the license headers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2101) DELIVERY_TIME: protocol to measure delivery times

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2101?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2101. ---------------------------- Resolution: Done > DELIVERY_TIME: protocol to measure delivery times > ------------------------------------------------- > > Key: JGRP-2101 > URL: https://issues.jboss.org/browse/JGRP-2101 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.12, 4.0 > > > This protocol should be placed at the top of the stack. It measure delivery times: > * Average times for single messages to get delivered. This returns when {{receive()}} returns > * Average times for message batches: the delivery time is computed as time to deliver the batch divided by batch size -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2101) DELIVERY_TIME: protocol to measure delivery times

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2101?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2101: --------------------------- Fix Version/s: 3.6.12 > DELIVERY_TIME: protocol to measure delivery times > ------------------------------------------------- > > Key: JGRP-2101 > URL: https://issues.jboss.org/browse/JGRP-2101 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.12, 4.0 > > > This protocol should be placed at the top of the stack. It measure delivery times: > * Average times for single messages to get delivered. This returns when {{receive()}} returns > * Average times for message batches: the delivery time is computed as time to deliver the batch divided by batch size -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2101) DELIVERY_TIME: protocol to measure delivery times

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2101?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2101: --------------------------- Summary: DELIVERY_TIME: protocol to measure delivery times (was: DELIVERY_STATS: protocol to measure delivery times) > DELIVERY_TIME: protocol to measure delivery times > ------------------------------------------------- > > Key: JGRP-2101 > URL: https://issues.jboss.org/browse/JGRP-2101 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > This protocol should be placed at the top of the stack. It measure delivery times: > * Average times for single messages to get delivered. This returns when {{receive()}} returns > * Average times for message batches: the delivery time is computed as time to deliver the batch divided by batch size -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2101) DELIVERY_STATS: protocol to measure delivery times

by Bela Ban (JIRA)

Bela Ban created JGRP-2101: ------------------------------ Summary: DELIVERY_STATS: protocol to measure delivery times Key: JGRP-2101 URL: https://issues.jboss.org/browse/JGRP-2101 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 4.0 This protocol should be placed at the top of the stack. It measure delivery times: * Average times for single messages to get delivered. This returns when {{receive()}} returns * Average times for message batches: the delivery time is computed as time to deliver the batch divided by batch size -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1816) It's not possible to re-add extension

by Martin Simka (JIRA)

Martin Simka created WFCORE-1816: ------------------------------------ Summary: It's not possible to re-add extension Key: WFCORE-1816 URL: https://issues.jboss.org/browse/WFCORE-1816 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha8 Reporter: Martin Simka Assignee: Brian Stansberry {noformat} [standalone@localhost:9990 /] /subsystem=ejb3:remove { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9990 /] reload [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:remove {"outcome" => "success"} [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:add { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3'", "rolled-back" => true } {noformat} {noformat} 13:46:48,278 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.jboss.as.ejb3")]): java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3' at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:222) at org.jboss.as.controller.extension.ExtensionRegistry$DeploymentManagementResourceRegistration.registerSubModel(ExtensionRegistry.java:922) at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerDeploymentModel(ExtensionRegistry.java:700) at org.jboss.as.ejb3.subsystem.EJB3Extension.initialize(EJB3Extension.java:91) at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) {noformat} the error with logging subsystem, I didn't try other subsystems reload after extension:remove helps -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1815) It's not possible to re-add extension

by Martin Simka (JIRA)

Martin Simka created WFCORE-1815: ------------------------------------ Summary: It's not possible to re-add extension Key: WFCORE-1815 URL: https://issues.jboss.org/browse/WFCORE-1815 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha8 Reporter: Martin Simka Assignee: Brian Stansberry {noformat} [standalone@localhost:9990 /] /subsystem=ejb3:remove { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9990 /] reload [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:remove {"outcome" => "success"} [standalone@localhost:9990 /] /extension=org.jboss.as.ejb3:add { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3'", "rolled-back" => true } {noformat} {noformat} 13:46:48,278 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.jboss.as.ejb3")]): java.lang.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subdeployment=*/subsystem=ejb3' at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:222) at org.jboss.as.controller.extension.ExtensionRegistry$DeploymentManagementResourceRegistration.registerSubModel(ExtensionRegistry.java:922) at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerDeploymentModel(ExtensionRegistry.java:700) at org.jboss.as.ejb3.subsystem.EJB3Extension.initialize(EJB3Extension.java:91) at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) 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) {noformat} the error with logging subsystem, I didn't try other subsystems reload after extension:remove helps -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7203) Elytron - inconsistency between DMR and XSD representation of regex-name-validating-rewriter

by Jan Tymel (JIRA)

Jan Tymel created WFLY-7203: ------------------------------- Summary: Elytron - inconsistency between DMR and XSD representation of regex-name-validating-rewriter Key: WFLY-7203 URL: https://issues.jboss.org/browse/WFLY-7203 Project: WildFly Issue Type: Bug Components: Security Reporter: Jan Tymel Assignee: Darran Lofthouse Priority: Optional There is an inconsistency between DMR and XSD representation of {{regex-name-validating-rewriter}}. According to XSD[1] is {{match}} attribute optional. On the other hand DMR[2] says that {{match}} attribute is mandatory (_"nillable" => false_). {{Match}} attribute is currently required if user adds a new regex-name-validating-rewriter. Is it an intentional behaviour or should {{match}} be optional (=according to XSD definition)? [1] https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... [2] {{/subsystem=elytron:read-resource-description(recursive=true)}} {code} "regex-name-validating-rewriter" => { "description" => "A regular expression based Name Rewriter which uses the regular expression to validate the name.", "model-description" => {"*" => { "description" => "A regular expression based Name Rewriter which uses the regular expression to validate the name.", "capabilities" => [{ "name" => "org.wildfly.security.name-rewriter", "dynamic" => true }], "attributes" => { "match" => { "type" => BOOLEAN, "description" => "Should names that match the pattern be rejected or names that don't", "expressions-allowed" => true, "nillable" => false, "default" => true, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, "pattern" => { "type" => STRING, "description" => "The regular expression to use to locate the portion of the name to be replaced.", "expressions-allowed" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" } }, "operations" => undefined, "notifications" => undefined, "children" => {} }} } {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-591) revertReloadRequired() throws a NPE is reloadRequired has not been called

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-591?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-591: ------------------------------------------------ Vlado Pakan <vpakan(a)redhat.com> changed the Status of [bug 1294591|https://bugzilla.redhat.com/show_bug.cgi?id=1294591] from POST to MODIFIED > revertReloadRequired() throws a NPE is reloadRequired has not been called > ------------------------------------------------------------------------- > > Key: WFCORE-591 > URL: https://issues.jboss.org/browse/WFCORE-591 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 1.0.0.Beta1 > > > If an operation step handler calls org.jboss.as.controller.OperationContext#revertReloadRequired() when org.jboss.as.controller.OperationContext#reloadRequired() has not been called, it throws a NPE: > {noformat} > java.lang.NullPointerException > at org.jboss.as.controller.ControlledProcessState.revertReloadRequired(ControlledProcessState.java:181) > at org.jboss.as.controller.AbstractOperationContext.revertReloadRequired(AbstractOperationContext.java:1037) > at org.jboss.as.controller.test.RevertReloadRequiredTestCase$TestResourceAddHandler.rollbackRuntime(RevertReloadRequiredTestCase.java:98) > at org.jboss.as.controller.AbstractAddStepHandler$1$1.handleRollback(AbstractAddStepHandler.java:133) > at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1419) > at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1385) > at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1367) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1323) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1283) > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1172) > at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:929) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1182) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205) > {noformat} > The NPE is caused by this.activeStep.restartStamp field which is set only when reloadRequired() (or restartRequired()) is called. > My OSH may call reloadRequired() or not depending on some runtime state and I could add some logic to make sure I call > I can fix my handle to check that I call context.revertReloadRequired() only I had previously called reloadRequired () first. > However, in order to make the OperationContext more robust, I think that the revertReloadRequired() method should instead be a no-op if there is no reload required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7202) generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7202?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7202: ----------------------------------------------- Tom Ross <tom.ross(a)redhat.com> changed the Status of [bug 1378723|https://bugzilla.redhat.com/show_bug.cgi?id=1378723] from ASSIGNED to MODIFIED > generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type > ------------------------------------------------------------------------------------------------ > > Key: WFLY-7202 > URL: https://issues.jboss.org/browse/WFLY-7202 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: Tom Ross > Assignee: Tom Ross > > The code snippet shows that the method returns wrong type. > {noformat} > public String getSessionDefaultType() { > if (type == JmsConnectionFactory.AGNOSTIC) > return "agnostic"; > else if (type == JmsConnectionFactory.QUEUE) > return TOPIC_TYPE; > else > return QUEUE_TYPE; > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7202) generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type

by Tom Ross (JIRA)

[ https://issues.jboss.org/browse/WFLY-7202?page=com.atlassian.jira.plugin.... ] Tom Ross updated WFLY-7202: --------------------------- Summary: generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type (was: JmsMCFProperties.getSessionDefaultType() method in generic-jms-ra returns wrong type.) > generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type > ------------------------------------------------------------------------------------------------ > > Key: WFLY-7202 > URL: https://issues.jboss.org/browse/WFLY-7202 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: Tom Ross > Assignee: Tom Ross > > The code snippet shows that the method returns wrong type. > {noformat} > public String getSessionDefaultType() { > if (type == JmsConnectionFactory.AGNOSTIC) > return "agnostic"; > else if (type == JmsConnectionFactory.QUEUE) > return TOPIC_TYPE; > else > return QUEUE_TYPE; > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7202) JmsMCFProperties.getSessionDefaultType() method in generic-jms-ra returns wrong type.

by Tom Ross (JIRA)

[ https://issues.jboss.org/browse/WFLY-7202?page=com.atlassian.jira.plugin.... ] Tom Ross updated WFLY-7202: --------------------------- Summary: JmsMCFProperties.getSessionDefaultType() method in generic-jms-ra returns wrong type. (was: JmsMCFProperties.getSessionDefaultType() method in generic-kms-ra returns wrong type.) > JmsMCFProperties.getSessionDefaultType() method in generic-jms-ra returns wrong type. > ------------------------------------------------------------------------------------- > > Key: WFLY-7202 > URL: https://issues.jboss.org/browse/WFLY-7202 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: Tom Ross > Assignee: Tom Ross > > The code snippet shows that the method returns wrong type. > {noformat} > public String getSessionDefaultType() { > if (type == JmsConnectionFactory.AGNOSTIC) > return "agnostic"; > else if (type == JmsConnectionFactory.QUEUE) > return TOPIC_TYPE; > else > return QUEUE_TYPE; > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7202) JmsMCFProperties.getSessionDefaultType() method in generic-kms-ra returns wrong type.

by Tom Ross (JIRA)

[ https://issues.jboss.org/browse/WFLY-7202?page=com.atlassian.jira.plugin.... ] Tom Ross reassigned WFLY-7202: ------------------------------ Assignee: Tom Ross (was: Jeff Mesnil) > JmsMCFProperties.getSessionDefaultType() method in generic-kms-ra returns wrong type. > ------------------------------------------------------------------------------------- > > Key: WFLY-7202 > URL: https://issues.jboss.org/browse/WFLY-7202 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: Tom Ross > Assignee: Tom Ross > > The code snippet shows that the method returns wrong type. > {noformat} > public String getSessionDefaultType() { > if (type == JmsConnectionFactory.AGNOSTIC) > return "agnostic"; > else if (type == JmsConnectionFactory.QUEUE) > return TOPIC_TYPE; > else > return QUEUE_TYPE; > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7202) JmsMCFProperties.getSessionDefaultType() method in generic-kms-ra returns wrong type.

by Tom Ross (JIRA)

Tom Ross created WFLY-7202: ------------------------------ Summary: JmsMCFProperties.getSessionDefaultType() method in generic-kms-ra returns wrong type. Key: WFLY-7202 URL: https://issues.jboss.org/browse/WFLY-7202 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: Tom Ross Assignee: Jeff Mesnil The code snippet shows that the method returns wrong type. {noformat} public String getSessionDefaultType() { if (type == JmsConnectionFactory.AGNOSTIC) return "agnostic"; else if (type == JmsConnectionFactory.QUEUE) return TOPIC_TYPE; else return QUEUE_TYPE; } {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7194) Simplify creation of trust/key-manager in elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7194?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7194: ---------------------------------- No, to use JVM default it will have to be defined explicitly. The idea is to not abet administrators to use non-JVM-portable configuration. Sorry. > Simplify creation of trust/key-manager in elytron > ------------------------------------------------- > > Key: WFLY-7194 > URL: https://issues.jboss.org/browse/WFLY-7194 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > > If I want to setup TLS [1], I have to create key manager with CLI command > {code} > /subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509") > {code} > 1. It seems to me {{algorithm}} can be optional. If not set {{TrustManagerFactory.getDefaultAlgorithm()}} can be used. > 2. Also, please, enhance xsd/model documentation with clear statement that this {{password}} attribute is in fact "key password" . Or probably better rename attribute from {{password}} to {{key-password}} to make it absolutely clear to everyone. > 3. {{key-store}} attribute is declared optional in xsd . In model it is properly declared as required. Please change XSD to express it is required. > {code} > <xs:attribute name="key-store" type="xs:string" use="optional"> > <xs:annotation> > <xs:documentation> > Reference to the KeyStore to use with the KeyManager. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > 4.{{password}} attribute is optional, probably should be required > {code} > "password" => { > "type" => STRING, > "description" => "The password to use when initialising the underlying KeyManagerFactory.", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "deprecated" => { > "since" => "1.0.0", > "reason" => "Will be updated to use proper CredentialStore references." > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7149) Unable to remove elytron subsystem with defined properties-realm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7149?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7149: -------------------------------- Assignee: Bartosz Baranowski (was: Jan Kalina) > Unable to remove elytron subsystem with defined properties-realm > ---------------------------------------------------------------- > > Key: WFLY-7149 > URL: https://issues.jboss.org/browse/WFLY-7149 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Radim Hatlapatka > Assignee: Bartosz Baranowski > Priority: Critical > > When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies \[1\]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove. > \[1\] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security > Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7192) 'name' attribute missing in XSD while required by web subsystem parser

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7192?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-7192: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1365939 Bugzilla Update: Perform > 'name' attribute missing in XSD while required by web subsystem parser > ---------------------------------------------------------------------- > > Key: WFLY-7192 > URL: https://issues.jboss.org/browse/WFLY-7192 > Project: WildFly > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > Labels: downstream_dependency > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1365939 , originaly reported by [~paramjindal] > While configuring the global valve using the following article : > https://access.redhat.com/solutions/379813 > It is mandatory that the "name" attribute of valve must match the "auth-method" that is specified in the "WEB-INF/web.xml". > So "name" attribute is mandatory to configure this valve. > but it is not mentioned in the schema of valve as shown below : > {code:xml} > <xs:element name="valve"> > <xs:complexType> > <xs:sequence> > <xs:element name="param" minOccurs="0" maxOccurs="unbounded" type="paramType" /> > </xs:sequence> > <xs:attribute name="class-name" type="xs:string" use="required" /> > <xs:attribute name="module" type="xs:string" use="required" /> > <xs:attribute name="enabled" default="true" type="xs:boolean" /> > </xs:complexType> > </xs:element> > {code} > Version-Release number of selected component (if applicable): -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1304) OOPath ReactiveList remove cases

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1304: ----------------------------------- Summary: OOPath ReactiveList remove cases Key: DROOLS-1304 URL: https://issues.jboss.org/browse/DROOLS-1304 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.CR2 Reporter: Matteo Mortari Assignee: Matteo Mortari Priority: Minor * Removing element from ReactiveList is not covered * Ensure removing from 1 out of many ReactiveList does affect only the relevant lists when issuing modification to a ReactiveObject -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-958) JASPIC implementation in JBoss EAP 7.0.0 seems to contradict the javadoc of the ServerAuthModule interface

by Enrique González Martínez (JIRA)

Enrique González Martínez created SECURITY-958: -------------------------------------------------- Summary: JASPIC implementation in JBoss EAP 7.0.0 seems to contradict the javadoc of the ServerAuthModule interface Key: SECURITY-958 URL: https://issues.jboss.org/browse/SECURITY-958 Project: PicketBox Issue Type: Bug Reporter: Enrique González Martínez Assignee: Enrique González Martínez The EAP 7.0.0 JASPIC ServerAuthModule framework passes the request policy and response policy objects as null into the initialize() method. The spec and java docs say that both must not be null. http://docs.oracle.com/javaee/6/api/javax/security/auth/message/module/Se... https://docs.oracle.com/javaee/7/api/javax/security/auth/message/module/S... The javadoc and spec says: "The request policy and the response policy must not both be null". Wildfly 10.0.0.Final has the same issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7194) Simplify creation of trust/key-manager in elytron

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7194?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFLY-7194: ------------------------------------ Does that mean "Default" will be declared as default value in model? So if I don't specify algorithm "Default" will be applied? [~dlofthouse] [~honza889] My motivation for point 1 is part of general idea: "Provide a possibility to create SSL Context in simple way." That's why I think in terms, "does that really need to be provided by user"? I really like that user can configure pretty everything now, but I think also on people who want ideally specify just keystore and password to make TLS work. > Simplify creation of trust/key-manager in elytron > ------------------------------------------------- > > Key: WFLY-7194 > URL: https://issues.jboss.org/browse/WFLY-7194 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > > If I want to setup TLS [1], I have to create key manager with CLI command > {code} > /subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509") > {code} > 1. It seems to me {{algorithm}} can be optional. If not set {{TrustManagerFactory.getDefaultAlgorithm()}} can be used. > 2. Also, please, enhance xsd/model documentation with clear statement that this {{password}} attribute is in fact "key password" . Or probably better rename attribute from {{password}} to {{key-password}} to make it absolutely clear to everyone. > 3. {{key-store}} attribute is declared optional in xsd . In model it is properly declared as required. Please change XSD to express it is required. > {code} > <xs:attribute name="key-store" type="xs:string" use="optional"> > <xs:annotation> > <xs:documentation> > Reference to the KeyStore to use with the KeyManager. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > 4.{{password}} attribute is optional, probably should be required > {code} > "password" => { > "type" => STRING, > "description" => "The password to use when initialising the underlying KeyManagerFactory.", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "deprecated" => { > "since" => "1.0.0", > "reason" => "Will be updated to use proper CredentialStore references." > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7201) Statement.cancel() is not invoked until the statement is completed

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7201?page=com.atlassian.jira.plugin.... ] Lin Gao deleted WFLY-7201: -------------------------- > Statement.cancel() is not invoked until the statement is completed > ------------------------------------------------------------------ > > Key: WFLY-7201 > URL: https://issues.jboss.org/browse/WFLY-7201 > Project: WildFly > Issue Type: Bug > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Critical > > Hi, > in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}: > {code:java} > public void cancel() throws SQLException > { > if (doLocking) > lock(); > try > { > /* ... */ > {code} > It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock. > Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion. > Thank you, > lorenzo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7201) Statement.cancel() is not invoked until the statement is completed

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7201?page=com.atlassian.jira.plugin.... ] Lin Gao moved JBEAP-6173 to WFLY-7201: -------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7201 (was: JBEAP-6173) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) Affects Version/s: (was: 7.0.0.GA) > Statement.cancel() is not invoked until the statement is completed > ------------------------------------------------------------------ > > Key: WFLY-7201 > URL: https://issues.jboss.org/browse/WFLY-7201 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Critical > > Hi, > in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}: > {code:java} > public void cancel() throws SQLException > { > if (doLocking) > lock(); > try > { > /* ... */ > {code} > It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock. > Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion. > Thank you, > lorenzo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7200) Websocket compression should be controlled through the management model

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7200: ------------------------------------ Summary: Websocket compression should be controlled through the management model Key: WFLY-7200 URL: https://issues.jboss.org/browse/WFLY-7200 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7199) Websocket compression should be controlled through the management model

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7199: ------------------------------------ Summary: Websocket compression should be controlled through the management model Key: WFLY-7199 URL: https://issues.jboss.org/browse/WFLY-7199 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1331) Use connection-url to get database connection when connection properties for datasource-class is empty

by Lin Gao (JIRA)

Lin Gao created JBJCA-1331: ------------------------------ Summary: Use connection-url to get database connection when connection properties for datasource-class is empty Key: JBJCA-1331 URL: https://issues.jboss.org/browse/JBJCA-1331 Project: IronJacamar Issue Type: Task Components: JDBC Affects Versions: WildFly/IronJacamar 1.3.4.Final Reporter: Lin Gao Assignee: Lin Gao Fixes of JBJCA-1312 will fail the old configuration where the connection-url is used. In the compatibility point of view, we should try to use {{connection-url}} & {{driver-class}} to get the database connection if the connection properties are empty && datasource-class != null. A warning message should be printed to encourage users to use DataSource for database connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1316) patch apply command not working as expected in non-interactive mode in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1316?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1316: ------------------------------------------------- Vlado Pakan <vpakan(a)redhat.com> changed the Status of [bug 1290290|https://bugzilla.redhat.com/show_bug.cgi?id=1290290] from POST to MODIFIED > patch apply command not working as expected in non-interactive mode in domain mode > ----------------------------------------------------------------------------------- > > Key: WFCORE-1316 > URL: https://issues.jboss.org/browse/WFCORE-1316 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > Fix For: 2.0.8.Final > > > CLI patch apply command is misleading when the --host option is used. In non-interactive mode applies the patch to the local installation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7198) Add support for Elytron SecurityDomain in IIOP-enabled EJBs

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFLY-7198?page=com.atlassian.jira.plugin.... ] Stefan Guilhen updated WFLY-7198: --------------------------------- Description: With https://issues.jboss.org/browse/WFLY-5689 we now have a way to map security domains as defined within deployment descriptors to Elytron security domains in the EJB3 subsystem. This means that IIOP-enabled beans should make use of the Elytron security framework to authenticate and authorize incoming requests if such a mapping exists for the EJB application. (was: With https://issues.jboss.org/browse/WFLY-5689 we now have a way to map security domains as defined within deployment descriptors to Elytron security domains in the EJB3 subsystem. This means that IIOP-enabled beans should make use of the Elytron security framework to authenticate and authorize incoming requests.) > Add support for Elytron SecurityDomain in IIOP-enabled EJBs > ----------------------------------------------------------- > > Key: WFLY-7198 > URL: https://issues.jboss.org/browse/WFLY-7198 > Project: WildFly > Issue Type: Feature Request > Components: EJB, IIOP > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Labels: affects_elytron > > With https://issues.jboss.org/browse/WFLY-5689 we now have a way to map security domains as defined within deployment descriptors to Elytron security domains in the EJB3 subsystem. This means that IIOP-enabled beans should make use of the Elytron security framework to authenticate and authorize incoming requests if such a mapping exists for the EJB application. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7198) Add support for Elytron SecurityDomain in IIOP-enabled EJBs

by Stefan Guilhen (JIRA)

Stefan Guilhen created WFLY-7198: ------------------------------------ Summary: Add support for Elytron SecurityDomain in IIOP-enabled EJBs Key: WFLY-7198 URL: https://issues.jboss.org/browse/WFLY-7198 Project: WildFly Issue Type: Feature Request Components: EJB, IIOP Reporter: Stefan Guilhen Assignee: Stefan Guilhen With https://issues.jboss.org/browse/WFLY-5689 we now have a way to map security domains as defined within deployment descriptors to Elytron security domains in the EJB3 subsystem. This means that IIOP-enabled beans should make use of the Elytron security framework to authenticate and authorize incoming requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7197) Allow configuration of an Elytron SSLContext in the IIOP subsystem

by Stefan Guilhen (JIRA)

Stefan Guilhen created WFLY-7197: ------------------------------------ Summary: Allow configuration of an Elytron SSLContext in the IIOP subsystem Key: WFLY-7197 URL: https://issues.jboss.org/browse/WFLY-7197 Project: WildFly Issue Type: Feature Request Components: IIOP Reporter: Stefan Guilhen Assignee: Tomasz Adamski Currently the IIOP subsystem defines an attribute that references a JSSE security domain to obtain the key and trust managers used by the SSLSocketFactory to build an SSLContext instance. With Elytron we now have a new capability that exposes SSLContext instances and we should be able to use that in the IIOP subsystem. A new attribute must be added to allow for the specification of the Elytron SSLContext that should be used. The SSLSocketFactory will still support the old JSSE-based configuration but will be able to make use of Elytron's centralized SSL configuration to obtain an SSLContext. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7197) Allow configuration of an Elytron SSLContext in the IIOP subsystem

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFLY-7197?page=com.atlassian.jira.plugin.... ] Stefan Guilhen reassigned WFLY-7197: ------------------------------------ Assignee: Stefan Guilhen (was: Tomasz Adamski) > Allow configuration of an Elytron SSLContext in the IIOP subsystem > ------------------------------------------------------------------ > > Key: WFLY-7197 > URL: https://issues.jboss.org/browse/WFLY-7197 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Labels: affects_elytron > > Currently the IIOP subsystem defines an attribute that references a JSSE security domain to obtain the key and trust managers used by the SSLSocketFactory to build an SSLContext instance. > With Elytron we now have a new capability that exposes SSLContext instances and we should be able to use that in the IIOP subsystem. A new attribute must be added to allow for the specification of the Elytron SSLContext that should be used. The SSLSocketFactory will still support the old JSSE-based configuration but will be able to make use of Elytron's centralized SSL configuration to obtain an SSLContext. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBAS-7853) Migrate sessions that use jvmRoute to nodes where they are local cached

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBAS-7853?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBAS-7853: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1233400|https://bugzilla.redhat.com/show_bug.cgi?id=1233400] from MODIFIED to ON_QA > Migrate sessions that use jvmRoute to nodes where they are local cached > ----------------------------------------------------------------------- > > Key: JBAS-7853 > URL: https://issues.jboss.org/browse/JBAS-7853 > Project: Application Server 3 4 5 and 6 > Issue Type: Task > Components: Clustering, Web (Tomcat) service > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Fix For: 6.0.0.CR1 > > > Detect situation where a session is not stored locally in infinispan on the node that is servicing it. (This could happen with DIST following a rehash). If detected, determine the jvmRoute of a node where the session is local. Change the jvmRoute of session cookie to that node, which will trigger the next request going there. > Note that this requires that the request that is changing the jvmRoute also replicates the session synchronously. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-286) HTTP Digest Authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-286?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-286: -------------------------------------- Design notes for nonce handling: - https://developer.jboss.org/docs/DOC-55755 > HTTP Digest Authentication > -------------------------- > > Key: ELY-286 > URL: https://issues.jboss.org/browse/ELY-286 > Project: WildFly Elytron > Issue Type: Sub-task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > > Original Digest RFC [https://tools.ietf.org/html/rfc2069] > Current Digest RFC [https://tools.ietf.org/html/rfc2617] > HTTP 1.1 Authentication (Updates RFC2617) [https://tools.ietf.org/html/rfc7235] > Draft currently under discussion - [https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/] > RFC7616 Now Proposed Standard > "HTTP Digest Access Authentication", September 2015 > [https://www.rfc-editor.org/info/rfc7616] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-639) SecurityIdentity and PeerIdentity should have more runAs* variants

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-639?page=com.atlassian.jira.plugin.sy... ] David Lloyd updated ELY-639: ---------------------------- Description: The XxxIdentity classes have fewer runAs modes than (for example) Contextual objects do. Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common. (was: The *Identity classes have fewer runAs modes than (for example) Contextual objects do. Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common.) > SecurityIdentity and PeerIdentity should have more runAs* variants > ------------------------------------------------------------------ > > Key: ELY-639 > URL: https://issues.jboss.org/browse/ELY-639 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Fix For: 1.1.0.Beta10 > > > The XxxIdentity classes have fewer runAs modes than (for example) Contextual objects do. Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-639) SecurityIdentity and PeerIdentity should have more runAs* variants

by David Lloyd (JIRA)

David Lloyd created ELY-639: ------------------------------- Summary: SecurityIdentity and PeerIdentity should have more runAs* variants Key: ELY-639 URL: https://issues.jboss.org/browse/ELY-639 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI Reporter: David Lloyd Fix For: 1.1.0.Beta10 The *Identity classes have fewer runAs modes than (for example) Contextual objects do. Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ FYI [https://java.net/projects/jpa-spec/lists/users/archive/2016-09/message/1] asks if [https://java.net/jira/browse/JPA_SPEC-6] should be reconsidered for the next JPA release. > proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7194) Simplify creation of trust/key-manager in elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7194?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7194: ---------------------------------- *Part 1* was rejected. JVM default is not recommended because not portable between JVMs. Change of attribute to required would broke back compatibility. JVM default can be allowed as special value "Default" => https://github.com/wildfly-security/elytron-subsystem/issues/235 > Simplify creation of trust/key-manager in elytron > ------------------------------------------------- > > Key: WFLY-7194 > URL: https://issues.jboss.org/browse/WFLY-7194 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > > If I want to setup TLS [1], I have to create key manager with CLI command > {code} > /subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509") > {code} > 1. It seems to me {{algorithm}} can be optional. If not set {{TrustManagerFactory.getDefaultAlgorithm()}} can be used. > 2. Also, please, enhance xsd/model documentation with clear statement that this {{password}} attribute is in fact "key password" . Or probably better rename attribute from {{password}} to {{key-password}} to make it absolutely clear to everyone. > 3. {{key-store}} attribute is declared optional in xsd . In model it is properly declared as required. Please change XSD to express it is required. > {code} > <xs:attribute name="key-store" type="xs:string" use="optional"> > <xs:annotation> > <xs:documentation> > Reference to the KeyStore to use with the KeyManager. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > 4.{{password}} attribute is optional, probably should be required > {code} > "password" => { > "type" => STRING, > "description" => "The password to use when initialising the underlying KeyManagerFactory.", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "deprecated" => { > "since" => "1.0.0", > "reason" => "Will be updated to use proper CredentialStore references." > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7196) The outcome of xa_commit call on non exiting transaction is silently ignored

by Tom Ross (JIRA)

Tom Ross created WFLY-7196: ------------------------------ Summary: The outcome of xa_commit call on non exiting transaction is silently ignored Key: WFLY-7196 URL: https://issues.jboss.org/browse/WFLY-7196 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.1.0.Final Reporter: Tom Ross This from mail thread on transactional mailing list: {noformat} There is definitely a bug in EJBR. These two at least look wrong by inspection: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it. You could simulate this with a test case that gets hold of the EJBR XAResource and invokes: xar.prepare(dummyXid) and does not get back XAER_NOTA That explains how the root transaction can prepare/commit without error as we can see here: 2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b 2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions. What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue. What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently. After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that. {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7196) The outcome of xa_commit call on non exiting transaction is silently ignored

by Tom Ross (JIRA)

[ https://issues.jboss.org/browse/WFLY-7196?page=com.atlassian.jira.plugin.... ] Tom Ross updated WFLY-7196: --------------------------- Description: This is from mail thread on transactional mailing list: {noformat} There is definitely a bug in EJBR. These two at least look wrong by inspection: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it. You could simulate this with a test case that gets hold of the EJBR XAResource and invokes: xar.prepare(dummyXid) and does not get back XAER_NOTA That explains how the root transaction can prepare/commit without error as we can see here: 2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b 2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions. What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue. What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently. After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that. {noformat} was: This from mail thread on transactional mailing list: {noformat} There is definitely a bug in EJBR. These two at least look wrong by inspection: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it. You could simulate this with a test case that gets hold of the EJBR XAResource and invokes: xar.prepare(dummyXid) and does not get back XAER_NOTA That explains how the root transaction can prepare/commit without error as we can see here: 2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b 2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions. What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue. What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently. After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that. {noformat} > The outcome of xa_commit call on non exiting transaction is silently ignored > ---------------------------------------------------------------------------- > > Key: WFLY-7196 > URL: https://issues.jboss.org/browse/WFLY-7196 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Reporter: Tom Ross > > This is from mail thread on transactional mailing list: > {noformat} > There is definitely a bug in EJBR. > These two at least look wrong by inspection: > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... > The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it. > You could simulate this with a test case that gets hold of the EJBR XAResource and invokes: > xar.prepare(dummyXid) and does not get back XAER_NOTA > That explains how the root transaction can prepare/commit without error as we can see here: > 2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b > 2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b > Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions. > What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue. > What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently. > After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that. > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7195) Transaction context should not be propagated when calling remote server asynchronously

by Tom Ross (JIRA)

Tom Ross created WFLY-7195: ------------------------------ Summary: Transaction context should not be propagated when calling remote server asynchronously Key: WFLY-7195 URL: https://issues.jboss.org/browse/WFLY-7195 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.1.0.Final Environment: Wildfly 10.x Reporter: Tom Ross When an EJB call is made asynchronously between two JBoss servers the transaction context should not be propagated as per EJB spec. {noformat} EJB 3.2 4.5.3 Transactions The client’s transaction context does not propagate with an asynchronous method invocation. From the Bean Provider’s point of view, there is never a transaction context flowing in from the client. This means, for example, that the semantics of the REQUIRED transaction attribute on an asynchronous method are exactly the same as REQUIRES_NEW. {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-987: ---------------------------------- Assignee: Mario Fusco (was: Maciej Swiderski) > Errors in Phreak under heavy and multi threaded load > ----------------------------------------------------- > > Key: DROOLS-987 > URL: https://issues.jboss.org/browse/DROOLS-987 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final, 6.4.0.Final > Environment: linux > Java 7 > kernel 3.16 > Reporter: Jose Cavieres > Assignee: Mario Fusco > Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz > > > Several threads are started, each one starts 1 jbpm process containing rule(s) task(s). > If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%. > Aparently the setFocus method used by rule tasks is related to the problem. > The most comon error is: > Caused by: java.lang.NullPointerException > at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266) > at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361) > at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334) > at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317) > at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358) > at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7194) Simplify creation of trust/key-manager in elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7194?page=com.atlassian.jira.plugin.... ] Jan Kalina moved JBEAP-6159 to WFLY-7194: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7194 (was: JBEAP-6159) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.DR4) > Simplify creation of trust/key-manager in elytron > ------------------------------------------------- > > Key: WFLY-7194 > URL: https://issues.jboss.org/browse/WFLY-7194 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > > If I want to setup TLS [1], I have to create key manager with CLI command > {code} > /subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509") > {code} > 1. It seems to me {{algorithm}} can be optional. If not set {{TrustManagerFactory.getDefaultAlgorithm()}} can be used. > 2. Also, please, enhance xsd/model documentation with clear statement that this {{password}} attribute is in fact "key password" . Or probably better rename attribute from {{password}} to {{key-password}} to make it absolutely clear to everyone. > 3. {{key-store}} attribute is declared optional in xsd . In model it is properly declared as required. Please change XSD to express it is required. > {code} > <xs:attribute name="key-store" type="xs:string" use="optional"> > <xs:annotation> > <xs:documentation> > Reference to the KeyStore to use with the KeyManager. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > 4.{{password}} attribute is optional, probably should be required > {code} > "password" => { > "type" => STRING, > "description" => "The password to use when initialising the underlying KeyManagerFactory.", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "deprecated" => { > "since" => "1.0.0", > "reason" => "Will be updated to use proper CredentialStore references." > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Scott Marlow commented on JASSIST-261: -------------------------------------- [~sebersole] I think yes, part of the text from the linked [http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-June/000307...] proposal is quoted here, which I think is showing that the application developer changes their Hibernate applications to privately export these classes to Hibernate: {quote} Proposal -------- Extend the language of module declarations so that a package can be declared to be exported at run time but not at compile time. This is, roughly, the dual of the `requires static` construct proposed for #CompileTimeDependences, hence we propose to introduce a new modifier, `dynamic`, for use on the `exports` directive. It has the following meanings: - At compile time, `exports dynamic P` does not cause the package `P` to be exported, though it does require `P` to be a package defined in the module. - In phases after compile time, `exports dynamic P` behaves in exactly the same way as `exports P`. It therefore takes part fully in resolution and configuration, and is subject to the same consistency constraints as normally-exported packages (e.g., no split packages). Thus a module declaration of the form module com.foo.app { requires hibernate.core; requires hibernate.entitymanager; exports dynamic com.foo.app.model; } makes the types in the `com.foo.app.model` package accessible at run time but not at compile time. In combination with the earlier change to enable #ReflectionWithoutReadability [2] this means that frameworks that today use core reflection to manipulate user classes at run time are more likely to work out-of-the-box, without change, as automatic modules. If the `com.foo.app.model` package in this example includes entity classes to be managed by Hibernate then the framework will be able to access them without further ado, but under normal circumstances an attempt to compile code that refers directly to those classes will fail. The `dynamic` modifier can be applied to both unqualified and qualified `exports` directives, though the caveats on using qualified exports [3] still apply. {quote} [https://java.net/projects/javaee-spec/lists/jsr366-experts/archive/2016-0...] is where I saw the (above mentioned) list of issues being discussed. > Issue with javassist on jdk 9b112 > --------------------------------- > > Key: JASSIST-261 > URL: https://issues.jboss.org/browse/JASSIST-261 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Environment: Javassist with jdk 9b112 > Reporter: Hoang Chuong Tran > Assignee: Shigeru Chiba > > I am migrating a project to java 9, which also uses javassist to generate runtime code. > One test of mine fails on jdk 9b112 while it passes on jdk 8u77. > {noformat} > import static javassist.CtClass.voidType; > import java.lang.reflect.Method; > import java.lang.reflect.Modifier; > import java.util.HashMap; > import java.util.Map; > import org.junit.Test; > import javassist.ClassClassPath; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtField; > import javassist.CtMethod; > import javassist.CtNewMethod; > public class MyTests { > public static class MyObject { > protected Object field; > Object getField() {return field;} > public void setField(Object field) {} > } > @Test > public void test() throws InstantiationException, IllegalAccessException { > Class<? extends MyObject> clazz = compile(MyObject.class); > clazz.newInstance().setField(null); > } > /** Compile a transfer class */ > public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) { > // Determine class setters > Map<String, Method> setters = extractSetters(targetClass); > ClassPool classPool = ClassPool.getDefault(); > classPool.insertClassPath(new ClassClassPath(targetClass)); > try { > // Compile a new transfer class on the fly > CtClass baseClass = classPool.get(MyObject.class.getName()); > CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass); > for(Method originalSetter : setters.values()) { > // Create a field to hold the attribute > Class<?> fieldClass = originalSetter.getParameterTypes()[0]; > CtClass fieldType = classPool.get(fieldClass.getName()); > String fieldName = originalSetter.getName().substring(3); > CtField field = new CtField(fieldType, fieldName, proxyClass); > proxyClass.addField(field); > // Create a setter method to set that field > CtClass[] parameters = new CtClass[] { fieldType }; > String setterBody = "{ System.out.println(\"Hello World\"); }"; > CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass); > proxyClass.addMethod(setter); > } > Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain()); > return javaClass; > } catch(Exception e) { > throw new RuntimeException("Failure during transfer compilation for " + targetClass, e); > } > } > /** Extract setter methods from a class */ > public static Map<String, Method> extractSetters(Class<?> cls) { > Map<String, Method> setters = new HashMap<String, Method>(); > for(Method method : cls.getMethods()) { > // Lookup setter methods > if(method.getName().startsWith("set")) { > // Only public setters > int modifiers = method.getModifiers(); > if(Modifier.isPublic(modifiers)) { > Class<?>[] exceptions = method.getExceptionTypes(); > Class<?>[] parameters = method.getParameterTypes(); > Class<?> returnType = method.getReturnType(); > if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) { > setters.put(method.getName(), method); > } > } > } > } > return setters; > } > } > {noformat} > On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. > On jdk 9b112, I got the following exception > {noformat} > java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject > at MyTests.compile(MyTests.java:68) > at MyTests.test(MyTests.java:29) > at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: javassist.NotFoundException: java.lang.Object > at javassist.ClassPool.get(ClassPool.java:450) > at MyTests.compile(MyTests.java:51) > ... 24 more > {noformat} > I suspect that is due to the jigsaw integration into the jdk. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1730) Singleton service is not correctly being set in WILDFLY

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1730?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1730: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1367793|https://bugzilla.redhat.com/show_bug.cgi?id=1367793] from MODIFIED to ON_QA > Singleton service is not correctly being set in WILDFLY > ------------------------------------------------------- > > Key: WFCORE-1730 > URL: https://issues.jboss.org/browse/WFCORE-1730 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 3.0.0.Alpha5 > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > WILDFLY doesn't call ServiceLoader (META-INF/services/org.jboss.msc.service.ServiceActivator) when it is deployed in EAR/lib. The SingletonService (not a singleton EJB) is activated in the ServiceLoader so the SingletonService hasn't been activated from the first. It works as expected when deployed as an EJB (not in EAR/lib). > When the ServiceLoader is called, a message of "HATimerService will be installed!" is logged and the SingletonService will be activated. > $ fgrep -e HATimerService -e '[org.jboss.as.clustering.singleton]' domain/servers/server-one/log/server.log > 12:14:52,373 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator] (MSC service thread 1-7) HATimerService will be installed! > 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service > 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010340: This node will now operate as the singleton provider of the jboss.quickstart.ha.singleton.timer service > 12:14:56,268 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerService] (MSC service thread 1-8) Start HASingleton timer service 'org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATim > erService' > 12:14:56,873 INFO [org.jboss.as.clustering.singleton] (notification-thread-0) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1360) CLI Options missed in WFCORE-1199

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1360?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1360: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1284885|https://bugzilla.redhat.com/show_bug.cgi?id=1284885] from MODIFIED to ON_QA > CLI Options missed in WFCORE-1199 > --------------------------------- > > Key: WFCORE-1360 > URL: https://issues.jboss.org/browse/WFCORE-1360 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 2.1.0.Final > > > The comma-seperated lists for server-groups in DeployHandler and UndeployHandler were missed in the original commit for WFCORE-1199. The --properties field for ASModuleHandler as also omitted by mistake. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1199) CLI Lists in non-interactive mode are erroneously split into multiple commands

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1199?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1199: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1284885|https://bugzilla.redhat.com/show_bug.cgi?id=1284885] from MODIFIED to ON_QA > CLI Lists in non-interactive mode are erroneously split into multiple commands > ------------------------------------------------------------------------------ > > Key: WFCORE-1199 > URL: https://issues.jboss.org/browse/WFCORE-1199 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Modules, Patching > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 2.0.8.Final > > > The problem arises because commands entered in non-interactive mode are split by the "," character. Therefore, in the case of: > "./bin/jboss-cli.sh -c --controller=localhost --commands="module add --name=test --resources=test.jar --dependencies=dep1,dep2" > the cli is incorrectly splitting the request into two distinct commands: > 1. module add --name=test --resources=test.jar --dependencies=dep1 > 2. dep2 > The reason this behaviour is not observed in interactive mode is because multiple commands can not be specified. However, in non-interactive mode --commands=ls,pwd is valid and should result in the execution of ls followed by pwd. > This problem is not restricted to the module command, as it affects all commands entered in non-interactive mode that require a comma-separated list as an argument. So far this appears to be PatchHanlder.java, ASModuleHandler.java and DeploymentOverlayHandler.java. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6680: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1343633|https://bugzilla.redhat.com/show_bug.cgi?id=1343633] from MODIFIED to ON_QA > :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-6680 > URL: https://issues.jboss.org/browse/WFLY-6680 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch, > Reporter: Kristina Clair > Assignee: Radoslav Husar > Labels: downstream_dependency > Fix For: 10.1.0.CR1, 10.1.0.Final > > > When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error. > On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error. This is the output from the application host: > {noformat} > [domain@localhost:9999 subsystem=modcluster] pwd > /host=localhost/server=cluster2/subsystem=modcluster > [domain@localhost:9999 subsystem=modcluster] :list-proxies > { > "outcome" => "success", > "result" => [ > "web02:8009", > "web01:8009" > ] > } > [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS014749: Operation handler failed: newValue is null", > "rolled-back" => true > } > [domain@localhost:9999 subsystem=modcluster] :read-proxies-info > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS014749: Operation handler failed: newValue is null", > "rolled-back" => true > } > {noformat} > In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7034) JDR is not collecting the file .overlays, layer.conf, version.txt config files

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7034?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7034: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1372781|https://bugzilla.redhat.com/show_bug.cgi?id=1372781] from MODIFIED to ON_QA > JDR is not collecting the file .overlays, layer.conf, version.txt config files > ------------------------------------------------------------------------------ > > Key: WFLY-7034 > URL: https://issues.jboss.org/browse/WFLY-7034 > Project: WildFly > Issue Type: Bug > Components: JDR > Affects Versions: 10.1.0.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Priority: Minor > Fix For: 11.0.0.Alpha1 > > > The JDR report when collecting files should be collecting > $JBOSS_HOME/modules/system/layers/base/.overlays/.overlays > $JBOSS_HOME/.installation/identity.conf > $JBOSS_HOME/.installation/layers/base/layer.conf > $JBOSS_HOME/.installation/patches/*/misc/version.txt > This file is needed to confirm overlay priority and other layer configurations to make sure the installation is not corrupted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1164) Warning about private module use issued twice

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1164?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1164: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1365668|https://bugzilla.redhat.com/show_bug.cgi?id=1365668] from MODIFIED to ON_QA > Warning about private module use issued twice > --------------------------------------------- > > Key: WFCORE-1164 > URL: https://issues.jboss.org/browse/WFCORE-1164 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Frank Langelage > Assignee: Stuart Douglas > Priority: Minor > Fix For: 2.0.4.Final > > Attachments: test.war > > > My web app is using some modules of WildFly AS which are not public. > The warning about using private modules is issued twice for every module: > 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6626) Add log message indicating disabled <distributable/> flag from web-fragments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6626?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6626: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1337858|https://bugzilla.redhat.com/show_bug.cgi?id=1337858] from MODIFIED to ON_QA > Add log message indicating disabled <distributable/> flag from web-fragments > ---------------------------------------------------------------------------- > > Key: WFLY-6626 > URL: https://issues.jboss.org/browse/WFLY-6626 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Aaron Ogburn > Assignee: Stuart Douglas > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: undistributable.war > > > If a web-fragment doesn't have distributable set, then replication is not enabled. This happens silently so it may be confusing to some users that are expecting replication to be enabled when they have set <distributable/> in their WEB-INF/web.xml. > Other third party libraries they included may have web-fragments without distributable set so it'd be nice to log a notification when this happens so that users are easily informed why replication was not enabled as they may have expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1316) patch apply command not working as expected in non-interactive mode in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1316?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1316: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1290290|https://bugzilla.redhat.com/show_bug.cgi?id=1290290] from MODIFIED to ON_QA > patch apply command not working as expected in non-interactive mode in domain mode > ----------------------------------------------------------------------------------- > > Key: WFCORE-1316 > URL: https://issues.jboss.org/browse/WFCORE-1316 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > Fix For: 2.0.8.Final > > > CLI patch apply command is misleading when the --host option is used. In non-interactive mode applies the patch to the local installation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5499) Channel end notification received, closing channel ... should be logged at debug in EjbLogger

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5499?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5499: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1271538|https://bugzilla.redhat.com/show_bug.cgi?id=1271538] from MODIFIED to ON_QA > Channel end notification received, closing channel ... should be logged at debug in EjbLogger > --------------------------------------------------------------------------------------------- > > Key: WFLY-5499 > URL: https://issues.jboss.org/browse/WFLY-5499 > Project: WildFly > Issue Type: Bug > Components: EJB, Naming > Reporter: Takayuki Konishi > > Remote naming is logging this at ERROR, though it seems normal and no adverse effects are apparent, we should log it at debug instead of error. > {code} > ERROR [org.jboss.as.ejb3] (Remoting "master@ap02:server-apip" task-2) JBAS014141: Channel end notification received, closing channel Channel ID 6b8f00d7 (inbound) of Remoting connection 36e4f81b to /192.168.1.10:64354 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-591) revertReloadRequired() throws a NPE is reloadRequired has not been called

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-591?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-591: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1294591|https://bugzilla.redhat.com/show_bug.cgi?id=1294591] from MODIFIED to ON_QA > revertReloadRequired() throws a NPE is reloadRequired has not been called > ------------------------------------------------------------------------- > > Key: WFCORE-591 > URL: https://issues.jboss.org/browse/WFCORE-591 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 1.0.0.Beta1 > > > If an operation step handler calls org.jboss.as.controller.OperationContext#revertReloadRequired() when org.jboss.as.controller.OperationContext#reloadRequired() has not been called, it throws a NPE: > {noformat} > java.lang.NullPointerException > at org.jboss.as.controller.ControlledProcessState.revertReloadRequired(ControlledProcessState.java:181) > at org.jboss.as.controller.AbstractOperationContext.revertReloadRequired(AbstractOperationContext.java:1037) > at org.jboss.as.controller.test.RevertReloadRequiredTestCase$TestResourceAddHandler.rollbackRuntime(RevertReloadRequiredTestCase.java:98) > at org.jboss.as.controller.AbstractAddStepHandler$1$1.handleRollback(AbstractAddStepHandler.java:133) > at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1419) > at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1385) > at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1367) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1323) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1283) > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1172) > at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:929) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1182) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205) > {noformat} > The NPE is caused by this.activeStep.restartStamp field which is set only when reloadRequired() (or restartRequired()) is called. > My OSH may call reloadRequired() or not depending on some runtime state and I could add some logic to make sure I call > I can fix my handle to check that I call context.revertReloadRequired() only I had previously called reloadRequired () first. > However, in order to make the OperationContext more robust, I think that the revertReloadRequired() method should instead be a no-op if there is no reload required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7193) No log messages comming from Elytron - ssl context creation

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6158 to WFLY-7193: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7193 (was: JBEAP-6158) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR5) > No log messages comming from Elytron - ssl context creation > ----------------------------------------------------------- > > Key: WFLY-7193 > URL: https://issues.jboss.org/browse/WFLY-7193 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > > Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details. > Seems to me it would be useful for troubleshooting to have logged on TRACE level: > - Keystore initialization with parameters > - Filtering keystore initialization with parameters > - KeyManager / TrustManager initialization with parameters > - Client / Server SSLContext initialization with parameters -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1257) support query filter implementation in MBeanServerConnection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1257?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1257: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1294010|https://bugzilla.redhat.com/show_bug.cgi?id=1294010] from MODIFIED to ON_QA > support query filter implementation in MBeanServerConnection > ------------------------------------------------------------ > > Key: WFCORE-1257 > URL: https://issues.jboss.org/browse/WFCORE-1257 > Project: WildFly Core > Issue Type: Bug > Components: JMX > Affects Versions: 2.0.5.Final > Reporter: Chao Wang > Assignee: Brian Stansberry > Fix For: 2.0.8.Final > > > There is no implementation for query filter in MBeanServerConnection, marked as TODO > {code:title=ModelControllerMBeanHelper.java|borderStyle=solid} > Set<ObjectName> queryNames(final ObjectName name, final QueryExp query) { > return new RootResourceIterator<Set<ObjectName>>(accessControlUtil, getRootResourceAndRegistration().getResource(), > new ObjectNameMatchResourceAction<Set<ObjectName>>(name) { > Set<ObjectName> set = new HashSet<ObjectName>(); > @Override > public boolean onResource(ObjectName resourceName) { > if (name == null || name.apply(resourceName)) { > //TODO check query > set.add(resourceName); > } > return true; > } > @Override > public Set<ObjectName> getResult() { > if (set.size() == 1 && set.contains(ModelControllerMBeanHelper.createRootObjectName(domain))) { > return Collections.emptySet(); > } > return set; > } > }).iterate(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1303) OOPath reactive Collection coverage

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1303: -------------------------------------- Summary: OOPath reactive Collection coverage Key: DROOLS-1303 URL: https://issues.jboss.org/browse/DROOLS-1303 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 6.5.0.CR2 Reporter: Matteo Mortari Assignee: Matteo Mortari * proper coverage for all methods of java.util.Collection e.g.: addAll() -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1332) Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1332?page=com.atlassian.jira.plugi... ] Ivo Studensky reassigned WFCORE-1332: ------------------------------------- Assignee: Ivo Studensky (was: Darran Lofthouse) > Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1332 > URL: https://issues.jboss.org/browse/WFCORE-1332 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.7.Final > Reporter: Ondrej Lukas > Assignee: Ivo Studensky > > In case when crossRef object to different domain is configured on MS Active Directory for handling referrals and JBoss EAP 7 uses ldap authentication to mgmt console with configured referrals 'throw' then authentication fails for referral users. It is inconsistent with behavior of EAP with another LDAP providers (e.g. Red Hat Directory Server). In correct behavior authentication should pass. > It seems it is caused by thrown LdapReferralException search method of org.jboss.as.domain.management.security.LdapUserSearcherFactory.LdapUserSearcherImpl before it is handled by try-catch block. Stack trace of thrown LdapReferralException: > com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2975) > com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) > com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1846) > com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) > com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786) > com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418) > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396) > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:378) > javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286) > javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286) > org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125) > org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66) > org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) > org.jboss.as.domain.management.security.UserLdapCallbackHandler$LdapCallbackHandler.handle(UserLdapCallbackHandler.java:205) > org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:178) > org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162) > org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141) > io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118) > org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52) > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112

by Steve Ebersole (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Steve Ebersole commented on JASSIST-261: ---------------------------------------- [~smarlow] - Do I understand that proposal properly that for a persistence unit (module) it would the application's responsibility to define its module as "privately" exporting these classes? > Issue with javassist on jdk 9b112 > --------------------------------- > > Key: JASSIST-261 > URL: https://issues.jboss.org/browse/JASSIST-261 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Environment: Javassist with jdk 9b112 > Reporter: Hoang Chuong Tran > Assignee: Shigeru Chiba > > I am migrating a project to java 9, which also uses javassist to generate runtime code. > One test of mine fails on jdk 9b112 while it passes on jdk 8u77. > {noformat} > import static javassist.CtClass.voidType; > import java.lang.reflect.Method; > import java.lang.reflect.Modifier; > import java.util.HashMap; > import java.util.Map; > import org.junit.Test; > import javassist.ClassClassPath; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtField; > import javassist.CtMethod; > import javassist.CtNewMethod; > public class MyTests { > public static class MyObject { > protected Object field; > Object getField() {return field;} > public void setField(Object field) {} > } > @Test > public void test() throws InstantiationException, IllegalAccessException { > Class<? extends MyObject> clazz = compile(MyObject.class); > clazz.newInstance().setField(null); > } > /** Compile a transfer class */ > public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) { > // Determine class setters > Map<String, Method> setters = extractSetters(targetClass); > ClassPool classPool = ClassPool.getDefault(); > classPool.insertClassPath(new ClassClassPath(targetClass)); > try { > // Compile a new transfer class on the fly > CtClass baseClass = classPool.get(MyObject.class.getName()); > CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass); > for(Method originalSetter : setters.values()) { > // Create a field to hold the attribute > Class<?> fieldClass = originalSetter.getParameterTypes()[0]; > CtClass fieldType = classPool.get(fieldClass.getName()); > String fieldName = originalSetter.getName().substring(3); > CtField field = new CtField(fieldType, fieldName, proxyClass); > proxyClass.addField(field); > // Create a setter method to set that field > CtClass[] parameters = new CtClass[] { fieldType }; > String setterBody = "{ System.out.println(\"Hello World\"); }"; > CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass); > proxyClass.addMethod(setter); > } > Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain()); > return javaClass; > } catch(Exception e) { > throw new RuntimeException("Failure during transfer compilation for " + targetClass, e); > } > } > /** Extract setter methods from a class */ > public static Map<String, Method> extractSetters(Class<?> cls) { > Map<String, Method> setters = new HashMap<String, Method>(); > for(Method method : cls.getMethods()) { > // Lookup setter methods > if(method.getName().startsWith("set")) { > // Only public setters > int modifiers = method.getModifiers(); > if(Modifier.isPublic(modifiers)) { > Class<?>[] exceptions = method.getExceptionTypes(); > Class<?>[] parameters = method.getParameterTypes(); > Class<?> returnType = method.getReturnType(); > if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) { > setters.put(method.getName(), method); > } > } > } > } > return setters; > } > } > {noformat} > On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. > On jdk 9b112, I got the following exception > {noformat} > java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject > at MyTests.compile(MyTests.java:68) > at MyTests.test(MyTests.java:29) > at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: javassist.NotFoundException: java.lang.Object > at javassist.ClassPool.get(ClassPool.java:450) > at MyTests.compile(MyTests.java:51) > ... 24 more > {noformat} > I suspect that is due to the jigsaw integration into the jdk. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2098: -------------------------------- The downside of only coordinators responding to discovery requests is that initial startup of multiple members will inevitable lead to a merge: when A, B and C are started as first members of a cluster, none of them will respond to the others' discovery requests and thus we end up with 3 singleton clusters, which need to be merged into one. If everybody replied, then everyone would see A, B and C as clients, and they would enact a quick-and-dirty coord election scheme; essentially sorting the list and picking the first to be coordinator. > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2098 at 9/22/16 7:56 AM: --------------------------------------------------------- To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. *When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}*. (Perhaps the discovery protocol could query attribute {{TP.use_ip_addrs}} and use it instead, so we don't have to introduce another attribute). In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to. was (Author: belaban): To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}. (Perhaps the discovery protocol could query attribute {{TP.use_ip_addrs}} and use it instead, so we don't have to introduce another attribute). In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to. > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7120) NPE in SessionManagerStatsHandler

by Mathieu Lachance (JIRA)

[ https://issues.jboss.org/browse/WFLY-7120?page=com.atlassian.jira.plugin.... ] Mathieu Lachance reopened WFLY-7120: ------------------------------------ Assignee: Brian Stansberry (was: Mathieu Lachance) I just got another NPE, I've created another pull request. > NPE in SessionManagerStatsHandler > --------------------------------- > > Key: WFLY-7120 > URL: https://issues.jboss.org/browse/WFLY-7120 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 11.0.0.Alpha1 > > > [~matlach] reports an NPE when SessionManagerStatsHandler tries to use the ServiceController for a no-longer present deployment. See https://github.com/wildfly/wildfly/pull/9189 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7120) NPE in SessionManagerStatsHandler

by Mathieu Lachance (JIRA)

[ https://issues.jboss.org/browse/WFLY-7120?page=com.atlassian.jira.plugin.... ] Mathieu Lachance edited comment on WFLY-7120 at 9/22/16 7:51 AM: ----------------------------------------------------------------- I just got another NPE, I've created another pull request. https://github.com/wildfly/wildfly/pull/9214 was (Author: matlach): I just got another NPE, I've created another pull request. > NPE in SessionManagerStatsHandler > --------------------------------- > > Key: WFLY-7120 > URL: https://issues.jboss.org/browse/WFLY-7120 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 11.0.0.Alpha1 > > > [~matlach] reports an NPE when SessionManagerStatsHandler tries to use the ServiceController for a no-longer present deployment. See https://github.com/wildfly/wildfly/pull/9189 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7153) Inconsistency of resources *-ssl-context in model vs. XSD

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7153?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7153: -------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Inconsistency of resources *-ssl-context in model vs. XSD > --------------------------------------------------------- > > Key: WFLY-7153 > URL: https://issues.jboss.org/browse/WFLY-7153 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > * in client-ssl-context there is attribute {{security-domain}} in XSD, which is not in model. In case of client-ssl-context this probably does not make sense and reaaly should't be in XSD, neither. > * in both *-ssl-context there is provider in XSD and provider-loader in model. Sync it please. Probably possibility to specify both could be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1257) support query filter implementation in MBeanServerConnection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1257?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1257: ------------------------------------------------- Vlado Pakan <vpakan(a)redhat.com> changed the Status of [bug 1294010|https://bugzilla.redhat.com/show_bug.cgi?id=1294010] from POST to MODIFIED > support query filter implementation in MBeanServerConnection > ------------------------------------------------------------ > > Key: WFCORE-1257 > URL: https://issues.jboss.org/browse/WFCORE-1257 > Project: WildFly Core > Issue Type: Bug > Components: JMX > Affects Versions: 2.0.5.Final > Reporter: Chao Wang > Assignee: Brian Stansberry > Fix For: 2.0.8.Final > > > There is no implementation for query filter in MBeanServerConnection, marked as TODO > {code:title=ModelControllerMBeanHelper.java|borderStyle=solid} > Set<ObjectName> queryNames(final ObjectName name, final QueryExp query) { > return new RootResourceIterator<Set<ObjectName>>(accessControlUtil, getRootResourceAndRegistration().getResource(), > new ObjectNameMatchResourceAction<Set<ObjectName>>(name) { > Set<ObjectName> set = new HashSet<ObjectName>(); > @Override > public boolean onResource(ObjectName resourceName) { > if (name == null || name.apply(resourceName)) { > //TODO check query > set.add(resourceName); > } > return true; > } > @Override > public Set<ObjectName> getResult() { > if (set.size() == 1 && set.contains(ModelControllerMBeanHelper.createRootObjectName(domain))) { > return Collections.emptySet(); > } > return set; > } > }).iterate(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-638) Add support for hashed usernames.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-638: ------------------------------------ Summary: Add support for hashed usernames. Key: ELY-638 URL: https://issues.jboss.org/browse/ELY-638 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI Reporter: Darran Lofthouse Fix For: 2.0.0.Alpha1 The latest HTTP Digest RFC https://datatracker.ietf.org/doc/rfc7616/ adds support for hashed usernames. https://tools.ietf.org/html/rfc7616#page-12 Passing in this hash within the name field of IdentityLocator may be suitable for a realm to map - alternatively NameRewriters and RealmMappers may be needed to handle some of this, or IdentityLocator could be extended to add fields for hashed username and algorithm. Or other options. Have scheduled for Elytron 2 as this is a new optional part of the RFC. It may turn out to be a feature of a mech never used but general support for an alternative form of a username like this sounds reasonable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-638) Add support for hashed usernames.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-638?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-638: --------------------------------- Component/s: HTTP > Add support for hashed usernames. > --------------------------------- > > Key: ELY-638 > URL: https://issues.jboss.org/browse/ELY-638 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, HTTP > Reporter: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > The latest HTTP Digest RFC https://datatracker.ietf.org/doc/rfc7616/ adds support for hashed usernames. > https://tools.ietf.org/html/rfc7616#page-12 > Passing in this hash within the name field of IdentityLocator may be suitable for a realm to map - alternatively NameRewriters and RealmMappers may be needed to handle some of this, or IdentityLocator could be extended to add fields for hashed username and algorithm. Or other options. > Have scheduled for Elytron 2 as this is a new optional part of the RFC. It may turn out to be a feature of a mech never used but general support for an alternative form of a username like this sounds reasonable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1302) OOPath ReactiveList remove cases

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1302: -------------------------------------- Summary: OOPath ReactiveList remove cases Key: DROOLS-1302 URL: https://issues.jboss.org/browse/DROOLS-1302 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.CR2 Reporter: Matteo Mortari Assignee: Matteo Mortari Priority: Minor * Removing element from ReactiveList is not covered * Ensure removing from 1 out of many ReactiveList does affect only the relevant lists when issuing modification to a ReactiveObject -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5499) Channel end notification received, closing channel ... should be logged at debug in EjbLogger

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5499?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5499: ----------------------------------------------- Vlado Pakan <vpakan(a)redhat.com> changed the Status of [bug 1271538|https://bugzilla.redhat.com/show_bug.cgi?id=1271538] from POST to MODIFIED > Channel end notification received, closing channel ... should be logged at debug in EjbLogger > --------------------------------------------------------------------------------------------- > > Key: WFLY-5499 > URL: https://issues.jboss.org/browse/WFLY-5499 > Project: WildFly > Issue Type: Bug > Components: EJB, Naming > Reporter: Takayuki Konishi > > Remote naming is logging this at ERROR, though it seems normal and no adverse effects are apparent, we should log it at debug instead of error. > {code} > ERROR [org.jboss.as.ejb3] (Remoting "master@ap02:server-apip" task-2) JBAS014141: Channel end notification received, closing channel Channel ID 6b8f00d7 (inbound) of Remoting connection 36e4f81b to /192.168.1.10:64354 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1730) Singleton service is not correctly being set in WILDFLY

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1730?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1730: ------------------------------------------------- Vlado Pakan <vpakan(a)redhat.com> changed the Status of [bug 1367793|https://bugzilla.redhat.com/show_bug.cgi?id=1367793] from POST to MODIFIED > Singleton service is not correctly being set in WILDFLY > ------------------------------------------------------- > > Key: WFCORE-1730 > URL: https://issues.jboss.org/browse/WFCORE-1730 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 3.0.0.Alpha5 > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > WILDFLY doesn't call ServiceLoader (META-INF/services/org.jboss.msc.service.ServiceActivator) when it is deployed in EAR/lib. The SingletonService (not a singleton EJB) is activated in the ServiceLoader so the SingletonService hasn't been activated from the first. It works as expected when deployed as an EJB (not in EAR/lib). > When the ServiceLoader is called, a message of "HATimerService will be installed!" is logged and the SingletonService will be activated. > $ fgrep -e HATimerService -e '[org.jboss.as.clustering.singleton]' domain/servers/server-one/log/server.log > 12:14:52,373 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator] (MSC service thread 1-7) HATimerService will be installed! > 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service > 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010340: This node will now operate as the singleton provider of the jboss.quickstart.ha.singleton.timer service > 12:14:56,268 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerService] (MSC service thread 1-8) Start HASingleton timer service 'org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATim > erService' > 12:14:56,873 INFO [org.jboss.as.clustering.singleton] (notification-thread-0) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3639) default-web-module doesn't work for non default hosts & servers

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3639?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3639: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/8953 (was: https://github.com/wildfly/wildfly/pull/8422) > default-web-module doesn't work for non default hosts & servers > --------------------------------------------------------------- > > Key: WFLY-3639 > URL: https://issues.jboss.org/browse/WFLY-3639 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > If you use config like this: > {code:xml} > <host name="default-host" default-web-module="myapp1.war" alias="webapp.domain1.com"/> > <host name="other-host" default-web-module="myapp2.war" alias="test.domain2.net"/> > {code} > and have apps myapp1.war & myapp2.war deployed myappwar2.war won't be bind to other-host. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1814) Move to woodstox 5.x

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-1814: ----------------------------------- Summary: Move to woodstox 5.x Key: WFCORE-1814 URL: https://issues.jboss.org/browse/WFCORE-1814 Project: WildFly Core Issue Type: Task Components: XML Frameworks Affects Versions: 3.0.0.Alpha8 Reporter: Tomaz Cerar Assignee: Tomaz Cerar Woodstox has moved to new home and is now better maintained. https://github.com/FasterXML/woodstox Version 5.0.1 was the first build from new repo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7192) 'name' attribute missing in XSD while required by web subsystem parser

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFLY-7192?page=com.atlassian.jira.plugin.... ] Peter Palaga moved JBEAP-6153 to WFLY-7192: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7192 (was: JBEAP-6153) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Web (JBoss Web)) > 'name' attribute missing in XSD while required by web subsystem parser > ---------------------------------------------------------------------- > > Key: WFLY-7192 > URL: https://issues.jboss.org/browse/WFLY-7192 > Project: WildFly > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > Labels: downstream_dependency > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1365939 , originaly reported by [~paramjindal] > While configuring the global valve using the following article : > https://access.redhat.com/solutions/379813 > It is mandatory that the "name" attribute of valve must match the "auth-method" that is specified in the "WEB-INF/web.xml". > So "name" attribute is mandatory to configure this valve. > but it is not mentioned in the schema of valve as shown below : > {code:xml} > <xs:element name="valve"> > <xs:complexType> > <xs:sequence> > <xs:element name="param" minOccurs="0" maxOccurs="unbounded" type="paramType" /> > </xs:sequence> > <xs:attribute name="class-name" type="xs:string" use="required" /> > <xs:attribute name="module" type="xs:string" use="required" /> > <xs:attribute name="enabled" default="true" type="xs:boolean" /> > </xs:complexType> > </xs:element> > {code} > Version-Release number of selected component (if applicable): -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-631: -------------------------------------- [~honza889] Could you please take a look into this one? Should be a small fix. > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: ELY-631 > URL: https://issues.jboss.org/browse/ELY-631 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-631: ------------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: ELY-631 > URL: https://issues.jboss.org/browse/ELY-631 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7191) alias-filter of filtering-key-store should be required in model

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7191?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFLY-7191: ------------------------------- Description: {{alias-filter}} attribute of filtering-key-store should be required in model Elytron doesn't allow null value of {{alias-filter}} attribute of resource filtering-key-store. If I try to create filtering-key-store withou alias-filter I get: {code} [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=fks:add(key-store=server) { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null Caused by: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null"}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"], "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined }, "rolled-back" => true } {code} So, {{alias-filter}} can be also defined in model as required, it means {{"nillable" => false}}. Now it is: {code} "alias-filter" => { "type" => STRING, "description" => "A filter to apply to the aliases returned from the KeyStore, can either be a comma separated list of aliases to return or one of the following formats ALL:-alias1:-alias2, NONE:+alias1:+alias2", "expressions-allowed" => true, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, {code} was: alias-filter of filtering-key-store should be required in model Elytron doesn't allow null value of {{alias-filter}} attribute of resource filtering-key-store. If I try to create filtering-key-store withou alias-filter I get: {code} [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=fks:add(key-store=server) { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null Caused by: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null"}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"], "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined }, "rolled-back" => true } {code} So, {{alias-filter}} can be also defined in model as required, it means {{"nillable" => false}}. Now it is: {code} "alias-filter" => { "type" => STRING, "description" => "A filter to apply to the aliases returned from the KeyStore, can either be a comma separated list of aliases to return or one of the following formats ALL:-alias1:-alias2, NONE:+alias1:+alias2", "expressions-allowed" => true, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, {code} > alias-filter of filtering-key-store should be required in model > --------------------------------------------------------------- > > Key: WFLY-7191 > URL: https://issues.jboss.org/browse/WFLY-7191 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Optional > > {{alias-filter}} attribute of filtering-key-store should be required in model > Elytron doesn't allow null value of {{alias-filter}} attribute of resource filtering-key-store. If I try to create filtering-key-store withou alias-filter I get: > {code} > [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=fks:add(key-store=server) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null > Caused by: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > So, {{alias-filter}} can be also defined in model as required, it means {{"nillable" => false}}. Now it is: > {code} > "alias-filter" => { > "type" => STRING, > "description" => "A filter to apply to the aliases returned from the KeyStore, can either be a comma separated list of aliases to return or one of the following formats ALL:-alias1:-alias2, NONE:+alias1:+alias2", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-637) No log messages comming from Elytron - permission assignment

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-637?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-637: ----------------------------- Affects Version/s: 1.1.0.Beta9 > No log messages comming from Elytron - permission assignment > ------------------------------------------------------------ > > Key: ELY-637 > URL: https://issues.jboss.org/browse/ELY-637 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron is missing any log messages related to permission assignment. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7191) alias-filter of filtering-key-store should be required in model

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7191?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6152 to WFLY-7191: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7191 (was: JBEAP-6152) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR5) > alias-filter of filtering-key-store should be required in model > --------------------------------------------------------------- > > Key: WFLY-7191 > URL: https://issues.jboss.org/browse/WFLY-7191 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Optional > > alias-filter of filtering-key-store should be required in model > Elytron doesn't allow null value of {{alias-filter}} attribute of resource filtering-key-store. If I try to create filtering-key-store withou alias-filter I get: > {code} > [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=fks:add(key-store=server) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null > Caused by: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > So, {{alias-filter}} can be also defined in model as required, it means {{"nillable" => false}}. Now it is: > {code} > "alias-filter" => { > "type" => STRING, > "description" => "A filter to apply to the aliases returned from the KeyStore, can either be a comma separated list of aliases to return or one of the following formats ALL:-alias1:-alias2, NONE:+alias1:+alias2", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-637) No log messages comming from Elytron - permission assignment

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-637: -------------------------------- Summary: No log messages comming from Elytron - permission assignment Key: ELY-637 URL: https://issues.jboss.org/browse/ELY-637 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron is missing any log messages related to permission assignment. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-636) No log messages comming from Elytron - principal mapping

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-636?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-636: ----------------------------- Affects Version/s: 1.1.0.Beta9 > No log messages comming from Elytron - principal mapping > -------------------------------------------------------- > > Key: ELY-636 > URL: https://issues.jboss.org/browse/ELY-636 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron is missing any log messages related to principal mapping. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-636) No log messages comming from Elytron - principal mapping

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-636: -------------------------------- Summary: No log messages comming from Elytron - principal mapping Key: ELY-636 URL: https://issues.jboss.org/browse/ELY-636 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron is missing any log messages related to principal mapping. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-635) No log messages comming from Elytron - role mapping

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-635?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-635: ----------------------------- Affects Version/s: 1.1.0.Beta9 > No log messages comming from Elytron - role mapping > --------------------------------------------------- > > Key: ELY-635 > URL: https://issues.jboss.org/browse/ELY-635 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron is missing any log messages related to role mapping. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-635) No log messages comming from Elytron - role mapping

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-635: -------------------------------- Summary: No log messages comming from Elytron - role mapping Key: ELY-635 URL: https://issues.jboss.org/browse/ELY-635 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron is missing any log messages related to role mapping. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-634) No log messages comming from Elytron - group assignment

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-634: -------------------------------- Summary: No log messages comming from Elytron - group assignment Key: ELY-634 URL: https://issues.jboss.org/browse/ELY-634 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron is missing any log messages related to group assignment. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-634) No log messages comming from Elytron - group assignment

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-634?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-634: ----------------------------- Affects Version/s: 1.1.0.Beta9 > No log messages comming from Elytron - group assignment > ------------------------------------------------------- > > Key: ELY-634 > URL: https://issues.jboss.org/browse/ELY-634 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron is missing any log messages related to group assignment. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-633) No log messages comming from Elytron - password verification

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-633: -------------------------------- Summary: No log messages comming from Elytron - password verification Key: ELY-633 URL: https://issues.jboss.org/browse/ELY-633 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron is missing any log messages related to password verification. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-633) No log messages comming from Elytron - password verification

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-633?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-633: ----------------------------- Affects Version/s: 1.1.0.Beta9 > No log messages comming from Elytron - password verification > ------------------------------------------------------------ > > Key: ELY-633 > URL: https://issues.jboss.org/browse/ELY-633 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron is missing any log messages related to password verification. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-632) No log messages comming from Elytron - authentication process start

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-632: -------------------------------- Summary: No log messages comming from Elytron - authentication process start Key: ELY-632 URL: https://issues.jboss.org/browse/ELY-632 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Elytron is missing any log messages related to starting authentication process. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-632) No log messages comming from Elytron - authentication process start

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-632?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-632: ----------------------------- Affects Version/s: 1.1.0.Beta9 > No log messages comming from Elytron - authentication process start > ------------------------------------------------------------------- > > Key: ELY-632 > URL: https://issues.jboss.org/browse/ELY-632 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Elytron is missing any log messages related to starting authentication process. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7149) Unable to remove elytron subsystem with defined properties-realm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7149?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7149: -------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Unable to remove elytron subsystem with defined properties-realm > ---------------------------------------------------------------- > > Key: WFLY-7149 > URL: https://issues.jboss.org/browse/WFLY-7149 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Radim Hatlapatka > Assignee: Jan Kalina > Priority: Critical > > When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies \[1\]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove. > \[1\] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security > Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-631: ----------------------------- Affects Version/s: 1.1.0.Beta9 > Wrong description of missing target-name in simple-permission-mapper > -------------------------------------------------------------------- > > Key: ELY-631 > URL: https://issues.jboss.org/browse/ELY-631 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-631: -------------------------------- Summary: Wrong description of missing target-name in simple-permission-mapper Key: ELY-631 URL: https://issues.jboss.org/browse/ELY-631 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1813) Command-timeout element is not described in CLI schema

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1813?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1813: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1821 > Command-timeout element is not described in CLI schema > ------------------------------------------------------ > > Key: WFCORE-1813 > URL: https://issues.jboss.org/browse/WFCORE-1813 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > <command-timeout> element of jboss-cli.xml is not described in CLI schema. Current schema for jboss-cli.xml is here: EAP_HOME/docs/schema/wildfly-cli_3_1.xsd -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1813) Command-timeout element is not described in CLI schema

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1813?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1813: ----------------------------------------- Description: <command-timeout> element of jboss-cli.xml is not described in CLI schema. Current schema for jboss-cli.xml is here: EAP_HOME/docs/schema/wildfly-cli_3_1.xsd > Command-timeout element is not described in CLI schema > ------------------------------------------------------ > > Key: WFCORE-1813 > URL: https://issues.jboss.org/browse/WFCORE-1813 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > <command-timeout> element of jboss-cli.xml is not described in CLI schema. Current schema for jboss-cli.xml is here: EAP_HOME/docs/schema/wildfly-cli_3_1.xsd -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1813) Command-timeout element is not described in CLI schema

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1813: -------------------------------------------- Summary: Command-timeout element is not described in CLI schema Key: WFCORE-1813 URL: https://issues.jboss.org/browse/WFCORE-1813 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7162) Elytron filtering-key-store:write-attribute cause NPE

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7162?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7162: -------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Elytron filtering-key-store:write-attribute cause NPE > ----------------------------------------------------- > > Key: WFLY-7162 > URL: https://issues.jboss.org/browse/WFLY-7162 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > Trying to update filtering-key-store cause NPE > {code} > [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=filteringKeyStore:add(key-store=server, alias-filter=undertow) > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=filteringKeyStore:write-attribute(name=alias-filter,value=management) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException", > "rolled-back" => true > } > {code} > Stacktrace: > {code} > 09:51:45,250 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0013: Operation ("write-attribute") failed - address: ([ > ("subsystem" => "elytron"), > ("filtering-key-store" => "filteringKeyStore") > ]): java.lang.NullPointerException > at org.wildfly.extension.elytron.FilteringKeyStoreDefinition$WriteAttributeHandler.getParentServiceName(FilteringKeyStoreDefinition.java:174) > at org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:57) > at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > 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 message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7152) Activate CDI request context during concurrency utilities task execution

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-7152?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-7152: ------------------------------- Summary: Activate CDI request context during concurrency utilities task execution (was: Activate CDI request context during task execution) > Activate CDI request context during concurrency utilities task execution > ------------------------------------------------------------------------ > > Key: WFLY-7152 > URL: https://issues.jboss.org/browse/WFLY-7152 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, EE > Reporter: Martin Kouba > Assignee: David Lloyd > > This is not required by any spec (CDI, Concurrency Utilities for Java EE). But it might be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2080 at 9/22/16 2:27 AM: --------------------------------------------------------- I'm starting to have second thoughts on {{IpAddressUUID}}... :-( Looking at the size of an instance (using JOL), we have * 32 bytes for {{IpAddressUUID}} * 24 bytes for {{Inet4Address}} * 32 bytes for {{InetAddressHolder}} and {{InetAddress6Holder}} each * 32 bytes for {{Inet6Address}} This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses. I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 24 bytes (16 address, 4 port and 4 scope-id) for IPv6 addresses... That would use *40 bytes for an IPv4 address* and *56 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}. The downside is that we have to create a new instance of {{Inet4Address}} or {{Inet6Address}} every time we need to send a unicast message, by extracting the address and port from the UUID. was (Author: belaban): I'm starting to have second thoughts on {{IpAddressUUID}}... :-( Looking at the size of an instance (using JOL), we have * 32 bytes for {{IpAddressUUID}} * 24 bytes for {{Inet4Address}} * 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each * 32 bytes for {{Inet6Address}} This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses. I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses... That would use *40 bytes for an IPv4 address* and *48 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}. The downside is that we have to create a new instance of {{Inet4Address}} or {{Inet6Address}} every time we need to send a unicast message, by extracting the address and port from the UUID. > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2098 at 9/22/16 2:08 AM: --------------------------------------------------------- To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}. (Perhaps the discovery protocol could query attribute {{TP.use_ip_addrs}} and use it instead, so we don't have to introduce another attribute). In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to. was (Author: belaban): To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}. In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to. > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2098: -------------------------------- To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}. In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to. > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2098 at 9/22/16 2:02 AM: --------------------------------------------------------- We could place {{NAMING}} over {{NAKACK2}} / {{UNICAST3}}, so we don't have to implement our own reliability. To make things simple, the name cache would be populated as follows: * The joiner sends its address-name mapping to everyone after having joined successfully * The joiner gets the full name cache from the coordintor, or - alternatively - everyone sends its name to the joiner after the new view has been installed At the time the coordinator receives the JOIN(P) request, P's logical name would not be known yet, but we could (for example) simply print the IP address:port of IpAddressUUID if the logical name is not known. After the protocol skteched out above has run, logical names would be available and used to print IpAddressUUIDs. was (Author: belaban): We could place {{NAMING}} over {{NAKACK2}} / {{UNICAST3}}, so we don't have to implement our own reliability. To make things simple, the name cache would be populated as follows: * The joiner sends its address-name mapping to everyone after having joined successfully * The joiner gets the full name cache from the coordintor, or - alternatively - everyone sends its name to the joiner after the new view has been installed > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2098: -------------------------------- We could place {{NAMING}} over {{NAKACK2}} / {{UNICAST3}}, so we don't have to implement our own reliability. To make things simple, the name cache would be populated as follows: * The joiner sends its address-name mapping to everyone after having joined successfully * The joiner gets the full name cache from the coordintor, or - alternatively - everyone sends its name to the joiner after the new view has been installed > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2098 at 9/22/16 1:47 AM: --------------------------------------------------------- Hmm, a separate {{NAMING}} protocol might be difficult to write... When a member P joins, it runs the discovery protocol to (1) find the coordinator and (2) populate its (name and address mapping) caches. Coordinator Q can log the logical name of P when receiving a JOIN(P) request, as the previous discovery phase made the logical name of P known to Q. However, with a separate {{NAMING}} protocol, the logical name of P would somehow have to be shipped to Q separately. Piggy-backing on the discovery protocol entails {{NAMING}} having to intercept all messages and piggybacking on {{GET_MBRS_REQ}} and {{GET_MBRS_RSP}}. However, this slows things down as these message make up only a small part of the overall messages, but we have to inspect *every single message*! The naming cache would have to be populated via each member sending its name to a joiner, or the joiner fetching the 'state' from the coordinator. Since {{NAMING}} would sit below the discovery protocol, it is not reliable, so this would have to be done multiple times, or we'd have to use some homegrown reliability by e.g. resending the name until it has been acked yada yada yada... Not nice... was (Author: belaban): Hmm, a separate {{NAMING}} protocol might be difficult to write... When a member P joins, it runs the discovery protocol to (1) find the coordinator and (2) populate its (name and address mapping) caches. Coordinator Q can log the logical name of P when receiving a JOIN(P) request, as the previous discovery phase made the logical name of P known to Q. However, with a separate {{NAMING}} protocol, the logical name of P would somehow have to be shipped to Q separately. Piggy-backing on the discovery protocol entails {{NAMING}} having to intercept all messages and piggybacking on {{GET_MBRS_REQ}} and {{GET_MBRS_RSP}}. However, this slows things down as these message make up only a small part of the overall messages, but we have to inspect *every single message*! > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7190) Group related resources in Elytron subsystem

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7190: ---------------------------------- Summary: Group related resources in Elytron subsystem Key: WFLY-7190 URL: https://issues.jboss.org/browse/WFLY-7190 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure. Suggestion: It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7190) Group related resources in Elytron subsystem

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7190?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7190: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Group related resources in Elytron subsystem > -------------------------------------------- > > Key: WFLY-7190 > URL: https://issues.jboss.org/browse/WFLY-7190 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure. > Suggestion: > It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7189) UT000010: Session not found

by Alpesh B (JIRA)

[ https://issues.jboss.org/browse/WFLY-7189?page=com.atlassian.jira.plugin.... ] Alpesh B updated WFLY-7189: --------------------------- Labels: wildfly (was: jboss) > UT000010: Session not found > --------------------------- > > Key: WFLY-7189 > URL: https://issues.jboss.org/browse/WFLY-7189 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.2.Final > Environment: Production > Reporter: Alpesh B > Assignee: Jason Greene > Priority: Critical > Labels: wildfly > > In my application I am using 4 different database connection with spring, > Before upgrading to wildfly 9.0.2 Final it was working fine, but yesterday from production I came to know that one database is not able to connect. and giving following exception > {code:java} > Caused by: java.lang.IllegalStateException: UT000010: Session not found ONaa4NC8R3y3WuYRhMjp5kD0__MXIkMtHbginKOx > INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:430) > INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:123) > INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.util.WebUtils.getSessionMutex(WebUtils.java:328) > INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.ServletRequestAttributes.getSessionMutex(ServletRequestAttributes.java:191) > INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.SessionScope.get(SessionScope.java:88) > INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) > {code} > While, I was able to connect to other databases through the application, only facing issues for accessing one of the database. > After restart of wildfly server issue is resolved, Even I am not able to reproduce it > [OpenIssue|[#https://developer.jboss.org/message/949465#949465]] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7189) UT000010: Session not found

by Alpesh B (JIRA)

[ https://issues.jboss.org/browse/WFLY-7189?page=com.atlassian.jira.plugin.... ] Alpesh B updated WFLY-7189: --------------------------- Description: In my application I am using 4 different database connection with spring, Before upgrading to wildfly 9.0.2 Final it was working fine, but yesterday from production I came to know that one database is not able to connect. and giving following exception {code:java} Caused by: java.lang.IllegalStateException: UT000010: Session not found ONaa4NC8R3y3WuYRhMjp5kD0__MXIkMtHbginKOx INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:430) INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:123) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.util.WebUtils.getSessionMutex(WebUtils.java:328) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.ServletRequestAttributes.getSessionMutex(ServletRequestAttributes.java:191) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.SessionScope.get(SessionScope.java:88) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) {code} While, I was able to connect to other databases through the application, only facing issues for accessing one of the database. After restart of wildfly server issue is resolved, Even I am not able to reproduce it [OpenIssue|[#https://developer.jboss.org/message/949465#949465]] was: In my application I am using 4 different database connection with spring, Before upgrading to wildfly 9.0.2 Final it was working fine, but yesterday from production I came to know that one database is not able to connect. and giving following exception {code:java} Caused by: java.lang.IllegalStateException: UT000010: Session not found ONaa4NC8R3y3WuYRhMjp5kD0__MXIkMtHbginKOx INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:430) INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:123) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.util.WebUtils.getSessionMutex(WebUtils.java:328) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.ServletRequestAttributes.getSessionMutex(ServletRequestAttributes.java:191) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.SessionScope.get(SessionScope.java:88) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) {code} While, I was able to connect to other databases through the application, only facing issues for accessing one of the database. After restart of wildfly server issue is resolved, Even I am not able to reproduce it [OpenIssue|[#anchor]] > UT000010: Session not found > --------------------------- > > Key: WFLY-7189 > URL: https://issues.jboss.org/browse/WFLY-7189 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.2.Final > Environment: Production > Reporter: Alpesh B > Assignee: Jason Greene > Priority: Critical > Labels: jboss > > In my application I am using 4 different database connection with spring, > Before upgrading to wildfly 9.0.2 Final it was working fine, but yesterday from production I came to know that one database is not able to connect. and giving following exception > {code:java} > Caused by: java.lang.IllegalStateException: UT000010: Session not found ONaa4NC8R3y3WuYRhMjp5kD0__MXIkMtHbginKOx > INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:430) > INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:123) > INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.util.WebUtils.getSessionMutex(WebUtils.java:328) > INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.ServletRequestAttributes.getSessionMutex(ServletRequestAttributes.java:191) > INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.SessionScope.get(SessionScope.java:88) > INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) > {code} > While, I was able to connect to other databases through the application, only facing issues for accessing one of the database. > After restart of wildfly server issue is resolved, Even I am not able to reproduce it > [OpenIssue|[#https://developer.jboss.org/message/949465#949465]] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7189) UT000010: Session not found

by Alpesh B (JIRA)

Alpesh B created WFLY-7189: ------------------------------ Summary: UT000010: Session not found Key: WFLY-7189 URL: https://issues.jboss.org/browse/WFLY-7189 Project: WildFly Issue Type: Bug Components: Server Affects Versions: 9.0.2.Final Environment: Production Reporter: Alpesh B Assignee: Jason Greene Priority: Critical In my application I am using 4 different database connection with spring, Before upgrading to wildfly 9.0.2 Final it was working fine, but yesterday from production I came to know that one database is not able to connect. and giving following exception {code:java} Caused by: java.lang.IllegalStateException: UT000010: Session not found ONaa4NC8R3y3WuYRhMjp5kD0__MXIkMtHbginKOx INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:430) INFO | jvm 1 | 2016/09/21 05:53:09 | at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:123) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.util.WebUtils.getSessionMutex(WebUtils.java:328) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.ServletRequestAttributes.getSessionMutex(ServletRequestAttributes.java:191) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.web.context.request.SessionScope.get(SessionScope.java:88) INFO | jvm 1 | 2016/09/21 05:53:09 | at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) {code} While, I was able to connect to other databases through the application, only facing issues for accessing one of the database. After restart of wildfly server issue is resolved, Even I am not able to reproduce it [OpenIssue|[#anchor]] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Scott Marlow commented on JASSIST-261: -------------------------------------- Also of note is a list of issues at [http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNo...] > Issue with javassist on jdk 9b112 > --------------------------------- > > Key: JASSIST-261 > URL: https://issues.jboss.org/browse/JASSIST-261 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Environment: Javassist with jdk 9b112 > Reporter: Hoang Chuong Tran > Assignee: Shigeru Chiba > > I am migrating a project to java 9, which also uses javassist to generate runtime code. > One test of mine fails on jdk 9b112 while it passes on jdk 8u77. > {noformat} > import static javassist.CtClass.voidType; > import java.lang.reflect.Method; > import java.lang.reflect.Modifier; > import java.util.HashMap; > import java.util.Map; > import org.junit.Test; > import javassist.ClassClassPath; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtField; > import javassist.CtMethod; > import javassist.CtNewMethod; > public class MyTests { > public static class MyObject { > protected Object field; > Object getField() {return field;} > public void setField(Object field) {} > } > @Test > public void test() throws InstantiationException, IllegalAccessException { > Class<? extends MyObject> clazz = compile(MyObject.class); > clazz.newInstance().setField(null); > } > /** Compile a transfer class */ > public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) { > // Determine class setters > Map<String, Method> setters = extractSetters(targetClass); > ClassPool classPool = ClassPool.getDefault(); > classPool.insertClassPath(new ClassClassPath(targetClass)); > try { > // Compile a new transfer class on the fly > CtClass baseClass = classPool.get(MyObject.class.getName()); > CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass); > for(Method originalSetter : setters.values()) { > // Create a field to hold the attribute > Class<?> fieldClass = originalSetter.getParameterTypes()[0]; > CtClass fieldType = classPool.get(fieldClass.getName()); > String fieldName = originalSetter.getName().substring(3); > CtField field = new CtField(fieldType, fieldName, proxyClass); > proxyClass.addField(field); > // Create a setter method to set that field > CtClass[] parameters = new CtClass[] { fieldType }; > String setterBody = "{ System.out.println(\"Hello World\"); }"; > CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass); > proxyClass.addMethod(setter); > } > Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain()); > return javaClass; > } catch(Exception e) { > throw new RuntimeException("Failure during transfer compilation for " + targetClass, e); > } > } > /** Extract setter methods from a class */ > public static Map<String, Method> extractSetters(Class<?> cls) { > Map<String, Method> setters = new HashMap<String, Method>(); > for(Method method : cls.getMethods()) { > // Lookup setter methods > if(method.getName().startsWith("set")) { > // Only public setters > int modifiers = method.getModifiers(); > if(Modifier.isPublic(modifiers)) { > Class<?>[] exceptions = method.getExceptionTypes(); > Class<?>[] parameters = method.getParameterTypes(); > Class<?> returnType = method.getReturnType(); > if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) { > setters.put(method.getName(), method); > } > } > } > } > return setters; > } > } > {noformat} > On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. > On jdk 9b112, I got the following exception > {noformat} > java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject > at MyTests.compile(MyTests.java:68) > at MyTests.test(MyTests.java:29) > at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: javassist.NotFoundException: java.lang.Object > at javassist.ClassPool.get(ClassPool.java:450) > at MyTests.compile(MyTests.java:51) > ... 24 more > {noformat} > I suspect that is due to the jigsaw integration into the jdk. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1250) Drools Sample.drl is broken

by Robert (Bob) Brodt (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1250?page=com.atlassian.jira.plugi... ] Robert (Bob) Brodt commented on DROOLS-1250: -------------------------------------------- The fix for this will not be available until 6.5.Final community (6.4 product) is released, shortly. At that time I will add a comment to this JIRA indicating where the new bits can be downloaded. > Drools Sample.drl is broken > --------------------------- > > Key: DROOLS-1250 > URL: https://issues.jboss.org/browse/DROOLS-1250 > Project: Drools > Issue Type: Feature Request > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Reporter: Tianwei Chen > Assignee: Robert (Bob) Brodt > Fix For: 6.5.0.Final > > > Hello, I use drools plugin (6.4.0.Final) in Eclipse Neon. I followed the wizard to create a drools project with some example files. After the step were done, Eclipse highlighted errors at the two rules in the Sample.drl file. Here is one of the errors: > Multiple markers at this line > - com.sample.DroolsTest.Message cannot be resolved to a type > - org.drools.core.util.bitmask.AllSetBitMask cannot be resolved to a type > - Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > - org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > - KnowledgeHelper cannot be resolved to a type > - Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > - Message.GOODBYE cannot be resolved to a type > - org.kie.api.runtime.rule.RuleContext cannot be resolved to a type > - java.lang.Exception cannot be resolved to a type > When I ran DroolsTest.java, I got the following error: > java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=Sample.drl, line=15, column=0 > text=Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type], Message [id=2, level=ERROR, path=Sample.drl, line=5, column=0 > text=Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type > Message.GOODBYE cannot be resolved to a type > org.drools.core.util.bitmask.AllSetBitMask cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type]] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:450) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:604) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:575) > It seems like an library path issue. Please help! > Thank you very much! > Tianwei Chen -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1250) Drools Sample.drl is broken

by Sean Wu (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1250?page=com.atlassian.jira.plugi... ] Sean Wu commented on DROOLS-1250: --------------------------------- Hi Tianwei Chen, just followed your comment and still got the same error. Did you still use droolsjbpm tools 6.4 plugin? I have to add dialect mvel to make it work. Is it an issue of plugin or runtime? > Drools Sample.drl is broken > --------------------------- > > Key: DROOLS-1250 > URL: https://issues.jboss.org/browse/DROOLS-1250 > Project: Drools > Issue Type: Feature Request > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Reporter: Tianwei Chen > Assignee: Robert (Bob) Brodt > Fix For: 6.5.0.Final > > > Hello, I use drools plugin (6.4.0.Final) in Eclipse Neon. I followed the wizard to create a drools project with some example files. After the step were done, Eclipse highlighted errors at the two rules in the Sample.drl file. Here is one of the errors: > Multiple markers at this line > - com.sample.DroolsTest.Message cannot be resolved to a type > - org.drools.core.util.bitmask.AllSetBitMask cannot be resolved to a type > - Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > - org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > - KnowledgeHelper cannot be resolved to a type > - Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > - Message.GOODBYE cannot be resolved to a type > - org.kie.api.runtime.rule.RuleContext cannot be resolved to a type > - java.lang.Exception cannot be resolved to a type > When I ran DroolsTest.java, I got the following error: > java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=Sample.drl, line=15, column=0 > text=Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type], Message [id=2, level=ERROR, path=Sample.drl, line=5, column=0 > text=Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type > Message.GOODBYE cannot be resolved to a type > org.drools.core.util.bitmask.AllSetBitMask cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type]] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:450) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:604) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:575) > It seems like an library path issue. Please help! > Thank you very much! > Tianwei Chen -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7188) Add an attribute to the JSF subsystem to specify whether or not DOCTYPE declarations in JSF deployments should be disallowed

by Kabir Khan (JIRA)

Kabir Khan created WFLY-7188: -------------------------------- Summary: Add an attribute to the JSF subsystem to specify whether or not DOCTYPE declarations in JSF deployments should be disallowed Key: WFLY-7188 URL: https://issues.jboss.org/browse/WFLY-7188 Project: WildFly Issue Type: Feature Request Components: JSF Affects Versions: 10.0.0.Final Reporter: Farah Juma Assignee: Farah Juma When JAXP secure processing features are added to Xerces (i.e., once Ron Sigal's [Xerces PR|https://github.com/jboss/xerces/pull/12] is merged), WildFly will be using a {{SAXParserFactory}} implementation that disallows DOCTYPE declarations by default. This will cause a {{ServletException}} to occur when accessing any JSF .xhtml page that includes a DOCTYPE declaration. We should give users the option to override this default behaviour and allow DOCTYPE declarations for JSF apps, if desired. We can accomplish this as follows: 1) Add a "com.sun.faces.disallowDoctypeDecl" context parameter to Mojarra to explicitly specify whether or not DOCTYPE declarations should be allowed. * I've created [JAVASERVERFACES-4130|https://java.net/jira/browse/JAVASERVERFACES-4130] to track this and I've submitted a patch upstream to the Mojarra team. 2) Add a {{disallow-doctype-decl}} attribute to the JSF subsystem to specify the default value of the "com.sun.faces.disallowDoctypeDecl" context parameter for JSF apps. * I've implemented the changes required for this: https://github.com/fjuma/wildfly/commit/e6076549ea5c4b84a93dbe4ea0db9f8c2... If my patch for the new context parameter looks good to the Mojarra team, I can apply it to our Mojarra fork and submit a PR against WildFly with these changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7183) 'name' attribute missing in XSD while required by web subsystem parser

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7183?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7183: ----------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1365939|https://bugzilla.redhat.com/show_bug.cgi?id=1365939] from MODIFIED to POST > 'name' attribute missing in XSD while required by web subsystem parser > ---------------------------------------------------------------------- > > Key: WFLY-7183 > URL: https://issues.jboss.org/browse/WFLY-7183 > Project: WildFly > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1365939 , originaly reported by [~paramjindal] > While configuring the global valve using the following article : > https://access.redhat.com/solutions/379813 > It is mandatory that the "name" attribute of valve must match the "auth-method" that is specified in the "WEB-INF/web.xml". > So "name" attribute is mandatory to configure this valve. > but it is not mentioned in the schema of valve as shown below : > <xs:element name="valve"> > <xs:complexType> > <xs:sequence> > <xs:element name="param" minOccurs="0" maxOccurs="unbounded" type="paramType" /> > </xs:sequence> > <xs:attribute name="class-name" type="xs:string" use="required" /> > <xs:attribute name="module" type="xs:string" use="required" /> > <xs:attribute name="enabled" default="true" type="xs:boolean" /> > </xs:complexType> > </xs:element> > Version-Release number of selected component (if applicable): -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7187) Upgrade to WildFly Naming Client 1.0.0.Beta1

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-7187: -------------------------------------- Summary: Upgrade to WildFly Naming Client 1.0.0.Beta1 Key: WFLY-7187 URL: https://issues.jboss.org/browse/WFLY-7187 Project: WildFly Issue Type: Component Upgrade Components: Naming Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1812) Makes ModuleOpsCompletionTestCase more resilient

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1812?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet reassigned WFCORE-1812: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Tomaz Cerar) > Makes ModuleOpsCompletionTestCase more resilient > ------------------------------------------------ > > Key: WFCORE-1812 > URL: https://issues.jboss.org/browse/WFCORE-1812 > Project: WildFly Core > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 3.0.0.Alpha8 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Minor > > Intermittent failure if the modules directory has some leftovers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1812) Makes ModuleOpsCompletionTestCase more resilient

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-1812: ----------------------------------------- Summary: Makes ModuleOpsCompletionTestCase more resilient Key: WFCORE-1812 URL: https://issues.jboss.org/browse/WFCORE-1812 Project: WildFly Core Issue Type: Feature Request Components: Test Suite Affects Versions: 3.0.0.Alpha8 Reporter: ehsavoie Hugonnet Assignee: Tomaz Cerar Priority: Minor Intermittent failure if the modules directory has some leftovers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1325) Wrong condition when parsing ironjacamar.rollback_on_fatal_error property

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1325?page=com.atlassian.jira.plugin... ] Ivo Studensky updated JBJCA-1325: --------------------------------- Fix Version/s: WildFly/IronJacamar 1.3.5.Final 1.2.8.Final > Wrong condition when parsing ironjacamar.rollback_on_fatal_error property > ------------------------------------------------------------------------- > > Key: JBJCA-1325 > URL: https://issues.jboss.org/browse/JBJCA-1325 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.3.4.Final > Reporter: Martin Simka > Assignee: Ivo Studensky > Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final > > > There is wrong condition in https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... > {code:java} > value = SecurityActions.getSystemProperty("ironjacamar.rollback_on_fatal_error"); > if (value != null && !value.trim().equals("")) > { > if ("true".equalsIgnoreCase(value) || "false".equalsIgnoreCase(value)) > { > doSetRollbackOnly = Boolean.parseBoolean(value); > } > else > { > StringTokenizer st = new StringTokenizer(value, ","); > while (doDelistResource && st.hasMoreTokens()) // <-- should be while (doSetRollbackOnly ... > { > if (getPool().getName().equals(st.nextToken())) > doSetRollbackOnly = false; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1325) Wrong condition when parsing ironjacamar.rollback_on_fatal_error property

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1325?page=com.atlassian.jira.plugin... ] Ivo Studensky resolved JBJCA-1325. ---------------------------------- Resolution: Done > Wrong condition when parsing ironjacamar.rollback_on_fatal_error property > ------------------------------------------------------------------------- > > Key: JBJCA-1325 > URL: https://issues.jboss.org/browse/JBJCA-1325 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.3.4.Final > Reporter: Martin Simka > Assignee: Ivo Studensky > > There is wrong condition in https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... > {code:java} > value = SecurityActions.getSystemProperty("ironjacamar.rollback_on_fatal_error"); > if (value != null && !value.trim().equals("")) > { > if ("true".equalsIgnoreCase(value) || "false".equalsIgnoreCase(value)) > { > doSetRollbackOnly = Boolean.parseBoolean(value); > } > else > { > StringTokenizer st = new StringTokenizer(value, ","); > while (doDelistResource && st.hasMoreTokens()) // <-- should be while (doSetRollbackOnly ... > { > if (getPool().getName().equals(st.nextToken())) > doSetRollbackOnly = false; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7185) JSON-B 1.0 Support

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7185?page=com.atlassian.jira.plugin.... ] James Perkins reassigned WFLY-7185: ----------------------------------- Assignee: James Perkins > JSON-B 1.0 Support > ------------------ > > Key: WFLY-7185 > URL: https://issues.jboss.org/browse/WFLY-7185 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6460) JSON-P 1.1 Support

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6460?page=com.atlassian.jira.plugin.... ] James Perkins reassigned WFLY-6460: ----------------------------------- Assignee: James Perkins > JSON-P 1.1 Support > ------------------ > > Key: WFLY-6460 > URL: https://issues.jboss.org/browse/WFLY-6460 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2098: -------------------------------- Hmm, a separate {{NAMING}} protocol might be difficult to write... When a member P joins, it runs the discovery protocol to (1) find the coordinator and (2) populate its (name and address mapping) caches. Coordinator Q can log the logical name of P when receiving a JOIN(P) request, as the previous discovery phase made the logical name of P known to Q. However, with a separate {{NAMING}} protocol, the logical name of P would somehow have to be shipped to Q separately. Piggy-backing on the discovery protocol entails {{NAMING}} having to intercept all messages and piggybacking on {{GET_MBRS_REQ}} and {{GET_MBRS_RSP}}. However, this slows things down as these message make up only a small part of the overall messages, but we have to inspect *every single message*! > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1300) result of rule execution in STREAM mode are different between PHREAK and RETEOO

by Hiroko Miura (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1300?page=com.atlassian.jira.plugi... ] Hiroko Miura updated DROOLS-1300: --------------------------------- Labels: support (was: ) > result of rule execution in STREAM mode are different between PHREAK and RETEOO > -------------------------------------------------------------------------------- > > Key: DROOLS-1300 > URL: https://issues.jboss.org/browse/DROOLS-1300 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Hiroko Miura > Assignee: Mario Fusco > Priority: Critical > Labels: support > Fix For: 6.5.0.Final > > Attachments: rules-reproducer.zip > > > Customer is developing rules and runs it as CEP in STREAM mode. > When executing it with same facts , the results (remaining objects in working memory) are > different between PHREAK and RETEOO. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7158: -------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Working with multiple keys in key store > --------------------------------------- > > Key: WFLY-7158 > URL: https://issues.jboss.org/browse/WFLY-7158 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key). > That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation. > {code} > /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-7158: ----------------------------- Description: In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key). That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation. {code} /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password) {code} was: In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key). That is pretty inconvinient. Probably introducing alias attribute on key-manager would be more intuitive solution to this situation. {code} /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password) {code} > Working with multiple keys in key store > --------------------------------------- > > Key: WFLY-7158 > URL: https://issues.jboss.org/browse/WFLY-7158 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key). > That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation. > {code} > /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7027) MBeans with ObjectName attributes throw ClassNotFoundException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7027?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7027: ----------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1372096|https://bugzilla.redhat.com/show_bug.cgi?id=1372096] from NEW to ASSIGNED > MBeans with ObjectName attributes throw ClassNotFoundException > -------------------------------------------------------------- > > Key: WFLY-7027 > URL: https://issues.jboss.org/browse/WFLY-7027 > Project: WildFly > Issue Type: Bug > Components: JMX > Affects Versions: 10.0.0.Final > Reporter: Dennis Reed > Assignee: Bartosz Baranowski > Fix For: 11.0.0.Alpha1 > > > An MBean with: > public void setObj(javax.management.ObjectName someObject) > <mbean ...> > <attribute name="Obj" /> > causes "java.lang.ClassNotFoundException: javax.management.MalformedObjectNameException from [Module \"org.jboss.common-beans:main\" > org.jboss.common.beans.property.ObjectNameEditor in that module is used to convert to ObjectName objects, and requires MalformedObjectNameException but it is not on the classpath of that module. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7183) 'name' attribute missing in XSD while required by web subsystem parser

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7183?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7183: ----------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1365939|https://bugzilla.redhat.com/show_bug.cgi?id=1365939] from NEW to ASSIGNED > 'name' attribute missing in XSD while required by web subsystem parser > ---------------------------------------------------------------------- > > Key: WFLY-7183 > URL: https://issues.jboss.org/browse/WFLY-7183 > Project: WildFly > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1365939 , originaly reported by [~paramjindal] > While configuring the global valve using the following article : > https://access.redhat.com/solutions/379813 > It is mandatory that the "name" attribute of valve must match the "auth-method" that is specified in the "WEB-INF/web.xml". > So "name" attribute is mandatory to configure this valve. > but it is not mentioned in the schema of valve as shown below : > <xs:element name="valve"> > <xs:complexType> > <xs:sequence> > <xs:element name="param" minOccurs="0" maxOccurs="unbounded" type="paramType" /> > </xs:sequence> > <xs:attribute name="class-name" type="xs:string" use="required" /> > <xs:attribute name="module" type="xs:string" use="required" /> > <xs:attribute name="enabled" default="true" type="xs:boolean" /> > </xs:complexType> > </xs:element> > Version-Release number of selected component (if applicable): -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7186) Security 1.0 Support (JSR 375)

by David Lloyd (JIRA)

David Lloyd created WFLY-7186: --------------------------------- Summary: Security 1.0 Support (JSR 375) Key: WFLY-7186 URL: https://issues.jboss.org/browse/WFLY-7186 Project: WildFly Issue Type: Sub-task Components: Security Reporter: David Lloyd -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7185) JSON-B 1.0 Support

by David Lloyd (JIRA)

David Lloyd created WFLY-7185: --------------------------------- Summary: JSON-B 1.0 Support Key: WFLY-7185 URL: https://issues.jboss.org/browse/WFLY-7185 Project: WildFly Issue Type: Sub-task Components: EE Reporter: David Lloyd -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6457) JMS 2.1 Support

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6457?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-6457: ----------------------------------- Proposed to drop as of 2016-Sep-19 > JMS 2.1 Support > --------------- > > Key: WFLY-6457 > URL: https://issues.jboss.org/browse/WFLY-6457 > Project: WildFly > Issue Type: Sub-task > Reporter: David Lloyd > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1811) make CredentialStoreClient check whether caller can obtian reference to store itself

by Peter Skopek (JIRA)

Peter Skopek created WFCORE-1811: ------------------------------------ Summary: make CredentialStoreClient check whether caller can obtian reference to store itself Key: WFCORE-1811 URL: https://issues.jboss.org/browse/WFCORE-1811 Project: WildFly Core Issue Type: Task Components: Security Reporter: Peter Skopek Assignee: Peter Skopek method org.jboss.as.controller.security.CredentialStoreClient#getCredentialStore should check caller's permission -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2080 at 9/21/16 10:45 AM: ---------------------------------------------------------- I'm starting to have second thoughts on {{IpAddressUUID}}... :-( Looking at the size of an instance (using JOL), we have * 32 bytes for {{IpAddressUUID}} * 24 bytes for {{Inet4Address}} * 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each * 32 bytes for {{Inet6Address}} This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses. I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses... That would use *40 bytes for an IPv4 address* and *48 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}. The downside is that we have to create a new instance of {{Inet4Address}} or {{Inet6Address}} every time we need to send a unicast message, by extracting the address and port from the UUID. was (Author: belaban): I'm starting to have second thoughts on {{IpAddressUUID}}... :-( Looking at the size of an instance (using JOL), we have * 32 bytes for {{IpAddressUUID}} * 24 bytes for {{Inet4Address}} * 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each * 32 bytes for {{Inet6Address}} This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses. I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses... That would use *40 bytes for an IPv4 address* and *48 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}. > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2080: -------------------------------- I'm starting to have second thoughts on {{IpAddressUUID}}... :-( Looking at the size of an instance (using JOL), we have * 32 bytes for {{IpAddressUUID}} * 24 bytes for {{Inet4Address}} * 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each * 32 bytes for {{Inet6Address}} This means a total of 88 bytes for an IPv4 address and 96 bytes for an IPv6 address! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses. I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses... That would use 40 bytes for an IPv4 address and 48 bytes for an IPv6 address. That's much less memory used than {{IpAddressUUID}}. > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2080 at 9/21/16 10:42 AM: ---------------------------------------------------------- I'm starting to have second thoughts on {{IpAddressUUID}}... :-( Looking at the size of an instance (using JOL), we have * 32 bytes for {{IpAddressUUID}} * 24 bytes for {{Inet4Address}} * 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each * 32 bytes for {{Inet6Address}} This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses. I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses... That would use *40 bytes for an IPv4 address* and *48 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}. was (Author: belaban): I'm starting to have second thoughts on {{IpAddressUUID}}... :-( Looking at the size of an instance (using JOL), we have * 32 bytes for {{IpAddressUUID}} * 24 bytes for {{Inet4Address}} * 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each * 32 bytes for {{Inet6Address}} This means a total of 88 bytes for an IPv4 address and 96 bytes for an IPv6 address! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses. I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses... That would use 40 bytes for an IPv4 address and 48 bytes for an IPv6 address. That's much less memory used than {{IpAddressUUID}}. > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1301) Add remote API call to deploy kie artifact from a specific maven repo.

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1301?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1301: ------------------------------------- In practice it is required to: # have an API to dynamically add and remove a maven repository and list all available repositories # have a public method to deploy an artifact into a specific repository > Add remote API call to deploy kie artifact from a specific maven repo. > ---------------------------------------------------------------------- > > Key: DROOLS-1301 > URL: https://issues.jboss.org/browse/DROOLS-1301 > Project: Drools > Issue Type: Feature Request > Reporter: Hiram Chirino > Assignee: Mario Fusco > > We want to build a camel OSE example which needs to deploy kie artifacts to a BRMS server. We want to avoid having to require a user from having to setup and deploy this artifacts to mvn repo. > We could have our example pod host a mvn repo with the kie artifacts deployed to it. It would be nice to have the API call the requests the sever to the deploy the artifact GAV to also pass along the the mvn repo URL to the pod hosting the kie artifacts. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1325) Wrong condition when parsing ironjacamar.rollback_on_fatal_error property

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1325?page=com.atlassian.jira.plugin... ] Martin Simka commented on JBJCA-1325: ------------------------------------- [~istudens] PR is merged, this should be resolved > Wrong condition when parsing ironjacamar.rollback_on_fatal_error property > ------------------------------------------------------------------------- > > Key: JBJCA-1325 > URL: https://issues.jboss.org/browse/JBJCA-1325 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.3.4.Final > Reporter: Martin Simka > Assignee: Ivo Studensky > > There is wrong condition in https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... > {code:java} > value = SecurityActions.getSystemProperty("ironjacamar.rollback_on_fatal_error"); > if (value != null && !value.trim().equals("")) > { > if ("true".equalsIgnoreCase(value) || "false".equalsIgnoreCase(value)) > { > doSetRollbackOnly = Boolean.parseBoolean(value); > } > else > { > StringTokenizer st = new StringTokenizer(value, ","); > while (doDelistResource && st.hasMoreTokens()) // <-- should be while (doSetRollbackOnly ... > { > if (getPool().getName().equals(st.nextToken())) > doSetRollbackOnly = false; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1301) Add remote API call to deploy kie artifact from a specific maven repo.

by Hiram Chirino (JIRA)

Hiram Chirino created DROOLS-1301: ------------------------------------- Summary: Add remote API call to deploy kie artifact from a specific maven repo. Key: DROOLS-1301 URL: https://issues.jboss.org/browse/DROOLS-1301 Project: Drools Issue Type: Feature Request Reporter: Hiram Chirino Assignee: Edson Tirelli We want to build a camel OSE example which needs to deploy kie artifacts to a BRMS server. We want to avoid having to require a user from having to setup and deploy this artifacts to mvn repo. We could have our example pod host a mvn repo with the kie artifacts deployed to it. It would be nice to have the API call the requests the sever to the deploy the artifact GAV to also pass along the the mvn repo URL to the pod hosting the kie artifacts. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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 September 2016