September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7066) Wrong description of simple-regex-realm-mapper / mapped-regex-realm-mapper in model

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7066?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-5908 to WFLY-7066: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7066 (was: JBEAP-5908) 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.DR4) > Wrong description of simple-regex-realm-mapper / mapped-regex-realm-mapper in model > ----------------------------------------------------------------------------------- > > Key: WFLY-7066 > URL: https://issues.jboss.org/browse/WFLY-7066 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > In output of {noformat}/subsystem=elytron:read-resource-description(recursive=true){noformat} , there is wrong description of simple-regex-realm-mapper / mapped-regex-realm-mapper _"Definition of a custom RealmMapper"_ , what is probably copied from custom-realm-mapper. > In XSD, there is more proper > * mapped-regex-realm-mapper: _"A RealmMapper implementaion that first uses a regular expression to extract the realm name, this is then converted using the configured mapping of realm names."_ > * simple-regex-realm-mapper: _"A simple RealmMapper definition that attempts to extract the realm name using the capture group from the regular expression, if that does not provide a match then the delegate RealmMapper is used instead."_ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7065) Wrong description of logical-role-mapper in model

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7065?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-5905 to WFLY-7065: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7065 (was: JBEAP-5905) 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.DR4) > Wrong description of logical-role-mapper in model > ------------------------------------------------- > > Key: WFLY-7065 > URL: https://issues.jboss.org/browse/WFLY-7065 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > In output of > {noformat} > /subsystem=elytron:read-resource-description(recursive=true) > {noformat} > , there is wrong description of logical-role-mapper _A role mapper definition where a constant set of roles is always returned._ , what is probably copied from constant-role-mapper. > In XSD, there is more proper description _A RoleMapper definition for a RoleMapper that performs a logical operation using two refereced RoleMappers._ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-955) Regression in parsing username in LdapExtLoginModule

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/SECURITY-955?page=com.atlassian.jira.plug... ] Ondrej Lukas updated SECURITY-955: ---------------------------------- Affects Version/s: PicketBox_5_0_0.Alpha3 > Regression in parsing username in LdapExtLoginModule > ---------------------------------------------------- > > Key: SECURITY-955 > URL: https://issues.jboss.org/browse/SECURITY-955 > Project: PicketBox > Issue Type: Bug > Affects Versions: PicketBox_5_0_0.Alpha3 > Reporter: Ondrej Lukas > Assignee: Stefan Guilhen > Priority: Blocker > > In case when customers using LdapExtLoginModule with option parseUsername=true but without option usernameBeginString (i.e. usernameBeginString=null) then all users cannot be successfully authenticated into application. Authentication failure is caused by hidden internal NPE. > It is the same issue as was reported in [1], but fix is missing in current EAP 7.1 version of PicketBox (5.0.0.Alpha3). > We request blocker flag because: > * Valid configuration which works for 7.0.x becomes invalid after migration to 7.1.0 > * All users cannot authenticate to application despite of valid EAP configuration > * Authetication failure caused by NPE is logged to server log > Thrown NPE: > {code} > java.lang.NullPointerException > at org.jboss.security.auth.spi.LdapExtLoginModule.getUsername(LdapExtLoginModule.java:963) > at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:342) > at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:283) > {code} > [1] https://issues.jboss.org/browse/JBEAP-364?focusedCommentId=13160168&page=... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-955) Regression in parsing username in LdapExtLoginModule

by Ondrej Lukas (JIRA)

Ondrej Lukas created SECURITY-955: ------------------------------------- Summary: Regression in parsing username in LdapExtLoginModule Key: SECURITY-955 URL: https://issues.jboss.org/browse/SECURITY-955 Project: PicketBox Issue Type: Bug Reporter: Ondrej Lukas Assignee: Stefan Guilhen Priority: Blocker In case when customers using LdapExtLoginModule with option parseUsername=true but without option usernameBeginString (i.e. usernameBeginString=null) then all users cannot be successfully authenticated into application. Authentication failure is caused by hidden internal NPE. It is the same issue as was reported in [1], but fix is missing in current EAP 7.1 version of PicketBox (5.0.0.Alpha3). We request blocker flag because: * Valid configuration which works for 7.0.x becomes invalid after migration to 7.1.0 * All users cannot authenticate to application despite of valid EAP configuration * Authetication failure caused by NPE is logged to server log Thrown NPE: {code} java.lang.NullPointerException at org.jboss.security.auth.spi.LdapExtLoginModule.getUsername(LdapExtLoginModule.java:963) at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:342) at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:283) {code} [1] https://issues.jboss.org/browse/JBEAP-364?focusedCommentId=13160168&page=... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1278) Test coverage of MBean for processes

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1278: -------------------------------------- Summary: Test coverage of MBean for processes Key: DROOLS-1278 URL: https://issues.jboss.org/browse/DROOLS-1278 Project: Drools Issue Type: Sub-task Reporter: Matteo Mortari Assignee: Matteo Mortari Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1277) Remove detailed info by process instance, keeping statistics by process (aggregated) only

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1277: -------------------------------------- Summary: Remove detailed info by process instance, keeping statistics by process (aggregated) only Key: DROOLS-1277 URL: https://issues.jboss.org/browse/DROOLS-1277 Project: Drools Issue Type: Sub-task Reporter: Matteo Mortari Assignee: Matteo Mortari Important to differentiate monitoring (JMX MBeans) from audit and logging -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7033) EL break page compilation

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7033?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-7033: ------------------------------------ Assignee: Tomaz Cerar (was: Stuart Douglas) > EL break page compilation > ------------------------- > > Key: WFLY-7033 > URL: https://issues.jboss.org/browse/WFLY-7033 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Marco Mondini > Assignee: Tomaz Cerar > > In case of an expression with multiple ELs, fix for WFLY-4455 breaks braces precedence. > As a conseguence, if a single quote is present between expressions, EL Parser can't find function in second expression. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6866) "JVM Options" should not be marked with asterisk

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFLY-6866?page=com.atlassian.jira.plugin.... ] Chao Wang closed WFLY-6866. --------------------------- Resolution: Duplicate Issue Duplicate issue of HAL-1143 > "JVM Options" should not be marked with asterisk > ------------------------------------------------ > > Key: WFLY-6866 > URL: https://issues.jboss.org/browse/WFLY-6866 > Project: WildFly > Issue Type: Bug > Components: Web Console > Affects Versions: 10.0.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > When editing a JVM configuration through the console in domain mode, "JVM Options" is marked with an asterisk. But "JVM Options" are not required so this asterisk should be removd. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7064) IdentityLoginModuleTestCase is incorrect

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7064: ------------------------------------ Summary: IdentityLoginModuleTestCase is incorrect Key: WFLY-7064 URL: https://issues.jboss.org/browse/WFLY-7064 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas This test assumes that the security path of '/' will be a wildcard match, while in reality it should only match the root url. This test only passed due to UNDERTOW-805 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7063) IdentityLoginModuleTestCase is incorrect

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7063: ------------------------------------ Summary: IdentityLoginModuleTestCase is incorrect Key: WFLY-7063 URL: https://issues.jboss.org/browse/WFLY-7063 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas This test assumes that the security path of '/' will be a wildcard match, while in reality it should only match the root url. This test only passed due to UNDERTOW-805 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1697) Not displaying all possibilities for FS completion breaks from the command

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1697?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-1697. -------------------------------------- Fix Version/s: 3.0.0.Alpha8 Resolution: Done Fixed via WFCORE-1753 aesh upgrade. > Not displaying all possibilities for FS completion breaks from the command > -------------------------------------------------------------------------- > > Key: WFCORE-1697 > URL: https://issues.jboss.org/browse/WFCORE-1697 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha4 > Reporter: Petr Kremensky > Assignee: Tomas Hofman > Fix For: 3.0.0.Alpha8 > > > Terminal gets cleared in case user select not to display all possibilities during FS completion. > *my use-case* > {noformat} > [disconnected /] module add --name=org.wildfly.extension.blocker-test > --dependencies=org.jboss.staxmapper,org.jboss.as.controller,org.jboss.msc > --resources=~/help/test-extension.jar --module-root-dir=../../../<TAB> > Display all 103 possibilities? (y or n)<n> > [disconnected /] > {noformat} > *reproduce* > _actual_ > {noformat} > [disconnected /] patch apply /etc/<TAB> > Display all 299 possibilities? (y or n)<n> > [disconnected /] > {noformat} > _expected_ > {noformat} > [disconnected /] patch apply /etc/<TAB> > Display all 299 possibilities? (y or n)<n> > [disconnected /] patch apply /etc/ > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-703) Add ability to see more text in a text field using a textarea or other multi-line wrapping capability

by Stephen Slaboda (JIRA)

[ https://issues.jboss.org/browse/DROOLS-703?page=com.atlassian.jira.plugin... ] Stephen Slaboda commented on DROOLS-703: ---------------------------------------- In 6.4.0.Final this is partially addressed with the self-lengthening text fields, but after some testing of that with sizeable text strings, there still seems to be some issues - 1. Using a lengthy string of just 'm' characters results in the text field not extending to the full required length. 2. Using all 'l' characters results in the text field extending more than double what is required to display the text. Using text between these values of course results in a varied amount of extra space/non-displayed characters depending on the mixture. Perhaps this has something to do with the fonts or the browser...now using Firefox 45.3.0 when I experienced this. > Add ability to see more text in a text field using a textarea or other multi-line wrapping capability > ----------------------------------------------------------------------------------------------------- > > Key: DROOLS-703 > URL: https://issues.jboss.org/browse/DROOLS-703 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.1.0.Final > Environment: RedHat 6.3 Linux x86_64; Firefox 10.0.5 > Reporter: Stephen Slaboda > Assignee: Mark Proctor > Labels: drools-wb, textarea > > Currently, if we want to assemble a string in a formula text field using various bound variables, the full text being constructed does not display all at once. The size of the box forces you to scroll around or copy/paste to see all the text after you get to a few dozen characters. We like to be somewhat verbose in our naming of variables to offer more clarity, so in some cases the text field may do this even when using a single variable name. Perhaps there could be a way to wrap the text into a multi-line display so that it is easier to edit these fields? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-625) Include the client schema in the jar

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-625: ------------------------------------ Summary: Include the client schema in the jar Key: ELY-625 URL: https://issues.jboss.org/browse/ELY-625 Project: WildFly Elytron Issue Type: Task Components: Build Reporter: Darran Lofthouse Fix For: 1.1.0.Beta9 We need to get the schema into the jar so when assembled in a WildFly feature pack it can be extracted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache

by kostd kostd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ] kostd kostd edited comment on WFLY-6596 at 9/6/16 12:46 PM: ------------------------------------------------------------ may be ready-to-use implementation can be helpful to someone attached ClassicalCacheKeysFactory.java this is same as org.hibernate.cache.internal.DefaultCacheKeysFactory but not uses deprecated Old* key implementations (Old* implementations included :) ) possible to use`em with hibernate.cache.keys_factory option P.S. formally, this is not bug, this is expected side-effect of HHH-10287 Cache keys no longer include the entity type P.P.S ClassicalCacheKeysFactory suitable to use only with Multy-tenancy = NO was (Author: kostd): may be ready-to-use implementation can be helpful to someone attached ClassicalCacheKeysFactory.java this is same as org.hibernate.cache.internal.DefaultCacheKeysFactory but not uses deprecated Old* key implementations (Old* implementations included :) ) possible to use`em with hibernate.cache.keys_factory option P.S. formally, this is not bug, this is expected side-effect of HHH-10287 Cache keys no longer include the entity type > WrongClassException when using infinispan as remote-store for hibernate entity cache > ------------------------------------------------------------------------------------ > > Key: WFLY-6596 > URL: https://issues.jboss.org/browse/WFLY-6596 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Java version: 1.8.0_45, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_45\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > Infifnspan 8.1.2 or 8.2.0 > Reporter: Gunther v. Wolffersdorff > Assignee: Scott Marlow > Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store > Attachments: ClassicalCacheKeysFactory.java, clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final-fix.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml > > > Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes: > {code} > 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66] > Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final] > at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:] > at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66] > at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > ... 43 more > Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > ... 58 more > {code} > Entity cache is configured like this: > {code:xml} > ... > <invalidation-cache name="entity" mode="SYNC"> > <eviction strategy="LRU" max-entries="1000"/> > <expiration lifespan="45000" max-idle="30000"/> > <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/> > </invalidation-cache> > ... > <outbound-socket-binding name="local-cache-server"> > <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/> > </outbound-socket-binding> > ... > {code} > see standalone.sample.ha-10.1.0.Final.xml . > *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache

by kostd kostd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ] kostd kostd updated WFLY-6596: ------------------------------ Attachment: ClassicalCacheKeysFactory.java may be ready-to-use implementation can be helpful to someone attached ClassicalCacheKeysFactory.java this is same as org.hibernate.cache.internal.DefaultCacheKeysFactory but not uses deprecated Old* key implementations (Old* implementations included :) ) possible to use`em with hibernate.cache.keys_factory option P.S. formally, this is not bug, this is expected side-effect of HHH-10287 Cache keys no longer include the entity type > WrongClassException when using infinispan as remote-store for hibernate entity cache > ------------------------------------------------------------------------------------ > > Key: WFLY-6596 > URL: https://issues.jboss.org/browse/WFLY-6596 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Java version: 1.8.0_45, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_45\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > Infifnspan 8.1.2 or 8.2.0 > Reporter: Gunther v. Wolffersdorff > Assignee: Scott Marlow > Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store > Attachments: ClassicalCacheKeysFactory.java, clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final-fix.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml > > > Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes: > {code} > 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66] > Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final] > at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:] > at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66] > at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > ... 43 more > Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > ... 58 more > {code} > Entity cache is configured like this: > {code:xml} > ... > <invalidation-cache name="entity" mode="SYNC"> > <eviction strategy="LRU" max-entries="1000"/> > <expiration lifespan="45000" max-idle="30000"/> > <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/> > </invalidation-cache> > ... > <outbound-socket-binding name="local-cache-server"> > <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/> > </outbound-socket-binding> > ... > {code} > see standalone.sample.ha-10.1.0.Final.xml . > *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7060) Elytron xsd is missing in docs/schema

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7060?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7060: ---------------------------------------- I have a fix for this one but will need to wait until I next tag the subsystem as I also need to apply a fix to the schema as it is causing a validation failure in the WildFly testsuite. https://github.com/wildfly-security/elytron-subsystem/issues/211 > Elytron xsd is missing in docs/schema > ------------------------------------- > > Key: WFLY-7060 > URL: https://issues.jboss.org/browse/WFLY-7060 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > There is no related xsd to Elytron subsystem in docs/schema. It should be added. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2047) Reduce number of threads in default configurations

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2047?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2047. ---------------------------- Resolution: Done > Reduce number of threads in default configurations > -------------------------------------------------- > > Key: JGRP-2047 > URL: https://issues.jboss.org/browse/JGRP-2047 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > Reduce the defaults for thread pools that have no queue enabled. If no queue is enabled, we can set min-threads to 0 but have a keep-alive time of 30s or 60s. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1556: ------------------------------------------ [~jmesnil] It sounds like socket-binding is just optional, since the default jgroups configs mean it is never required to set it. (The fact that the jgroups capabilities may not be available is, I think, a separate issue.) It is legal for all the attributes that are alternatives to each other to be optional. The tricky thing about your scenario is it can lead to unhelpful failures, where the user with a non-ha config doesn't configure a socket-binding and then gets ??? failure messages about missing jgroups requirements. I'm not sure if extra validation in your subsystem can cleanly help with that, since that validation would really be a capability presence check in Stage.MODEL, and that's not a valid thing to do since doing boot capabilities are registered concurrently. > Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition > --------------------------------------------------------------------------------- > > Key: WFCORE-1556 > URL: https://issues.jboss.org/browse/WFCORE-1556 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general. > The read-resource-description output for an attribute doesn't show "required" at all. > After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place. > The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing. > And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically: > nillable = !required || alternatives != null > Right now, nillable is implemented as > nillable = !required > There are a number of problems I see with AttributeDefinition: > 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'. > 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change. > 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined. > 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived. > I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway. > Next would be to fix 3), by changing how AD validates. > Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly. > Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2047) Reduce number of threads in default configurations

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2047?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2047: -------------------------------- Set the internal pools' min size to 0, no queue, max 10. This is kind of moot when JGRP-2009 is implemented... > Reduce number of threads in default configurations > -------------------------------------------------- > > Key: JGRP-2047 > URL: https://issues.jboss.org/browse/JGRP-2047 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > Reduce the defaults for thread pools that have no queue enabled. If no queue is enabled, we can set min-threads to 0 but have a keep-alive time of 30s or 60s. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2099: --------------------------- Fix Version/s: 4.0 > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2100) Timer: don't submit non-blocking tasks to the thread pool

by Bela Ban (JIRA)

Bela Ban created JGRP-2100: ------------------------------ Summary: Timer: don't submit non-blocking tasks to the thread pool Key: JGRP-2100 URL: https://issues.jboss.org/browse/JGRP-2100 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Currently, {{TimeScheduler3}} has a runner thread which continually takes tasks from a {{DelayQueue}} and submits them to the thread pool. If a task is non-blocking, this is not necessary; instead the task can be run on the runner's thread. This will reduce the number of thread created in the thread pool. Investigate whether it is possible to mark tasks as blocking or non-blocking. Example: an {{AgeOutCache}} task is always non-blocking. A {{UNICAST3}} or {{NAKACK2}} retransmission task is (potentially) blocking if {{TCP}} is used as transport and non-blocking if for example {{UDP}} or {{TCP_NIO2}} are used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2099: --------------------------- Description: Currently, TP has 4 thread pools: * OOB * Regular * Internal * Timer (used by TimeScheduler3) The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. The new common pool would have the following characteristics: * Default rejection policy of "abort" (so we can handle pool exhaustion) * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions was: Currently, TP has 4 thread pools: * OOB * Regular * Internal * Timer (used by TimeScheduler3) The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. The new common pool would have the following characteristics: * Default rejection policy of "abort" (so we can handle pool exhaustion) * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed * An additional parameter {{important}} for the {{execute()}} and {{scheduleXXX()}} methods. If set, a new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-1765: -------------------------------------- Labels: (was: deployment) > unclear NullPointerException if the deployment-scanner element is removed from the configuration > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1765 > URL: https://issues.jboss.org/browse/WFCORE-1765 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Wolf-Dieter Fink > Assignee: ehsavoie Hugonnet > > If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint. > Config: > {xml} > <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0"> >  > </subsystem> > {xml} > Log message: > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) > at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-1765: -------------------------------------- Component/s: Domain Management (was: Deployment Scanner) > unclear NullPointerException if the deployment-scanner element is removed from the configuration > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1765 > URL: https://issues.jboss.org/browse/WFCORE-1765 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Wolf-Dieter Fink > Assignee: ehsavoie Hugonnet > Labels: deployment > > If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint. > Config: > {xml} > <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0"> >  > </subsystem> > {xml} > Log message: > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) > at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1765: ------------------------------------------ [~ehugonnet] If this isn't the scanner logic itself but is a kernel issue please change the component to Domain Management. Please also reassign the downstream JBEAP to yourself and fix the component. > unclear NullPointerException if the deployment-scanner element is removed from the configuration > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1765 > URL: https://issues.jboss.org/browse/WFCORE-1765 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner > Affects Versions: 2.0.10.Final > Reporter: Wolf-Dieter Fink > Assignee: ehsavoie Hugonnet > Labels: deployment > > If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint. > Config: > {xml} > <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0"> >  > </subsystem> > {xml} > Log message: > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) > at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1768) elytron module.xml, invalid package name in exclude

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1768?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1768: ------------------------------------- Fix Version/s: 3.0.0.Alpha8 > elytron module.xml, invalid package name in exclude > --------------------------------------------------- > > Key: WFCORE-1768 > URL: https://issues.jboss.org/browse/WFCORE-1768 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha8 > > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-6127. ------------------------------ WildFly 10.1.0.Final contains the fix for the reported issue. The discussion about extended persistence context belongs in a separate jira (or could be discussed on [wildfly-dev(a)lists.jboss.org]). > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-6127: ------------------------------- Affects Version/s: 10.0.0.Final > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

Bela Ban created JGRP-2099: ------------------------------ Summary: TP: one single thread pool Key: JGRP-2099 URL: https://issues.jboss.org/browse/JGRP-2099 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Currently, TP has 4 thread pools: * OOB * Regular * Internal * Timer (used by TimeScheduler3) The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. The new common pool would have the following characteristics: * Default rejection policy of "abort" (so we can handle pool exhaustion) * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed * An additional parameter {{important}} for the {{execute()}} and {{scheduleXXX()}} methods. If set, a new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-6127: ------------------------------------ Please create a new [WFLY jira|https://issues.jboss.org/browse/WFLY] to discuss the proposed (extension) patch [https://github.com/argustelecom/wildfly/tree/WFLY-6127]. I have questions to ask about the change and whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. Please include the above two comments as well. > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1742: ------------------------------------------ [~jmesnil] fyi as we are talking about a management related subsystem in the context of the process state listener RFE. > Allow registering a custom handler for management interface > ----------------------------------------------------------- > > Key: WFCORE-1742 > URL: https://issues.jboss.org/browse/WFCORE-1742 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Sebastian Łaskawiec > > When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users): > {noformat} > curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth" > Content-Length: 77 > Content-Type: text/html > Date: Wed, 10 Aug 2016 10:39:15 GMT > HTTP/1.1 200 OK > Connection: keep-alive > Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001 > Content-Type: application/json; charset=utf-8 > Content-Length: 1927 > Date: Wed, 10 Aug 2016 10:39:15 GMT > { > "cache-health" : "GREEN", > "cluster-health" : ["test"], > "cluster-name" : "clustered", > "free-memory" : 96778, > "log-tail" : [ > "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222", > "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211", > "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container", > "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container", > "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container", > "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080", > "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest", > "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management", > "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990", > "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)" > ], > "number-of-cpus" : 8, > "number-of-nodes" : 1, > "total-memory" : 235520 > }% > {noformat} > It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7062) Infinispan query NPE on caches created by EmbeddedCacheManager

by Pavol Loffay (JIRA)

[ https://issues.jboss.org/browse/WFLY-7062?page=com.atlassian.jira.plugin.... ] Pavol Loffay updated WFLY-7062: ------------------------------- Description: Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final. Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine. https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/... When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception: https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/... Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final). Application source code: https://github.com/pavolloffay/infinispan-wildfly10 Exception when updated to 8.2.4.Final and deployed to Wildfly 10.1.0.Final {code:java} 15:51:14,692 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) 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) Caused by: java.lang.NullPointerException at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:42) at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49) at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53) at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43) at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) ... 42 more {code} was: Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final. Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine. https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/... When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception: https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/... Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final). Application source code: https://github.com/pavolloffay/infinispan-wildfly10 Error for infinispan 8.2.0.Final in Wildfly 10.0.0.Final: > Infinispan query NPE on caches created by EmbeddedCacheManager > -------------------------------------------------------------- > > Key: WFLY-7062 > URL: https://issues.jboss.org/browse/WFLY-7062 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Environment: Fedora 24 > openjdk version "1.8.0_102" > OpenJDK Runtime Environment (build 1.8.0_102-b14) > OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode) > Reporter: Pavol Loffay > Assignee: Jason Greene > Priority: Blocker > > Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final. > Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine. > https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/... > When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception: > https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/... > Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final). > Application source code: https://github.com/pavolloffay/infinispan-wildfly10 > Exception when updated to 8.2.4.Final and deployed to Wildfly 10.1.0.Final > {code:java} > 15:51:14,692 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) > 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) > Caused by: java.lang.NullPointerException > at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:42) > at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49) > at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53) > at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43) > at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) > ... 42 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7062) Infinispan query NPE on caches created by EmbeddedCacheManager

by Pavol Loffay (JIRA)

Pavol Loffay created WFLY-7062: ---------------------------------- Summary: Infinispan query NPE on caches created by EmbeddedCacheManager Key: WFLY-7062 URL: https://issues.jboss.org/browse/WFLY-7062 Project: WildFly Issue Type: Bug Affects Versions: 10.1.0.Final Environment: Fedora 24 openjdk version "1.8.0_102" OpenJDK Runtime Environment (build 1.8.0_102-b14) OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode) Reporter: Pavol Loffay Assignee: Jason Greene Priority: Blocker Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final. Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine. https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/... When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception: https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/... Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final). Application source code: https://github.com/pavolloffay/infinispan-wildfly10 Error for infinispan 8.2.0.Final in Wildfly 10.0.0.Final: -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1768) elytron module.xml, invalid package name in exclude

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1768?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1768: ------------------------------------------ In addition to that one we actually have a couple more packages that are _private not listed. > elytron module.xml, invalid package name in exclude > --------------------------------------------------- > > Key: WFCORE-1768 > URL: https://issues.jboss.org/browse/WFCORE-1768 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2097) Add Channel back

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2097?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2097: -------------------------------- It will have to be 5.0, as I cannot make API changes in minor versions. > Add Channel back > ---------------- > > Key: JGRP-2097 > URL: https://issues.jboss.org/browse/JGRP-2097 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Channel was removed, but this broke existing apps. Re-introduce Channel and mark it as deprecated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1768) elytron module.xml, invalid package name in exclude

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1768?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1768: ------------------------------------- Summary: elytron module.xml, invalid package name in exclude (was: elytron module.xml, unnecessary exclude) > elytron module.xml, invalid package name in exclude > --------------------------------------------------- > > Key: WFCORE-1768 > URL: https://issues.jboss.org/browse/WFCORE-1768 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node

by Fabian Meyer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ] Fabian Meyer commented on DROOLS-844: ------------------------------------- The reproducer I sent you last time (mail from 17.07.15) creates the NPE for 6.4.0.final and the latest 7.0.0-SNAPSHOT. > Crash when node is deleted from query node > ------------------------------------------ > > Key: DROOLS-844 > URL: https://issues.jboss.org/browse/DROOLS-844 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final, 7.0.0.Beta1 > Reporter: Fabian Meyer > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.4.0.Beta1 > > > When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException. > Exception in thread "Thread-6" java.lang.NullPointerException > at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176) > at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46) > at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360) > at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node

by Fabian Meyer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ] Fabian Meyer updated DROOLS-844: -------------------------------- Affects Version/s: 7.0.0.Beta1 6.4.0.Final (was: 6.3.0.Beta2) > Crash when node is deleted from query node > ------------------------------------------ > > Key: DROOLS-844 > URL: https://issues.jboss.org/browse/DROOLS-844 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final, 7.0.0.Beta1 > Reporter: Fabian Meyer > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.4.0.Beta1 > > > When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException. > Exception in thread "Thread-6" java.lang.NullPointerException > at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176) > at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46) > at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360) > at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2097) Add Channel back

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2097?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on JGRP-2097: -------------------------------------- Just out of curiosity, when do you plan to remove the Channel class altogether, e.g. 4.1, 4.2, 5.0? > Add Channel back > ---------------- > > Key: JGRP-2097 > URL: https://issues.jboss.org/browse/JGRP-2097 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Channel was removed, but this broke existing apps. Re-introduce Channel and mark it as deprecated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFCORE-1556: ------------------------------------- I'm hoping I'm not hijacking this issue but I have an use case in the messaging-activemq subsystem that would benefit from this improvement. A discovery-group resource can either have a socket-binding attribute or jgroups-channel / jgroups-stack attributes. If socket-binding attribute is set, jgroups-channel and jgroups-stack are not valid if socket-binding attribute is not set, JGroups resources will be used *but* jgroups-channel and jgroups-stack can still be undefined (i.e. use default channel and stack from jgroups subsystem). As an example, a discovery-group without any attributes must be valid and will use the default channel and stack from JGroups. What would be the flags on the ADs? socket-binding: required, alternative=jgroups-channel jgroups-channel: optional, alternative=socket-binding jgroups-stack: optional, alternative=socket-binding > Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition > --------------------------------------------------------------------------------- > > Key: WFCORE-1556 > URL: https://issues.jboss.org/browse/WFCORE-1556 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general. > The read-resource-description output for an attribute doesn't show "required" at all. > After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place. > The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing. > And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically: > nillable = !required || alternatives != null > Right now, nillable is implemented as > nillable = !required > There are a number of problems I see with AttributeDefinition: > 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'. > 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change. > 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined. > 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived. > I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway. > Next would be to fix 3), by changing how AD validates. > Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly. > Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1767) Exception on tab completion when adding new JGroups stack

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1767?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1767: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1778 > Exception on tab completion when adding new JGroups stack > --------------------------------------------------------- > > Key: WFCORE-1767 > URL: https://issues.jboss.org/browse/WFCORE-1767 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Jean-Francois Denise > > I just happened to catch the following exception: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{Exception in thread "Aesh Process Loop 1561063579" java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asType(ModelValue.java:147) > at org.jboss.dmr.ModelNode.asType(ModelNode.java:321) > at org.jboss.as.cli.impl.ValueTypeCompleter$ComplexInstance.isCompliantType(ValueTypeCompleter.java:239) > at org.jboss.as.cli.impl.ValueTypeCompleter$Instance.getType(ValueTypeCompleter.java:103) > at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:445) > at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74) > at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134) > at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) > at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) > at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155) > at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423) > at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) > at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773) > at org.jboss.aesh.console.Console.execute(Console.java:733) > at org.jboss.aesh.console.Console.access$900(Console.java:73) > at org.jboss.aesh.console.Console$6.run(Console.java:642) > 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) > {noformat} > when double tapping tab on the following: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{ > {noformat} > When trying a second time, it popped up again, so it is likely reproducible. Note that the server was started with: > {code} > ./standalone -c standalone-ha.xml > {code} > The exception killed the CLI. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1768) elytron module.xml, unnecessary exclude

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1768?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-1768: ------------------------------------- Ah yeah, I didn't notice the double wildfly. Definitely a typo. > elytron module.xml, unnecessary exclude > --------------------------------------- > > Key: WFCORE-1768 > URL: https://issues.jboss.org/browse/WFCORE-1768 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ] Mario Fusco commented on DROOLS-844: ------------------------------------ Please provide a reproducer or it will be impossible for me to investigate this issue. > Crash when node is deleted from query node > ------------------------------------------ > > Key: DROOLS-844 > URL: https://issues.jboss.org/browse/DROOLS-844 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Beta2 > Reporter: Fabian Meyer > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.4.0.Beta1 > > > When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException. > Exception in thread "Thread-6" java.lang.NullPointerException > at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176) > at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46) > at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360) > at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node

by Fabian Meyer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ] Fabian Meyer edited comment on DROOLS-844 at 9/6/16 9:19 AM: ------------------------------------------------------------- I've just been running some tests on 7.0.0.Snapshot and got a ClassCastException in "doLeftDeletes" : {code:java} Exception in thread "Thread-14" java.lang.ClassCastException: org.drools.core.reteoo.RightTupleImpl cannot be cast to org.drools.core.common.InternalFactHandle at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:120) at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:40) at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:435) at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:365) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:198) at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:141) at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:969) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1311) at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1231) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1395) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1374) {code} and a NPE in RuleNetworkEvaluator.deleteChildLeftTuple: {code:java} Exception in thread "Thread-14" java.lang.NullPointerException at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:725) at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:718) at org.drools.core.phreak.PhreakFromNode.doLeftDeletes(PhreakFromNode.java:248) at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:60) at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:355) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:573) at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:500) at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:969) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1311) at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1231) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1395) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1374) {code} The rule base makes use of queries, rules using the queries and logical inserts. was (Author: matrium): I've just been running some tests and got a ClassCastException in "doLeftDeletes" (7.0.0.Snapshot): Exception in thread "Thread-14" java.lang.ClassCastException: org.drools.core.reteoo.RightTupleImpl cannot be cast to org.drools.core.common.InternalFactHandle at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:120) at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:40) at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:435) at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:365) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:198) at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:141) at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:969) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1311) at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1231) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1395) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1374) The rule base makes use of queries, rules using the queries and logical inserts. > Crash when node is deleted from query node > ------------------------------------------ > > Key: DROOLS-844 > URL: https://issues.jboss.org/browse/DROOLS-844 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Beta2 > Reporter: Fabian Meyer > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.4.0.Beta1 > > > When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException. > Exception in thread "Thread-6" java.lang.NullPointerException > at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176) > at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46) > at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360) > at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node

by Fabian Meyer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ] Fabian Meyer reopened DROOLS-844: --------------------------------- > Crash when node is deleted from query node > ------------------------------------------ > > Key: DROOLS-844 > URL: https://issues.jboss.org/browse/DROOLS-844 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Beta2 > Reporter: Fabian Meyer > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.4.0.Beta1 > > > When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException. > Exception in thread "Thread-6" java.lang.NullPointerException > at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176) > at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46) > at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360) > at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node

by Fabian Meyer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ] Fabian Meyer commented on DROOLS-844: ------------------------------------- I've just been running some tests and got a ClassCastException in "doLeftDeletes" (7.0.0.Snapshot): Exception in thread "Thread-14" java.lang.ClassCastException: org.drools.core.reteoo.RightTupleImpl cannot be cast to org.drools.core.common.InternalFactHandle at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:120) at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:40) at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:435) at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:365) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:198) at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:141) at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:969) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1311) at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1231) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1395) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1374) The rule base makes use of queries, rules using the queries and logical inserts. > Crash when node is deleted from query node > ------------------------------------------ > > Key: DROOLS-844 > URL: https://issues.jboss.org/browse/DROOLS-844 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Beta2 > Reporter: Fabian Meyer > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.4.0.Beta1 > > > When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException. > Exception in thread "Thread-6" java.lang.NullPointerException > at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176) > at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46) > at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360) > at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1767) Exception on tab completion when adding new JGroups stack

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1767?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1767: -------------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) > Exception on tab completion when adding new JGroups stack > --------------------------------------------------------- > > Key: WFCORE-1767 > URL: https://issues.jboss.org/browse/WFCORE-1767 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Jean-Francois Denise > > I just happened to catch the following exception: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{Exception in thread "Aesh Process Loop 1561063579" java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asType(ModelValue.java:147) > at org.jboss.dmr.ModelNode.asType(ModelNode.java:321) > at org.jboss.as.cli.impl.ValueTypeCompleter$ComplexInstance.isCompliantType(ValueTypeCompleter.java:239) > at org.jboss.as.cli.impl.ValueTypeCompleter$Instance.getType(ValueTypeCompleter.java:103) > at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:445) > at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74) > at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134) > at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) > at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) > at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155) > at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423) > at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) > at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773) > at org.jboss.aesh.console.Console.execute(Console.java:733) > at org.jboss.aesh.console.Console.access$900(Console.java:73) > at org.jboss.aesh.console.Console$6.run(Console.java:642) > 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) > {noformat} > when double tapping tab on the following: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{ > {noformat} > When trying a second time, it popped up again, so it is likely reproducible. Note that the server was started with: > {code} > ./standalone -c standalone-ha.xml > {code} > The exception killed the CLI. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1768) elytron module.xml, unnecessary exclude

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1768?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFLY-7059 to WFCORE-1768: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1768 (was: WFLY-7059) Component/s: Security (was: Security) Affects Version/s: (was: 11.0.0.Alpha1) > elytron module.xml, unnecessary exclude > --------------------------------------- > > Key: WFCORE-1768 > URL: https://issues.jboss.org/browse/WFCORE-1768 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7061) Inconsistency of elytron security domains mapping

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7061?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7061: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Inconsistency of elytron security domains mapping > ------------------------------------------------- > > Key: WFLY-7061 > URL: https://issues.jboss.org/browse/WFLY-7061 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > Looking into wildfly-undertow_4_0.xsd and wildfly-ejb3_5_0.xsd .Both undertow and ejb subsystem enables to map deployment security domain to elytron security domain using application-security-domains element. > However, each in little different way, what could be IMHO misleading. > Ejb subsystem defines: > * name attribute for deployment security domain > * security-domain for elytron security domain > > Undertow subsystem defines: > * security-domain for deployment security domain > Could this be unified? > Also is it possible mention explicitly in comment in undertow subsystem, that elytron security domain is configured in http-authentication-factory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7061) Inconsistency of elytron security domains mapping

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7061?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-5890 to WFLY-7061: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7061 (was: JBEAP-5890) 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.DR4) > Inconsistency of elytron security domains mapping > ------------------------------------------------- > > Key: WFLY-7061 > URL: https://issues.jboss.org/browse/WFLY-7061 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > Looking into wildfly-undertow_4_0.xsd and wildfly-ejb3_5_0.xsd .Both undertow and ejb subsystem enables to map deployment security domain to elytron security domain using application-security-domains element. > However, each in little different way, what could be IMHO misleading. > Ejb subsystem defines: > * name attribute for deployment security domain > * security-domain for elytron security domain > > Undertow subsystem defines: > * security-domain for deployment security domain > Could this be unified? > Also is it possible mention explicitly in comment in undertow subsystem, that elytron security domain is configured in http-authentication-factory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ] Martin Choma edited comment on WFLY-7059 at 9/6/16 7:58 AM: ------------------------------------------------------------ I didn't find package org/wildfly/wildfly/security/manager/_private , sorry for not mentioning that in description. was (Author: mchoma): I didn't find package org/wildfly/wildfly/security/manager/_private . > elytron module.xml, unnecessary exclude > --------------------------------------- > > Key: WFLY-7059 > URL: https://issues.jboss.org/browse/WFLY-7059 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7059: ---------------------------------------- Looks like a typo - I will double check we exclude the correct ones. > elytron module.xml, unnecessary exclude > --------------------------------------- > > Key: WFLY-7059 > URL: https://issues.jboss.org/browse/WFLY-7059 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFLY-7059: ------------------------------------ I didn't find package org/wildfly/wildfly/security/manager/_private . > elytron module.xml, unnecessary exclude > --------------------------------------- > > Key: WFLY-7059 > URL: https://issues.jboss.org/browse/WFLY-7059 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-7059: ----------------------------------- Why unnecessary? We don't want to expose those packages as API. > elytron module.xml, unnecessary exclude > --------------------------------------- > > Key: WFLY-7059 > URL: https://issues.jboss.org/browse/WFLY-7059 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

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

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ] Stefano Maestri reassigned WFLY-7018: ------------------------------------- Assignee: Lin Gao (was: Stefano Maestri) This configuration is not valid because a connection property should be always needed w/ data source class. It's related to JBJCA-1312 and, in fact, it duplicates JBJCA-1320. Assigning to Lin (who was the assignee of both issues above) for a complete explanation of the new behaviour and, eventually, analysis of corner cases. > Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final > ------------------------------------------------------------------- > > Key: WFLY-7018 > URL: https://issues.jboss.org/browse/WFLY-7018 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Mark S > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7060) Elytron xsd is missing in docs/schema

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7060?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7060: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Elytron xsd is missing in docs/schema > ------------------------------------- > > Key: WFLY-7060 > URL: https://issues.jboss.org/browse/WFLY-7060 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > There is no related xsd to Elytron subsystem in docs/schema. It should be added. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7060) Elytron xsd is missing in docs/schema

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7060: ---------------------------------- Summary: Elytron xsd is missing in docs/schema Key: WFLY-7060 URL: https://issues.jboss.org/browse/WFLY-7060 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse There is no related xsd to Elytron subsystem in docs/schema. It should be added. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes

by Paul Pogonyshev (JIRA)

Paul Pogonyshev created JASSIST-263: --------------------------------------- Summary: ClassPool cannot read generated classes Key: JASSIST-263 URL: https://issues.jboss.org/browse/JASSIST-263 Project: Javassist Issue Type: Bug Affects Versions: 3.20.0-GA Reporter: Paul Pogonyshev Assignee: Shigeru Chiba Attachments: JavassistBug.java ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example. As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ] Stefano Maestri commented on JBJCA-1329: ---------------------------------------- I'll run TCK and I'll add a test case too updating PR > No error message on concurrent processing of the same inflow transaction > ------------------------------------------------------------------------ > > Key: JBJCA-1329 > URL: https://issues.jboss.org/browse/JBJCA-1329 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: WildFly/IronJacamar 1.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Stefano Maestri > Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log > > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages. > If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3]. > [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... > [2] > {code} > 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2] > {code} > [3] > {quote} > The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1767) Exception on tab completion when adding new JGroups stack

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1767?page=com.atlassian.jira.plugi... ] Alexey Loubyansky updated WFCORE-1767: -------------------------------------- Description: I just happened to catch the following exception: {noformat} [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{Exception in thread "Aesh Process Loop 1561063579" java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.asType(ModelValue.java:147) at org.jboss.dmr.ModelNode.asType(ModelNode.java:321) at org.jboss.as.cli.impl.ValueTypeCompleter$ComplexInstance.isCompliantType(ValueTypeCompleter.java:239) at org.jboss.as.cli.impl.ValueTypeCompleter$Instance.getType(ValueTypeCompleter.java:103) at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:445) at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332) at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254) at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74) at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134) at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155) at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423) at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773) at org.jboss.aesh.console.Console.execute(Console.java:733) at org.jboss.aesh.console.Console.access$900(Console.java:73) at org.jboss.aesh.console.Console$6.run(Console.java:642) 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) {noformat} when double tapping tab on the following: {noformat} [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{ {noformat} When trying a second time, it popped up again, so it is likely reproducible. Note that the server was started with: {code} ./standalone -c standalone-ha.xml {code} The exception killed the CLI. was: I just happened to catch the following exception: {noformat} Exception in thread "Aesh Process Loop 1360657223" java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.asType(ModelValue.java:147) at org.jboss.dmr.ModelNode.asType(ModelNode.java:321) at org.jboss.as.cli.impl.ValueTypeCompleter$ComplexInstance.isCompliantType(ValueTypeCompleter.java:236) at org.jboss.as.cli.impl.ValueTypeCompleter$Instance.getType(ValueTypeCompleter.java:100) at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:414) at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:323) at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254) at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74) at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134) at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:150) at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:420) at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) at org.jboss.aesh.console.Console.processInternalOperation(Console.java:767) at org.jboss.aesh.console.Console.execute(Console.java:727) at org.jboss.aesh.console.Console.access$900(Console.java:73) at org.jboss.aesh.console.Console$6.run(Console.java:636) 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) {noformat} when double tapping tab on the following: {noformat} [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{ {noformat} When trying a second time, it popped up again, so it is likely reproducible. Note that EAP was started with: {code} ./standalone -c standalone-ha.xml {code} and the EAP was in a different directory than the {{jboss-cli.sh}}, though I don't think that should matter. * EAP: $MYDIR/jboss-eap-7.1.0.DR3-playground/bin/standalone.sh * jboss-cli: $MYDIR/jboss-eap-7.1.0.DR3-clean/bin/jboss-cli.sh The exception killed the CLI. > Exception on tab completion when adding new JGroups stack > --------------------------------------------------------- > > Key: WFCORE-1767 > URL: https://issues.jboss.org/browse/WFCORE-1767 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > I just happened to catch the following exception: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{Exception in thread "Aesh Process Loop 1561063579" java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asType(ModelValue.java:147) > at org.jboss.dmr.ModelNode.asType(ModelNode.java:321) > at org.jboss.as.cli.impl.ValueTypeCompleter$ComplexInstance.isCompliantType(ValueTypeCompleter.java:239) > at org.jboss.as.cli.impl.ValueTypeCompleter$Instance.getType(ValueTypeCompleter.java:103) > at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:445) > at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74) > at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134) > at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) > at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) > at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155) > at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423) > at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) > at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773) > at org.jboss.aesh.console.Console.execute(Console.java:733) > at org.jboss.aesh.console.Console.access$900(Console.java:73) > at org.jboss.aesh.console.Console$6.run(Console.java:642) > 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) > {noformat} > when double tapping tab on the following: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{ > {noformat} > When trying a second time, it popped up again, so it is likely reproducible. Note that the server was started with: > {code} > ./standalone -c standalone-ha.xml > {code} > The exception killed the CLI. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1767) Exception on tab completion when adding new JGroups stack

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1767?page=com.atlassian.jira.plugi... ] Alexey Loubyansky moved JBEAP-5881 to WFCORE-1767: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1767 (was: JBEAP-5881) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Affects Version/s: (was: 7.1.0.DR3) > Exception on tab completion when adding new JGroups stack > --------------------------------------------------------- > > Key: WFCORE-1767 > URL: https://issues.jboss.org/browse/WFCORE-1767 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > I just happened to catch the following exception: > {noformat} > Exception in thread "Aesh Process Loop 1360657223" java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asType(ModelValue.java:147) > at org.jboss.dmr.ModelNode.asType(ModelNode.java:321) > at org.jboss.as.cli.impl.ValueTypeCompleter$ComplexInstance.isCompliantType(ValueTypeCompleter.java:236) > at org.jboss.as.cli.impl.ValueTypeCompleter$Instance.getType(ValueTypeCompleter.java:100) > at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:414) > at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:323) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74) > at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134) > at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) > at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) > at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:150) > at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:420) > at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) > at org.jboss.aesh.console.Console.processInternalOperation(Console.java:767) > at org.jboss.aesh.console.Console.execute(Console.java:727) > at org.jboss.aesh.console.Console.access$900(Console.java:73) > at org.jboss.aesh.console.Console$6.run(Console.java:636) > 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) > {noformat} > when double tapping tab on the following: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{ > {noformat} > When trying a second time, it popped up again, so it is likely reproducible. Note that EAP was started with: > {code} > ./standalone -c standalone-ha.xml > {code} > and the EAP was in a different directory than the {{jboss-cli.sh}}, though I don't think that should matter. > * EAP: $MYDIR/jboss-eap-7.1.0.DR3-playground/bin/standalone.sh > * jboss-cli: $MYDIR/jboss-eap-7.1.0.DR3-clean/bin/jboss-cli.sh > The exception killed the CLI. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache

by Gunther v. Wolffersdorff (JIRA)

[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ] Gunther v. Wolffersdorff updated WFLY-6596: ------------------------------------------- Attachment: sample-10.1.0.Final-fix.zip Sample app with {{de.alvara.ticket.sample.util.MyDefaultCacheKeysFactory}} as workaround. > WrongClassException when using infinispan as remote-store for hibernate entity cache > ------------------------------------------------------------------------------------ > > Key: WFLY-6596 > URL: https://issues.jboss.org/browse/WFLY-6596 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Java version: 1.8.0_45, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_45\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > Infifnspan 8.1.2 or 8.2.0 > Reporter: Gunther v. Wolffersdorff > Assignee: Scott Marlow > Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store > Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final-fix.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml > > > Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes: > {code} > 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66] > Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final] > at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:] > at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66] > at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > ... 43 more > Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > ... 58 more > {code} > Entity cache is configured like this: > {code:xml} > ... > <invalidation-cache name="entity" mode="SYNC"> > <eviction strategy="LRU" max-entries="1000"/> > <expiration lifespan="45000" max-idle="30000"/> > <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/> > </invalidation-cache> > ... > <outbound-socket-binding name="local-cache-server"> > <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/> > </outbound-socket-binding> > ... > {code} > see standalone.sample.ha-10.1.0.Final.xml . > *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-954) Microsoft Active Directory and Red Hat Directory Server fail on empty rolesCtxDN

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/SECURITY-954?page=com.atlassian.jira.plug... ] Tomas Hofman commented on SECURITY-954: --------------------------------------- PR: https://github.com/wildfly-security/jboss-negotiation/pull/33 > Microsoft Active Directory and Red Hat Directory Server fail on empty rolesCtxDN > -------------------------------------------------------------------------------- > > Key: SECURITY-954 > URL: https://issues.jboss.org/browse/SECURITY-954 > Project: PicketBox > Issue Type: Bug > Reporter: Tomas Hofman > Assignee: Tomas Hofman > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-954) Microsoft Active Directory and Red Hat Directory Server fail on empty rolesCtxDN

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/SECURITY-954?page=com.atlassian.jira.plug... ] Tomas Hofman moved JBEAP-5879 to SECURITY-954: ---------------------------------------------- Project: PicketBox (was: JBoss Enterprise Application Platform) Key: SECURITY-954 (was: JBEAP-5879) Workflow: classic default workflow (was: CDW with loose statuses v1) > Microsoft Active Directory and Red Hat Directory Server fail on empty rolesCtxDN > -------------------------------------------------------------------------------- > > Key: SECURITY-954 > URL: https://issues.jboss.org/browse/SECURITY-954 > Project: PicketBox > Issue Type: Bug > Reporter: Tomas Hofman > Assignee: Tomas Hofman > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7037) Memory leak when doing deploy/undeploy app using REST and JPA

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/WFLY-7037?page=com.atlassian.jira.plugin.... ] Tomas Remes commented on WFLY-7037: ----------------------------------- [~swd847] thanks for reporting the issue. > Memory leak when doing deploy/undeploy app using REST and JPA > ------------------------------------------------------------- > > Key: WFLY-7037 > URL: https://issues.jboss.org/browse/WFLY-7037 > Project: WildFly > Issue Type: Bug > Components: REST, XML Frameworks > Affects Versions: 10.1.0.Final > Reporter: Tomas Remes > Assignee: Stuart Douglas > Priority: Critical > Attachments: gc_path.png, mem-leak.zip > > > It seems that exposing some type (ApplicationUser in attached app) which has enum type as attribute via REST api could cause memory leak (See steps to reproduce). You can observe that person.joey.test.UserType instances are kept in memory when GC happens (metaspace exceeds) and the path to GC root looks: > !gc_path.png|thumbnail! > Note that this map https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.7.4... was not available in 2.5.4 version used in WF 10.0.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache

by Gunther v. Wolffersdorff (JIRA)

[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ] Gunther v. Wolffersdorff commented on WFLY-6596: ------------------------------------------------ [~sebersole] Using {{<property name="hibernate.cache.keys_factory" value="org.hibernate.cache.internal.DefaultCacheKeysFactory.INSTANCE" />}} in persistence.xml leads to {code} Caused by: org.hibernate.boot.registry.selector.spi.StrategySelectionException: Unable to resolve name [org.hibernate.cache.internal.DefaultCacheKeysFactory.INSTANCE] as strategy [org.hibernate.cache.spi.CacheKeysFactory] {code} at startup. Using {{<property name="hibernate.cache.keys_factory" value="org.hibernate.cache.internal.SimpleCacheKeysFactory" />}} brings no errors at startup but obviously does not solve the bug. A difference between SimpleCacheKeysFactory and DefaultCacheKeysFactory is that SimpleCacheKeysFactory implements CacheKeysFactory. So I wrote my own MyDefaultCacheKeysFactory based upon the DefaultCacheKeysFactory implementing CacheKeysFactory and configure it with {{<property name="hibernate.cache.keys_factory" value="de.alvara.ticket.sample.util.MyDefaultCacheKeysFactory" />}}. So no errors at startup and also the WrongClassExcption is gone. > WrongClassException when using infinispan as remote-store for hibernate entity cache > ------------------------------------------------------------------------------------ > > Key: WFLY-6596 > URL: https://issues.jboss.org/browse/WFLY-6596 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Java version: 1.8.0_45, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_45\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > Infifnspan 8.1.2 or 8.2.0 > Reporter: Gunther v. Wolffersdorff > Assignee: Scott Marlow > Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store > Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml > > > Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes: > {code} > 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66] > Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final] > at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:] > at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66] > at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > ... 43 more > Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > ... 58 more > {code} > Entity cache is configured like this: > {code:xml} > ... > <invalidation-cache name="entity" mode="SYNC"> > <eviction strategy="LRU" max-entries="1000"/> > <expiration lifespan="45000" max-idle="30000"/> > <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/> > </invalidation-cache> > ... > <outbound-socket-binding name="local-cache-server"> > <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/> > </outbound-socket-binding> > ... > {code} > see standalone.sample.ha-10.1.0.Final.xml . > *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ] Martin Choma reassigned WFLY-7059: ---------------------------------- Assignee: Darran Lofthouse > elytron module.xml, unnecessary exclude > --------------------------------------- > > Key: WFLY-7059 > URL: https://issues.jboss.org/browse/WFLY-7059 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-5878 to WFLY-7059: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7059 (was: JBEAP-5878) 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.DR4) > elytron module.xml, unnecessary exclude > --------------------------------------- > > Key: WFLY-7059 > URL: https://issues.jboss.org/browse/WFLY-7059 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > > in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat} > there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary. > {noformat} > <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron"> > <exports> > <exclude path="org/wildfly/security/_private"/> > <exclude path="org/wildfly/wildfly/security/manager/_private"/> > </exports> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1489) Expose (un)registerNotificationHandler() on OperationContext

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugi... ] Kabir Khan commented on WFCORE-1489: ------------------------------------ Assigning to Jeff. This might not be necessary, it was a hack I needed for the WIP on WFCORE-1157 and WFCORE-1405. If not necessary, please close it. > Expose (un)registerNotificationHandler() on OperationContext > ------------------------------------------------------------ > > Key: WFCORE-1489 > URL: https://issues.jboss.org/browse/WFCORE-1489 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Kabir Khan > Assignee: Jeff Mesnil > Fix For: 3.0.0.Beta1 > > > Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1489) Expose (un)registerNotificationHandler() on OperationContext

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugi... ] Kabir Khan reassigned WFCORE-1489: ---------------------------------- Assignee: Jeff Mesnil (was: Kabir Khan) > Expose (un)registerNotificationHandler() on OperationContext > ------------------------------------------------------------ > > Key: WFCORE-1489 > URL: https://issues.jboss.org/browse/WFCORE-1489 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Kabir Khan > Assignee: Jeff Mesnil > Fix For: 3.0.0.Beta1 > > > Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5542) Look into using apache's upstream JSTL

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-5542?page=com.atlassian.jira.plugin.... ] Rostislav Svoboda commented on WFLY-5542: ----------------------------------------- Tomaz , any update on 2 + 3 ? Radim, can you please ensure that 1 is not the case for 1.1 version ? > Look into using apache's upstream JSTL > -------------------------------------- > > Key: WFLY-5542 > URL: https://issues.jboss.org/browse/WFLY-5542 > Project: WildFly > Issue Type: Task > Components: EE, Web (Undertow) > Affects Versions: 10.0.0.CR2 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > We are now using forked combination of apache & java.net's version of JSTL. > We should look into using upstream version if possible. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1276) KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null)

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1276?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1276: ------------------------------------- Description: This works to get the default kieSession: {code} String ksessionName = null; // if ksessionName is null, then the default kieSession is used KieSessionModel kieSessionModel = kieContainer.getKieSessionModel(ksessionName); {code} But this doesn't work to get the default ksession: {code} String ksessionName = null; // Fails if ksessionName is null. Should return the default ksession instead. return kieContainer.newKieSession(ksessionName); {code} The above fails if ksessioName is null with this stacktrace: {code} java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:692) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:652) at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirectorFactory.newKieSession(DroolsScoreDirectorFactory.java:129) {code} If no default ksession exists with argument null, a nice error message should be thrown. was: This works to get the default kieSession: {code} // if ksessionName is null, then the default kieSession is used KieSessionModel kieSessionModel = kieContainer.getKieSessionModel(ksessionName); {code} But this doesn't: {code} // Fails if ksessionName is null. Should return the default ksession instead. return kieContainer.newKieSession(ksessionName); {code} The above fails if ksessioName is null with this stacktrace: {code} java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:692) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:652) at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirectorFactory.newKieSession(DroolsScoreDirectorFactory.java:129) {code} If no default ksession exists with argument null, a nice error message should be thrown. > KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null) > --------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1276 > URL: https://issues.jboss.org/browse/DROOLS-1276 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.CR1 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > This works to get the default kieSession: > {code} > String ksessionName = null; > // if ksessionName is null, then the default kieSession is used > KieSessionModel kieSessionModel = kieContainer.getKieSessionModel(ksessionName); > {code} > But this doesn't work to get the default ksession: > {code} > String ksessionName = null; > // Fails if ksessionName is null. Should return the default ksession instead. > return kieContainer.newKieSession(ksessionName); > {code} > The above fails if ksessioName is null with this stacktrace: > {code} > java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) > at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:692) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:652) > at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirectorFactory.newKieSession(DroolsScoreDirectorFactory.java:129) > {code} > If no default ksession exists with argument null, a nice error message should be thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1276) KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null)

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-1276: ---------------------------------------- Summary: KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null) Key: DROOLS-1276 URL: https://issues.jboss.org/browse/DROOLS-1276 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 6.5.0.CR1 Reporter: Geoffrey De Smet Assignee: Mario Fusco This works to get the default kieSession: {code} // if ksessionName is null, then the default kieSession is used KieSessionModel kieSessionModel = kieContainer.getKieSessionModel(ksessionName); {code} But this doesn't: {code} // Fails if ksessionName is null. Should return the default ksession instead. return kieContainer.newKieSession(ksessionName); {code} The above fails if ksessioName is null with this stacktrace: {code} java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:692) at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:652) at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirectorFactory.newKieSession(DroolsScoreDirectorFactory.java:129) {code} If no default ksession exists with argument null, a nice error message should be thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-157) InvocationTargetException when opening hibernate structure

by Yasuyuki Inoue (JIRA)

Yasuyuki Inoue created HIBERNATE-157: ---------------------------------------- Summary: InvocationTargetException when opening hibernate structure Key: HIBERNATE-157 URL: https://issues.jboss.org/browse/HIBERNATE-157 Project: Hibernate Integration Issue Type: Bug Environment: MacOS10.11.6(El Capitan), Eclipse4.6.0(Neon) Reporter: Yasuyuki Inoue Assignee: Steve Ebersole InvocationTargetException occured when opening existing Hibernate structure. !ENTRY org.hibernate.eclipse.console 4 2 2016-09-06 15:19:57.154 !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException !SUBENTRY 1 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154 !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException !STACK 0 java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:78) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105) at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272) at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63) at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108) at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270) at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72) ... 12 more Caused by: java.lang.NullPointerException at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36) ... 17 more !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154 !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException !STACK 0 java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:78) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105) at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272) at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63) at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108) at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270) at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72) ... 12 more Caused by: java.lang.NullPointerException at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36) ... 17 more !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154 !MESSAGE java.lang.reflect.InvocationTargetException: <no message> !STACK 0 java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105) at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272) at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63) at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108) at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270) at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.lang.NullPointerException at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36) ... 17 more Root exception: java.lang.NullPointerException at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105) at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272) at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63) at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108) at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270) at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154 !MESSAGE java.lang.NullPointerException: <no message> !STACK 0 java.lang.NullPointerException at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72) at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167) at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105) at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272) at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63) at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108) at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270) at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98) at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2047) Reduce number of threads in default configurations

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2047?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2047: -------------------------------- Defaults for timer: * min_threads: 0 * max_threads: 5 * no queue * rejection_policy: "abort". This causes a new thread to be created if the pool is exhausted (should never happen, just a 2nd line of defense) > Reduce number of threads in default configurations > -------------------------------------------------- > > Key: JGRP-2047 > URL: https://issues.jboss.org/browse/JGRP-2047 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > Reduce the defaults for thread pools that have no queue enabled. If no queue is enabled, we can set min-threads to 0 but have a keep-alive time of 30s or 60s. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7057) standalone-elytron.xml , unnecessary unsecure interface

by Martin Choma (JIRA)

Martin Choma created WFLY-7057: ---------------------------------- Summary: standalone-elytron.xml , unnecessary unsecure interface Key: WFLY-7057 URL: https://issues.jboss.org/browse/WFLY-7057 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 11.0.0.Alpha1 Reporter: Martin Choma Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 When I compare standalone-elytron.xml to standalone.xml, there is additional section {noformat} </interface>  <interface name="unsecure">  <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/> {noformat} Is it necessary? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7056) domain-elytron.xml, missing singelton subsystem, different ejb cache type

by Martin Choma (JIRA)

Martin Choma created WFLY-7056: ---------------------------------- Summary: domain-elytron.xml, missing singelton subsystem, different ejb cache type Key: WFLY-7056 URL: https://issues.jboss.org/browse/WFLY-7056 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 11.0.0.Alpha1 Reporter: Martin Choma Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 When I compare domain-elytron.xml to domain.xml, 1) There is missing org.wildfly.extension.clustering.singleton extension installed. 2) There is changed ejb cache configuration 1254c1129 < <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/> --- > <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7055) host-elytron.xml, different jvm settings, unnecesarry unsecure interface

by Martin Choma (JIRA)

Martin Choma created WFLY-7055: ---------------------------------- Summary: host-elytron.xml, different jvm settings, unnecesarry unsecure interface Key: WFLY-7055 URL: https://issues.jboss.org/browse/WFLY-7055 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 11.0.0.Alpha1 Reporter: Martin Choma Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 host-elytron.xml, different jvm settings, unnecesarry unsecure interface When I compare host-elytron.xml to host.xml, 1) jvm settings use permgen element 2) probably unnecesarry configuration of unsecure profile stays there Is it worth provide elytron-like host-master/host-slave configuration files for convenience? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7019) [11.0.x] Calling HttpServletRequest.logout() with single sign-on enabled only works every second time

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7019?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-7019: --------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/8326) Will be fixed by the upgrade to Undertow 1.4.1 https://github.com/wildfly/wildfly-core/pull/1776 > [11.0.x] Calling HttpServletRequest.logout() with single sign-on enabled only works every second time > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-7019 > URL: https://issues.jboss.org/browse/WFLY-7019 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 11.0.0.Alpha1 > Reporter: Richard Janík > Assignee: Stuart Douglas > > This issue has resurfaced with 11.0.0.Alpha1-SNAPSHOT. It has been previously reported and fixed in 10.1.0.Final. > See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect. This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. I'm adding our security team members as watchers. > I'm trying to create a test in the WildFly integration testsuite, but I'm currently failing ([1]). The test I have written is currently passing. I don't know why yet, but either the test is bad or there might be something specific about the issue. The reproducer from JBEAP-1282 still works (in other words, it is failing now that the issue has appeared again). > [1]: https://github.com/LittleJohnII/wildfly/blob/sso-logout/testsuite/integra... see testLogoutWithClusteredSSO -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1766) Undertow 1.4.1.Final

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-1766: -------------------------------------- Summary: Undertow 1.4.1.Final Key: WFCORE-1766 URL: https://issues.jboss.org/browse/WFCORE-1766 Project: WildFly Core Issue Type: Component Upgrade Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7054) Memory leak when doing deploy/undeploy app using REST and JPA

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7054: ------------------------------------ Summary: Memory leak when doing deploy/undeploy app using REST and JPA Key: WFLY-7054 URL: https://issues.jboss.org/browse/WFLY-7054 Project: WildFly Issue Type: Bug Components: REST, XML Frameworks Affects Versions: 10.1.0.Final Reporter: Tomas Remes Assignee: Stuart Douglas Priority: Critical It seems that exposing some type (ApplicationUser in attached app) which has enum type as attribute via REST api could cause memory leak (See steps to reproduce). You can observe that person.joey.test.UserType instances are kept in memory when GC happens (metaspace exceeds) and the path to GC root looks: !gc_path.png|thumbnail! Note that this map https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.7.4... was not available in 2.5.4 version used in WF 10.0.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache

by Steve Ebersole (JIRA)

[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ] Steve Ebersole commented on WFLY-6596: -------------------------------------- [~smarlow], [~rvansa] - any thoughts on why this is leading to a "shared cache region" strategy, rather than Hibernate's default "cache region per-entity-hierarchy" strategy? [~gvwolf3d] The thing to reference as a setting is {{org.hibernate.cache.internal.DefaultCacheKeysFactory#INSTANCE}}, not {{org.hibernate.cache.internal.DefaultCacheKeysFactory}} itself. > WrongClassException when using infinispan as remote-store for hibernate entity cache > ------------------------------------------------------------------------------------ > > Key: WFLY-6596 > URL: https://issues.jboss.org/browse/WFLY-6596 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Java version: 1.8.0_45, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_45\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > Infifnspan 8.1.2 or 8.2.0 > Reporter: Gunther v. Wolffersdorff > Assignee: Scott Marlow > Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store > Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml > > > Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes: > {code} > 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66] > Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final] > at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:] > at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66] > at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > ... 43 more > Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > ... 58 more > {code} > Entity cache is configured like this: > {code:xml} > ... > <invalidation-cache name="entity" mode="SYNC"> > <eviction strategy="LRU" max-entries="1000"/> > <expiration lifespan="45000" max-idle="30000"/> > <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/> > </invalidation-cache> > ... > <outbound-socket-binding name="local-cache-server"> > <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/> > </outbound-socket-binding> > ... > {code} > see standalone.sample.ha-10.1.0.Final.xml . > *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7037) Memory leak when doing deploy/undeploy app using REST and JPA

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7037?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-7037: -------------------------------------- https://github.com/FasterXML/jackson-databind/issues/1363 > Memory leak when doing deploy/undeploy app using REST and JPA > ------------------------------------------------------------- > > Key: WFLY-7037 > URL: https://issues.jboss.org/browse/WFLY-7037 > Project: WildFly > Issue Type: Bug > Components: REST, XML Frameworks > Affects Versions: 10.1.0.Final > Reporter: Tomas Remes > Assignee: Stuart Douglas > Priority: Critical > Attachments: gc_path.png, mem-leak.zip > > > It seems that exposing some type (ApplicationUser in attached app) which has enum type as attribute via REST api could cause memory leak (See steps to reproduce). You can observe that person.joey.test.UserType instances are kept in memory when GC happens (metaspace exceeds) and the path to GC root looks: > !gc_path.png|thumbnail! > Note that this map https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.7.4... was not available in 2.5.4 version used in WF 10.0.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6944) Encode session affinity using multiple routes, if supported by the load balancer

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6944?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6944: ------------------------------- Description: Currently, session affinity is specified as a single route, usually the primary owner of a session. However, if this node is not active (from the load balancer's perspective), then the load balancer will select another node of its choosing. This is less than ideal, since some nodes are more optimal than others. Better is to expression session affinity as an ordered list of nodes. The load balancer can then choose the 1st node in the list that is active, and cascade on failures accordingly. From the server's perspective, the affinity list should have the following order: 1. The primary owner 2. Any backup owners 3. The local node (if the local node is not an owner) There are a couple of ways a load balancer can indicate that it supports multiple routes. 1. Static configuration, e.g. routing="NONE|OWNER|LOCAL|RANKED" 2. Adding an HTTP header to a proxied request, which can be detected by the server handling the request #1 has the advantage of simplicity - but requires that users manually apply this configuration to gain optimal performance. This would also let us allow users (for even the single node affinity case) to toggle between local affinity or primary owner affinity, or even no routing. #2 has the advantage of applying this optimization automatically, but incurs the cost of an additional header to every request was: Currently, session affinity is specified as a single route, usually the primary owner of a session. However, if this node is not active (from the load balancer's perspective), then the load balancer will select another node of its choosing. This is less than ideal, since some nodes are more optimal than others. Better is to expression session affinity as an ordered list of nodes. The load balancer can then choose the 1st node in the list that is active, and cascade on failures accordingly. From the server's perspective, the affinity list should have the following order: 1. The primary owner 2. Any backup owners 3. The local node (if the local node is not an owner) There are a couple of ways a load balancer can indicate that it supports multiple routes. 1. Static configuration, e.g. routing="OWNER|LOCAL|RANKED" 2. Adding an HTTP header to a proxied request, which can be detected by the server handling the request #1 has the advantage of simplicity - but requires that users manually apply this configuration to gain optimal performance. This would also let us allow users (for even the single node affinity case) to toggle between local affinity or primary owner affinity, or even no routing. #2 has the advantage of applying this optimization automatically, but incurs the cost of an additional header to every request > Encode session affinity using multiple routes, if supported by the load balancer > -------------------------------------------------------------------------------- > > Key: WFLY-6944 > URL: https://issues.jboss.org/browse/WFLY-6944 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, session affinity is specified as a single route, usually the primary owner of a session. However, if this node is not active (from the load balancer's perspective), then the load balancer will select another node of its choosing. This is less than ideal, since some nodes are more optimal than others. Better is to expression session affinity as an ordered list of nodes. The load balancer can then choose the 1st node in the list that is active, and cascade on failures accordingly. From the server's perspective, the affinity list should have the following order: > 1. The primary owner > 2. Any backup owners > 3. The local node (if the local node is not an owner) > There are a couple of ways a load balancer can indicate that it supports multiple routes. > 1. Static configuration, e.g. routing="NONE|OWNER|LOCAL|RANKED" > 2. Adding an HTTP header to a proxied request, which can be detected by the server handling the request > #1 has the advantage of simplicity - but requires that users manually apply this configuration to gain optimal performance. This would also let us allow users (for even the single node affinity case) to toggle between local affinity or primary owner affinity, or even no routing. > #2 has the advantage of applying this optimization automatically, but incurs the cost of an additional header to every request -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7016) Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7016?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-7016. ------------------------------ Resolution: Rejected The web session cache is only intended for use with BATCH and NONE tx modes. > Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener > --------------------------------------------------------------------------------------------------- > > Key: WFLY-7016 > URL: https://issues.jboss.org/browse/WFLY-7016 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Matthew Casperson > Assignee: Paul Ferraro > > We have the following code in a ServletRequestListener: > {code} > final HttpSession httpSession = httpRequest.getSession(false); > {code} > This code is the line: > {code} > [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94) > {code} > in the stack trace below. > We have been running applications with this listener in WildFly 10 for months without any issues, but when we migrated to WildFly 10.1, Infinispan started throwing exceptions when opening the app for the first time. The exception doesn't always happen, but often enough to make WildFly 10.1 unusable. > The configuration was copied directly from WildFly 10 to WildFly 10.1, so there are no configuration changes between the two versions. > {code} > [Server:main-server] 2016-08-26 15:03:10+1000 ERROR [[io.undertow.request]] [[default task-32]] UT005023: Exception handling request to /app/retrieve_quote.jsp: java.lang.IllegalStateException: Transaction TransactionImple < ac, BasicAction: 0:ffff0a1617d4:6cdfa442:57bfb3cd:31b status: ActionStatus.COMMITTED > is not in a valid state to be invoking cache operations on. > [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395) > [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:351) > [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345) > [Server:main-server] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331) > [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43) > [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) > [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85) > [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43) > [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177) > [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154) > [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43) > [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114) > [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83) > [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85) > [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43) > [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) > [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85) > [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43) > [Server:main-server] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335) > [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411) > [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403) > [Server:main-server] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286) > [Server:main-server] at org.wildfly.clustering.server.registry.CacheRegistry.getEntry(CacheRegistry.java:128) > [Server:main-server] at org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:58) > [Server:main-server] at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48) > [Server:main-server] at org.wildfly.extension.undertow.session.CodecSessionConfig.findSessionId(CodecSessionConfig.java:60) > [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.findSessionId(ServletContextImpl.java:1084) > [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:778) > [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370) > [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:375) > [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94) > [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.requestInitialized(SessionInvalidatorListener.java:52) > [Server:main-server] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246) > [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291) > [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > [Server:main-server] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > [Server:main-server] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > [Server:main-server] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > [Server:main-server] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) > [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [Server:main-server] at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2069) UNICAST3: bypass or remove when running over TCP

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2069?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2069. ---------------------------- Resolution: Done > UNICAST3: bypass or remove when running over TCP > ------------------------------------------------ > > Key: JGRP-2069 > URL: https://issues.jboss.org/browse/JGRP-2069 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.11, 4.0 > > > When running over TCP as transport, UNICAST3 is still required: while TCP/IP retransmits messages reliably and also provides sender-FIFO ordering, the receiver's thread pool might be exhausted and thus the message might get rejected. > However, *if* the regular and OOB thread pools are disabled, we could actually bypass (or completely remove) UNICAST3. If messages get dropped by a protocol further up the stack, however, there will be no retransmission in this case. > SOLUTION: > * Document this behavior > * Emit an INFO message (or automatically bypass UNICAST3) when run over a TCP transport and both OOB and regular pools are disabled -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-1765: ----------------------------------- Assignee: ehsavoie Hugonnet (was: Jason Greene) > unclear NullPointerException if the deployment-scanner element is removed from the configuration > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1765 > URL: https://issues.jboss.org/browse/WFCORE-1765 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner > Affects Versions: 2.0.10.Final > Reporter: Wolf-Dieter Fink > Assignee: ehsavoie Hugonnet > Labels: deployment > > If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint. > Config: > {xml} > <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0"> >  > </subsystem> > {xml} > Log message: > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) > at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ] Tomaz Cerar moved WFLY-7052 to WFCORE-1765: ------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1765 (was: WFLY-7052) Component/s: Deployment Scanner (was: Server) Affects Version/s: 2.0.10.Final (was: 11.0.0.Alpha1) > unclear NullPointerException if the deployment-scanner element is removed from the configuration > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1765 > URL: https://issues.jboss.org/browse/WFCORE-1765 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner > Affects Versions: 2.0.10.Final > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > Labels: deployment > > If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint. > Config: > {xml} > <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0"> >  > </subsystem> > {xml} > Log message: > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) > at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7051) Minor clean up of 'urn:jboss:domain:undertow:4.0' schema.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7051?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7051: ---------------------------------------- Changes applied to this branch ready to be bundled in a PR upstream: - https://github.com/wildfly-security-incubator/wildfly/tree/elytron_phase_I > Minor clean up of 'urn:jboss:domain:undertow:4.0' schema. > --------------------------------------------------------- > > Key: WFLY-7051 > URL: https://issues.jboss.org/browse/WFLY-7051 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > The version 4.0 of the schema is slightly behind the recent changes in version 3.1 of the schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2075) SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2075?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2075. ---------------------------- Resolution: Done > SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers > ------------------------------------------------------- > > Key: JGRP-2075 > URL: https://issues.jboss.org/browse/JGRP-2075 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.11, 4.0 > > > Currently we use WeakHashMap, but should not, reasons outlined below. We could replace it with a LazyRemovalCache. Andrew's email refers to SecretKeys but this probably also applies to Ciphers. > Andrew Haley's email: > {quote} > TL/DR: Please don't use WeakReferences, SoftReferences, etc. to cache > any data which might point to native memory. In particular, never do > this with instances of java.security.Key. Instead, implement either > some kind of ageing strategy or a fixed-size cache. > ... > This is a warning to anybody who might cache crypto keys. > A customer has been having problems with the exhaustion of native > memory before the Java heap is full. It was fun trying to track down > the cause, but it's now happened several times to several customers, > and it's a serious problem for real-world usage in app servers. > PKCS#11 is a standard way to communicate between applications and > crypto libraries. There is a Java crypto provider which supports > PKCS#11. Some of our customers must use this provider in order to get > FIPS certification. > The problem is this: > A crypto key is a buffer in memory, allocated by the PKCS#11 native > library. It's accessed via a handle which is stored as an integer > field in a Java object. This Java object is a PhantomReference, so > when the garbage collector detects that a crypto key is no longer > reachable it is closed and the associated native memory is freed. > Modern garbage collectors don't much bother to process objects in the > old generation because it's not usually worthwhile. Thus, crypto keys > don't get recycled very quickly. They can pile up in the old > generation. This isn't a problem for the Java heap because the > objects containing the references to crypto keys are very small. > Unfortunately, the native side of a crypto key is much bigger, maybe > up to a thousand times bigger. So if we have 4000 stale crypto keys > in the heap that's not a problem, a few kbytes. But the native memory > may be a megabyte. > This problem is made even worse by Tomcat because it uses > SoftReferences to cache crypto keys. SoftReferences are processed > lazily, and maybe not at all until the Java heap runs out of memory. > Unfortunately it doesn't, but the machine runs out of native memory > instead. > We could solve this simply by making instances of PKCS#11 keys really > big Java objects by padding with dummy fields. Then, the GC would > collect them quickly. This does work but it seriously impacts > performance. Also, we could tweak the garbage collectors to clear out > stale references more enthusiastically, but this impacts performance > even more. There are some controls with the G1 collector which > process SoftReferences more aggressively and these help, but again at > the cost of performance. > Finally: the Shanandoah collector we're working on handles this > problem much better than the older collectors, but it's some > way off. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2075) SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2075?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2075 at 9/5/16 12:28 PM: --------------------------------------------------------- Simple solution: use {{BoundedHashMap}} with a fixed size. The max size is set via {{key_map_max_size}} was (Author: belaban): Simple solution: use {{BoundedHashMap}} with a fixed size. > SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers > ------------------------------------------------------- > > Key: JGRP-2075 > URL: https://issues.jboss.org/browse/JGRP-2075 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.11, 4.0 > > > Currently we use WeakHashMap, but should not, reasons outlined below. We could replace it with a LazyRemovalCache. Andrew's email refers to SecretKeys but this probably also applies to Ciphers. > Andrew Haley's email: > {quote} > TL/DR: Please don't use WeakReferences, SoftReferences, etc. to cache > any data which might point to native memory. In particular, never do > this with instances of java.security.Key. Instead, implement either > some kind of ageing strategy or a fixed-size cache. > ... > This is a warning to anybody who might cache crypto keys. > A customer has been having problems with the exhaustion of native > memory before the Java heap is full. It was fun trying to track down > the cause, but it's now happened several times to several customers, > and it's a serious problem for real-world usage in app servers. > PKCS#11 is a standard way to communicate between applications and > crypto libraries. There is a Java crypto provider which supports > PKCS#11. Some of our customers must use this provider in order to get > FIPS certification. > The problem is this: > A crypto key is a buffer in memory, allocated by the PKCS#11 native > library. It's accessed via a handle which is stored as an integer > field in a Java object. This Java object is a PhantomReference, so > when the garbage collector detects that a crypto key is no longer > reachable it is closed and the associated native memory is freed. > Modern garbage collectors don't much bother to process objects in the > old generation because it's not usually worthwhile. Thus, crypto keys > don't get recycled very quickly. They can pile up in the old > generation. This isn't a problem for the Java heap because the > objects containing the references to crypto keys are very small. > Unfortunately, the native side of a crypto key is much bigger, maybe > up to a thousand times bigger. So if we have 4000 stale crypto keys > in the heap that's not a problem, a few kbytes. But the native memory > may be a megabyte. > This problem is made even worse by Tomcat because it uses > SoftReferences to cache crypto keys. SoftReferences are processed > lazily, and maybe not at all until the Java heap runs out of memory. > Unfortunately it doesn't, but the machine runs out of native memory > instead. > We could solve this simply by making instances of PKCS#11 keys really > big Java objects by padding with dummy fields. Then, the GC would > collect them quickly. This does work but it seriously impacts > performance. Also, we could tweak the garbage collectors to clear out > stale references more enthusiastically, but this impacts performance > even more. There are some controls with the G1 collector which > process SoftReferences more aggressively and these help, but again at > the cost of performance. > Finally: the Shanandoah collector we're working on handles this > problem much better than the older collectors, but it's some > way off. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2075) SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2075?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2075: -------------------------------- Simple solution: use {{BoundedHashMap}} with a fixed size. > SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers > ------------------------------------------------------- > > Key: JGRP-2075 > URL: https://issues.jboss.org/browse/JGRP-2075 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.11, 4.0 > > > Currently we use WeakHashMap, but should not, reasons outlined below. We could replace it with a LazyRemovalCache. Andrew's email refers to SecretKeys but this probably also applies to Ciphers. > Andrew Haley's email: > {quote} > TL/DR: Please don't use WeakReferences, SoftReferences, etc. to cache > any data which might point to native memory. In particular, never do > this with instances of java.security.Key. Instead, implement either > some kind of ageing strategy or a fixed-size cache. > ... > This is a warning to anybody who might cache crypto keys. > A customer has been having problems with the exhaustion of native > memory before the Java heap is full. It was fun trying to track down > the cause, but it's now happened several times to several customers, > and it's a serious problem for real-world usage in app servers. > PKCS#11 is a standard way to communicate between applications and > crypto libraries. There is a Java crypto provider which supports > PKCS#11. Some of our customers must use this provider in order to get > FIPS certification. > The problem is this: > A crypto key is a buffer in memory, allocated by the PKCS#11 native > library. It's accessed via a handle which is stored as an integer > field in a Java object. This Java object is a PhantomReference, so > when the garbage collector detects that a crypto key is no longer > reachable it is closed and the associated native memory is freed. > Modern garbage collectors don't much bother to process objects in the > old generation because it's not usually worthwhile. Thus, crypto keys > don't get recycled very quickly. They can pile up in the old > generation. This isn't a problem for the Java heap because the > objects containing the references to crypto keys are very small. > Unfortunately, the native side of a crypto key is much bigger, maybe > up to a thousand times bigger. So if we have 4000 stale crypto keys > in the heap that's not a problem, a few kbytes. But the native memory > may be a megabyte. > This problem is made even worse by Tomcat because it uses > SoftReferences to cache crypto keys. SoftReferences are processed > lazily, and maybe not at all until the Java heap runs out of memory. > Unfortunately it doesn't, but the machine runs out of native memory > instead. > We could solve this simply by making instances of PKCS#11 keys really > big Java objects by padding with dummy fields. Then, the GC would > collect them quickly. This does work but it seriously impacts > performance. Also, we could tweak the garbage collectors to clear out > stale references more enthusiastically, but this impacts performance > even more. There are some controls with the G1 collector which > process SoftReferences more aggressively and these help, but again at > the cost of performance. > Finally: the Shanandoah collector we're working on handles this > problem much better than the older collectors, but it's some > way off. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7052) unclear NullPointerException if the deployment-scanner element is removed from the configuration

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7052: -------------------------------------- Summary: unclear NullPointerException if the deployment-scanner element is removed from the configuration Key: WFLY-7052 URL: https://issues.jboss.org/browse/WFLY-7052 Project: WildFly Issue Type: Bug Components: Server Affects Versions: 11.0.0.Alpha1 Reporter: Wolf-Dieter Fink Assignee: Jason Greene If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint. Config: {xml} <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">  </subsystem> {xml} Log message: ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7053) unclear NullPointerException if the deployment-scanner element is removed from the configuration

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7053: -------------------------------------- Summary: unclear NullPointerException if the deployment-scanner element is removed from the configuration Key: WFLY-7053 URL: https://issues.jboss.org/browse/WFLY-7053 Project: WildFly Issue Type: Bug Components: Server Affects Versions: 11.0.0.Alpha1 Reporter: Wolf-Dieter Fink Assignee: Jason Greene If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint. Config: {xml} <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">  </subsystem> {xml} Log message: ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying dataSource object directly (e.g. via after_creation_hook)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2063. ---------------------------- Resolution: Done > JDBC_PING: allow supplying dataSource object directly (e.g. via after_creation_hook) > ------------------------------------------------------------------------------------ > > Key: JGRP-2063 > URL: https://issues.jboss.org/browse/JGRP-2063 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.9 > Reporter: Radoslav Husar > Assignee: Bela Ban > Fix For: 4.1 > > > See WFLY-6599. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying dataSource object directly (e.g. via after_creation_hook)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.... ] Bela Ban reopened JGRP-2063: ---------------------------- > JDBC_PING: allow supplying dataSource object directly (e.g. via after_creation_hook) > ------------------------------------------------------------------------------------ > > Key: JGRP-2063 > URL: https://issues.jboss.org/browse/JGRP-2063 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.9 > Reporter: Radoslav Husar > Assignee: Bela Ban > Fix For: 4.1 > > > See WFLY-6599. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2054) Documentation for 4.0

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2054?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2054. ---------------------------- Resolution: Done The manual for 4.x is now found at http://www.jgroups.org/manual4/index.html > Documentation for 4.0 > --------------------- > > Key: JGRP-2054 > URL: https://issues.jboss.org/browse/JGRP-2054 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > * Should use a separate URL, e.g. http://www.jgroups.org/manual/4/index.html > * Update documentation, code snippets need to be changed -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich edited comment on WFLY-6127 at 9/5/16 12:09 PM: ----------------------------------------------------------------------- *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 ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization. *FIX:* We created 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... Corrections: The method getSynchronizationType returns declared synchronization type. *Effect:* We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction. Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService call. This requires the declaration of synchronized persistence context. We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans. However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check. *Our actions:* We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual state of synchronization). This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false. Commit: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... *Commentary:* Though our actions deviate from JPA SPEC, we have a valid reason for acting this way: - A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?". Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was also closed too: "No feedback in favor of changing current approach" was (Author: veselroger): *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 ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization. *FIX:* We created 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... Corrections: The method getSynchronizationType returns declared synchronization type. *Effect:* We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction. Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService call. This requires the declaration of synchronized persistence context. We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans. However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check. *Our actions:* We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization). This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false. Commit: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... *Commentary:* Though our actions deviate from JPA SPEC, we have a valid reason for acting this way: - A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?". Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was also closed too: "No feedback in favor of changing current approach" > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7051) Minor clean up of 'urn:jboss:domain:undertow:4.0' schema.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-7051: -------------------------------------- Summary: Minor clean up of 'urn:jboss:domain:undertow:4.0' schema. Key: WFLY-7051 URL: https://issues.jboss.org/browse/WFLY-7051 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 The version 4.0 of the schema is slightly behind the recent changes in version 3.1 of the schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by kostd kostd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] kostd kostd commented on WFLY-6127: ----------------------------------- [~smarlow], can you accept [~veselroger] `s commit (which adds the jboss.as.jpa.syncasjoin option and "relaxed" check against current.isJoined instead of current.getSyncType() == Synchronized)? JCP process seems stopped (https://javaee-guardians.io/lack-of-java-ee-8-progress/) and our feedback to Linda is too late :( What we can do to you able to accept? may be some ut or something like that? We can rework to take your comments. > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7050) JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException

by Konstantin Glazkov (JIRA)

[ https://issues.jboss.org/browse/WFLY-7050?page=com.atlassian.jira.plugin.... ] Konstantin Glazkov updated WFLY-7050: ------------------------------------- Steps to Reproduce: ostream.write_string (""); ostream.write_char (' '); JUnit test is in attachment "empty_string_followed_by_char_conversion_unit_test.patch" was: ostream.write_string (""); ostream.write_char (' '); JUnit test is in attachment "empty_string_followed_by_char_conversion_unit_test_fix.patch" > JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-7050 > URL: https://issues.jboss.org/browse/WFLY-7050 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 10.1.0.Final > Reporter: Konstantin Glazkov > Assignee: Tomasz Adamski > Attachments: empty_string_followed_by_char_conversion_suggested_fix.patch, empty_string_followed_by_char_conversion_unit_test.patch, empty_string_followed_by_char_conversion_unit_test_fix.patch > > > If IDL structure contains string and char fields, and generated *Helper#write method looks like > ostream.write_string (value.string_field); //empty string > ostream.write_char (value.char_field); //any char > without non-empty strings before char field, then write_char method will fail with stacktrace: > Caused by: java.lang.ArrayIndexOutOfBoundsException: 0 > at com.sun.corba.se.impl.encoding.CodeSetConversion$JavaCTBConverter.convert(CodeSetConversion.java:206) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final] > at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_char(CDROutputStream_1_0.java:318) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final] > at com.sun.corba.se.impl.encoding.CDROutputStream.write_char(CDROutputStream.java:138) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final] > at SomeClassHelper.write(SomeClassHelper.java:<some line>) > Suggested fix is in attachment "empty_string_followed_by_char_conversion_suggested_fix.patch" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7050) JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException

by Konstantin Glazkov (JIRA)

[ https://issues.jboss.org/browse/WFLY-7050?page=com.atlassian.jira.plugin.... ] Konstantin Glazkov updated WFLY-7050: ------------------------------------- Attachment: empty_string_followed_by_char_conversion_unit_test.patch > JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-7050 > URL: https://issues.jboss.org/browse/WFLY-7050 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 10.1.0.Final > Reporter: Konstantin Glazkov > Assignee: Tomasz Adamski > Attachments: empty_string_followed_by_char_conversion_suggested_fix.patch, empty_string_followed_by_char_conversion_unit_test.patch, empty_string_followed_by_char_conversion_unit_test_fix.patch > > > If IDL structure contains string and char fields, and generated *Helper#write method looks like > ostream.write_string (value.string_field); //empty string > ostream.write_char (value.char_field); //any char > without non-empty strings before char field, then write_char method will fail with stacktrace: > Caused by: java.lang.ArrayIndexOutOfBoundsException: 0 > at com.sun.corba.se.impl.encoding.CodeSetConversion$JavaCTBConverter.convert(CodeSetConversion.java:206) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final] > at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_char(CDROutputStream_1_0.java:318) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final] > at com.sun.corba.se.impl.encoding.CDROutputStream.write_char(CDROutputStream.java:138) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final] > at SomeClassHelper.write(SomeClassHelper.java:<some line>) > Suggested fix is in attachment "empty_string_followed_by_char_conversion_suggested_fix.patch" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich edited comment on WFLY-6127 at 9/5/16 11:54 AM: ----------------------------------------------------------------------- *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 ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization. *FIX:* We created 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... Corrections: The method getSynchronizationType returns declared synchronization type. *Effect:* We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction. Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService call. This requires the declaration of synchronized persistence context. We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans. However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check. *Our actions:* We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization). This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false. Commit: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... *Commentary:* Though our actions deviate from JPA SPEC, we have a valid reason for acting this way: - A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?". Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was also closed too: "No feedback in favor of changing current approach" was (Author: veselroger): *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 ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization. *FIX:* We created 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... Corrections: The method getSynchronizationType returns declared synchronization type. *Effect:* We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction. Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService. This requires the declaration of synchronized persistence context. We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans. However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check. *Our actions:* We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization). This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false. *Commentary:* Though our actions deviate from JPA SPEC, we have a valid reason for acting this way: - A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?". Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was also closed too: "No feedback in favor of changing current approach" > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7050) JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException

by Konstantin Glazkov (JIRA)

Konstantin Glazkov created WFLY-7050: ---------------------------------------- Summary: JDK ORB char conversion preceeded by empty string conversion fails with ArrayIndexOutOfBoundsException Key: WFLY-7050 URL: https://issues.jboss.org/browse/WFLY-7050 Project: WildFly Issue Type: Bug Components: IIOP Affects Versions: 10.1.0.Final Reporter: Konstantin Glazkov Assignee: Tomasz Adamski Attachments: empty_string_followed_by_char_conversion_suggested_fix.patch, empty_string_followed_by_char_conversion_unit_test_fix.patch If IDL structure contains string and char fields, and generated *Helper#write method looks like ostream.write_string (value.string_field); //empty string ostream.write_char (value.char_field); //any char without non-empty strings before char field, then write_char method will fail with stacktrace: Caused by: java.lang.ArrayIndexOutOfBoundsException: 0 at com.sun.corba.se.impl.encoding.CodeSetConversion$JavaCTBConverter.convert(CodeSetConversion.java:206) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final] at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_char(CDROutputStream_1_0.java:318) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final] at com.sun.corba.se.impl.encoding.CDROutputStream.write_char(CDROutputStream.java:138) [openjdk-orb-8.0.6.Final.jar:8.0.6.Final] at SomeClassHelper.write(SomeClassHelper.java:<some line>) Suggested fix is in attachment "empty_string_followed_by_char_conversion_suggested_fix.patch" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich edited comment on WFLY-6127 at 9/5/16 11:51 AM: ----------------------------------------------------------------------- *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 ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization. *FIX:* We created 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... Corrections: The method getSynchronizationType returns declared synchronization type. *Effect:* We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction. Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService. This requires the declaration of synchronized persistence context. We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans. However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check. *Our actions:* We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization). This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false. *Commentary:* Though our actions deviate from JPA SPEC, we have a valid reason for acting this way: - A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?". Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was also closed too: "No feedback in favor of changing current approach" was (Author: veselroger): *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 ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization. *FIX:* We created 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... Corrections: The method getSynchronizationType returns declared synchronization type. *Effect:* We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction. Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService. This requires the declaration of synchronized persistence context. We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans. However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check. *Our actions:* We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization). This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false. *Commentary:* Though our actions deviate from JPA SPEC, we have a valid reason for acting this way: - A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?". Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We also found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was closed too because "No feedback in favor of changing current approach" > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich commented on WFLY-6127: ---------------------------------------------- *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 ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization. *FIX:* We created 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... Corrections: The method getSynchronizationType returns declared synchronization type. *Effect:* We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction. Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService. This requires the declaration of synchronized persistence context. We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans. However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check. *Our actions:* We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization). This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false. *Commentary:* Though our actions deviate from JPA SPEC, we have a valid reason for acting this way: - A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?". Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We also found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was closed too because "No feedback in favor of changing current approach" > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-184) gpd.xml incorrect with non-ascii characters like Chinese

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-184?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-184. --------------------------- Resolution: Out of Date > gpd.xml incorrect with non-ascii characters like Chinese > -------------------------------------------------------- > > Key: GPD-184 > URL: https://issues.jboss.org/browse/GPD-184 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.0.SP1 > Environment: Eclipse WTP 1.5 with JDK 1.6 > Windows XP Home SP2 > Reporter: lazing wong > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > Attachments: gpd-184.diff, screenshot-1.jpg > > > When named the node with non-ascii character like ?? > the generated gdp.xml is human unreadable. (not proper UTF-8 file) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7049) Support for Elytron-based SSO to Undertow Subsystem

by Pedro Igor (JIRA)

Pedro Igor created WFLY-7049: -------------------------------- Summary: Support for Elytron-based SSO to Undertow Subsystem Key: WFLY-7049 URL: https://issues.jboss.org/browse/WFLY-7049 Project: WildFly Issue Type: Feature Request Components: Security Affects Versions: 10.1.0.Final Reporter: Pedro Igor Assignee: Pedro Igor Add support for Elytron-based SSO to Undertow Subsystem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-98) GPD creates invalid gpd.xml when nodes contain special characters on Windows

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-98?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-98. -------------------------- Resolution: Out of Date > GPD creates invalid gpd.xml when nodes contain special characters on Windows > ----------------------------------------------------------------------------- > > Key: GPD-98 > URL: https://issues.jboss.org/browse/GPD-98 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.0.13, jBPM JPDL Designer 3.1.0.alpha4 > Environment: Windows XP, Eclipse 3.2.1 > Reporter: Martin Weiler > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > Attachments: processdefintion.xml > > > A process with a node containing a special character, such as <start-state name="Début">, leads to an invalid gpd.xml. This is reproducible with the attached sample processdefinition.xml on a Windows machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-399) switching between source and diagram duplicates text tag

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-399?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-399. --------------------------- Resolution: Out of Date > switching between source and diagram duplicates text tag > -------------------------------------------------------- > > Key: GPD-399 > URL: https://issues.jboss.org/browse/GPD-399 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 4.4 > Environment: Eclipse 3.6, Windows 7 > Reporter: Veiko Vaade > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.5 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7047) host-elytron.xml, different jvm settings, unnecesarry unsecure interface

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7047?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7047: ---------------------------------------- Once we reach phase IV of these pull requests I am hoping to completely eliminate these *-elytron.xml configuration files and move Elytron over to the main default configuration of a clean server so for now I don't think it will be beneficial to create forks of the additional host-* files. Phase III may temporarily introduce them as that is where full management integration will come in so they may be application and then depending on what happens in Phase IV we can have a closer look at the default files then. > host-elytron.xml, different jvm settings, unnecesarry unsecure interface > ------------------------------------------------------------------------ > > Key: WFLY-7047 > URL: https://issues.jboss.org/browse/WFLY-7047 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > host-elytron.xml, different jvm settings, unnecesarry unsecure interface > When I compare host-elytron.xml to host.xml, > 1) jvm settings use permgen element > 2) probably unnecesarry configuration of unsecure profile stays there > Is it worth provide elytron-like host-master/host-slave configuration files for convenience? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-395) Fields for decision handlers are lost

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-395?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-395. --------------------------- Resolution: Out of Date > Fields for decision handlers are lost > ------------------------------------- > > Key: GPD-395 > URL: https://issues.jboss.org/browse/GPD-395 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > Attachments: GPD-395.patch > > > see jBPM-380 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-378) Extend GPD to make it possible to set a task description

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-378?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-378. --------------------------- Resolution: Out of Date > Extend GPD to make it possible to set a task description > -------------------------------------------------------- > > Key: GPD-378 > URL: https://issues.jboss.org/browse/GPD-378 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Environment: not relevant > Reporter: Sebastian Schneider > Assignee: Koen Aers > Labels: description, task > Fix For: jBPM jPDL Designer 4.x > > > At the moment it is not possible to set the task description of a task in the GPD. This is due to 2 things. The task description attribute was forgotten in the jPDL schema definition and there is no field for the description of task when you click on properties in the GPD having a task selected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-389) Add more Items into Eclipse Property View

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-389?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-389. --------------------------- Resolution: Out of Date > Add more Items into Eclipse Property View > ----------------------------------------- > > Key: GPD-389 > URL: https://issues.jboss.org/browse/GPD-389 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 4.3, jBPM jPDL Designer 4.4 > Environment: JBPM 4.3 Eclipse Plugin > Reporter: Daniel Schaaf > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > Attachments: humanTask-javaTask.patch, transition-condition.patch > > > Hello to the jBOSS Developers Community. > There is a small missing feature in the JBPM GPD Eclipse Plugin, which makes our work together with the business side really hard. The expectation of the business side is to view (and perhaps one time alter) Workflow definitions graphically. To analyse and work with XML Code is not acceptable for them. > Though the Flow Graphs already look impressing, real work on this level is not possible because of the poor functionality of the Properties View. > Out of my point of view it should be a little change to provide here some additional information and functionality, which would bring us forward a big step: > Can you add the following Properties for the Workflow Items: > For Tasks: Form, DueDate, Notification Template; Assignment handler > For Java: A possibility to see and add a variable number of method arguments > For Transitions: Timer duedate (it´s there but only named timer); repeat and condition is missing > For Subprocesses: Parameter in; Parameter out each with var and subvar. > For Java Tasks: arg and field parameters > For Custom Tasks: field parameters > I know, that this set is not complete, but the actual is definitely too small for working and I think the once I suggested to add will enable a better Business Analyst work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-25) Saving processdefinition should add problem markers and entries in problem view if any problems occur

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-25?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-25. -------------------------- Resolution: Out of Date > Saving processdefinition should add problem markers and entries in problem view if any problems occur > ----------------------------------------------------------------------------------------------------- > > Key: GPD-25 > URL: https://issues.jboss.org/browse/GPD-25 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-397) Properly initialize the node and the two Connections when a dropping an activity on a connection.

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-397?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-397. --------------------------- Resolution: Out of Date > Properly initialize the node and the two Connections when a dropping an activity on a connection. > ------------------------------------------------------------------------------------------------- > > Key: GPD-397 > URL: https://issues.jboss.org/browse/GPD-397 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > The dropped activity has no name and neither has the first connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-308) prevent empty names

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-308?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-308. --------------------------- Resolution: Out of Date > prevent empty names > ------------------- > > Key: GPD-308 > URL: https://issues.jboss.org/browse/GPD-308 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Tom Baeyens > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > in end state example, i see you generated an empty name. that should be prevented if possible. the fact that this still parses without exception is actually a bug. > <process name="EndState" xmlns="http://jbpm.org/4/jpdl"> > <start g="16,96,48,48"> > <transition to="get return code" name=""/> > </start> > <state g="96,94,110,52" name="get return code"> > <transition g="150,63:-36,11" name="200" to="ok"/> > <transition g=":-16,-27" name="400" to="bad request"/> > <transition g="150,177:-33,-32" name="500" to="internal server error"/> > </state> > <end g="239,40,48,48" name="ok" state="completed"/> > <end-cancel g="239,97,48,48" name="bad request"/> > <end-error g="240,154,48,48" name="internal server error"/> > </process> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-388) GPD generates text which is surrunded by tab/newline for action handler's Config Info even if config-type="constructor" or "configuration-property"

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-388?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-388. --------------------------- Resolution: Out of Date > GPD generates text which is surrunded by tab/newline for action handler's Config Info even if config-type="constructor" or "configuration-property" > --------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: GPD-388 > URL: https://issues.jboss.org/browse/GPD-388 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.7 > Reporter: Toshiya Kobayashi > Assignee: Koen Aers > Priority: Minor > > 1. Create and select a node in GPD editor > 2. Set Action Handler in Properties View > 3. Set "Config Type" SelectBox to "Constructor" or "Compatibility" > 4. Set value like "Test" into the "Config Info" TextArea > 5. See the source xml contains value "Test" surrounded by tab/newline > <action class="ActionHandler" config-type="constructor"> > Test > </action> > On jBPM runtime engine side, config-type="constructor" or "configuration-property" indicates the action handler to take the complete text in xml without trimming [1]. > This leads to unexpected result for users -- even if they understand that config-type="constructor" doesn't trim the text in jBPM runtime, they don't expect that GPD adds tab/newline to the input text. Better behavior would be trimming the input text in TextArea by GPD before passing it to xml. > <action class="ActionHandler" config-type="constructor">Test</action> > [1] http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/4.3.CP02/html-single/... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-391) Limit assignment operation for Start Task

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-391?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-391. --------------------------- Resolution: Out of Date > Limit assignment operation for Start Task > ----------------------------------------- > > Key: GPD-391 > URL: https://issues.jboss.org/browse/GPD-391 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.7 > Reporter: Toshiya Kobayashi > Assignee: Koen Aers > Priority: Minor > Attachments: assignment_for_start_task.png > > > TaskMgmtInstance#createStartTaskInstance() fills actorId with authenticatedActorId regardless <assignment> settings in <task> in <start-state>. > But currently GPD allows users to assign the start task (e.g. to actor). It's useless and confuses them. See attached screen shot. > So this request is "In case of Start State, only 'Swimlane' should be selectable in Task -> Assignment tab." -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-392) Force a transition to have its name in case of Fork

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-392?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-392. --------------------------- Resolution: Out of Date > Force a transition to have its name in case of Fork > --------------------------------------------------- > > Key: GPD-392 > URL: https://issues.jboss.org/browse/GPD-392 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.7, jBPM jPDL Designer 3.2 > Reporter: Toshiya Kobayashi > Assignee: Koen Aers > > When you add transitions from a fork to nodes, GPD omits the name of the first transition. > <fork name="fork1"> > <transition to="node1" ></transition> > <transition to="node2" name="to node2"></transition> > <transition to="node3" name="to node3"></transition> > </fork> > This works without problem. Tokens go to node1, node2, node3. > But, after some modification, you may have a process definition like: > <fork name="fork1"> > <transition to="node1" name="to node1"></transition> > <transition to="node2" ></transition> > <transition to="node3" name="to node3"></transition> > </fork> > In this case, tokens go to node1, node1, node3. > Because if there is a transition without name, the child token goes to default leaving transition (in this case, node1). > This problem may be fixed on jBPM side, but forcing a transition to have its name on GDP side will help users avoid such odd process definition. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-387) Config Info of Decision Handler is lost after re-opening GPD editor

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-387?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-387. --------------------------- Resolution: Out of Date > Config Info of Decision Handler is lost after re-opening GPD editor > ------------------------------------------------------------------- > > Key: GPD-387 > URL: https://issues.jboss.org/browse/GPD-387 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.7 > Reporter: Toshiya Kobayashi > Assignee: Koen Aers > Attachments: 01_configure_properties.png, 02_after_reopen.png > > > 1. Create and select a decision node in GPD editor > 2. Set Decision Handler in Properties View > 3. Set Config Info of the handler ( 01_configure_properties.png ) > 4. Close and open the GPD editor > 5. Select the decision node and see the handler's Config Info is lost in Properties View ( 02_after_reopen.png ) > Actually the config info exists in xml. If you set Config Info in Properties View again, there will be duplicate entries in xml. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-302) Generate Form Dialog is NOT auto-populated with controller variables or named transitions

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-302?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-302. --------------------------- Resolution: Out of Date > Generate Form Dialog is NOT auto-populated with controller variables or named transitions > ----------------------------------------------------------------------------------------- > > Key: GPD-302 > URL: https://issues.jboss.org/browse/GPD-302 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.6 > Environment: Eclipse 3.1.4 w/ jBPM 3.3.1.GA w/ GPD 3.1.6 > Reporter: Nobody Cares > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 3.x > > > The launched dialog of a task's "Generate Form..." button is NOT automatically populated with the task's defined controller variables nor with buttons that correspond to the task's named transitions. This issue significantly hinders the usefulness of the GPD. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-386) script tag lost

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-386?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-386. --------------------------- Resolution: Out of Date > script tag lost > --------------- > > Key: GPD-386 > URL: https://issues.jboss.org/browse/GPD-386 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 4.1, jBPM jPDL Designer 4.3 > Reporter: Evgenij Dolganov > Assignee: Koen Aers > > When manually adding 'script' tag to 'transition' or task's 'on' in the XML, this tag is lost after having saved, gone back to the diagram and back to the xml. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-390) CLONE -GPD Diagram node and text positioning not saving.

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-390?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-390. --------------------------- Resolution: Out of Date > CLONE -GPD Diagram node and text positioning not saving. > -------------------------------------------------------- > > Key: GPD-390 > URL: https://issues.jboss.org/browse/GPD-390 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.7 > Environment: Eclipse 3.4, jbpm-jpdl-designer-3.1.4 > Reporter: Markus Kopka > Assignee: Koen Aers > > Using jbpm-jpdl-designer-3.1.4 gives me the following problem: > Sometimes when re-opening a process definition with the GPD, my nodes are jumbled up and placed at random locations. So there is this web of transition lines running everywhere to reach the nodes. You can't see what's going on. Sometimes I open my process definition in the GPD to work with it, I have to re-aligning everything. > This does not affect any configuration of nodes or the classes. But it becomes impossible to understand > the process flow from the diagram -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-358) Create jBPM Project Configuration Wizard

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-358?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-358. --------------------------- Resolution: Out of Date > Create jBPM Project Configuration Wizard > ---------------------------------------- > > Key: GPD-358 > URL: https://issues.jboss.org/browse/GPD-358 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. > A project configuration will offered and includes > - a selection of the configured jBPM runtimes > - a checkbox to import all the jBPM Libraries > Also, this includes that the 'create jBPM project' wizard in GPD 3.x will be eliminated -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-382) Add support for globalProcessScope and process-scope parameters in EsbActionHandler and EsbNotifier

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-382?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-382. --------------------------- Resolution: Out of Date > Add support for globalProcessScope and process-scope parameters in EsbActionHandler and EsbNotifier > --------------------------------------------------------------------------------------------------- > > Key: GPD-382 > URL: https://issues.jboss.org/browse/GPD-382 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.7 > Reporter: Jiri Pechanec > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > See http://documentation-stage.bne.redhat.com/docs/en-US/JBoss_Enterprise_SOA... > It should be probably implemented as three-state widget (listbox) called that will contain empty value (default), process and local -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-385) Deployment of processes including Java classes fails if the workspace path contains spaces

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-385?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-385. --------------------------- Resolution: Out of Date > Deployment of processes including Java classes fails if the workspace path contains spaces > ------------------------------------------------------------------------------------------ > > Key: GPD-385 > URL: https://issues.jboss.org/browse/GPD-385 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.7 > Environment: - JBDS on Windows or Linux > - workspace path contains spaces > Reporter: Martin Weiler > Assignee: Koen Aers > > 1. Use a workspace which contains spaces > 2. Create a new jBPM project with the default process and action handler classes > 3. Open the processdefinition and go to the Deployment tab > 4. Make sure the ActionHandler class is included in the deployment > 5. Hit 'Deploy Process Archive...' > ERROR: Exception happened while deploying > Exception Stack Trace (from Error Log): > java.lang.NullPointerException > at org.jbpm.gd.jpdl.util.ProcessDeployer.addClassOrResource(Unknown Source) > at org.jbpm.gd.jpdl.util.ProcessDeployer.addClassesAndResources(Unknown Source) > at org.jbpm.gd.jpdl.util.ProcessDeployer.createParBytes(Unknown Source) > at org.jbpm.gd.jpdl.util.ProcessDeployer.access$1(Unknown Source) > at org.jbpm.gd.jpdl.util.ProcessDeployer$1.run(Unknown Source) > at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464) > at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372) > at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:507) > at org.jbpm.gd.jpdl.util.ProcessDeployer.showProgressMonitorDialog(Unknown Source) > at org.jbpm.gd.jpdl.util.ProcessDeployer.deploy(Unknown Source) > at org.jbpm.gd.jpdl.deployment.DeploymentForm$1.widgetSelected(Unknown Source) > at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228) > at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158) > at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033) > at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2384) > at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2348) > at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2200) > at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:495) > at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) > at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:490) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) > at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) > at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) > at org.eclipse.equinox.launcher.Main.run(Main.java:1236) > at org.eclipse.equinox.launcher.Main.main(Main.java:1212) > (Note: deploying the process without the action handler classes works!) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-363) Name of Decision box are not visible on the grahi.

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-363?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-363. --------------------------- Resolution: Out of Date > Name of Decision box are not visible on the grahi. > -------------------------------------------------- > > Key: GPD-363 > URL: https://issues.jboss.org/browse/GPD-363 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 4.0.0.GA > Reporter: Alexandre Navarro > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > Name of Decision box are not visible on the grahi. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-292) Enhance Node Pluggability

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-292?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-292. --------------------------- Resolution: Out of Date > Enhance Node Pluggability > ------------------------- > > Key: GPD-292 > URL: https://issues.jboss.org/browse/GPD-292 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > It should be possible to add nodes by adding a jar file (containing a configuration and possibly some java classes and icons) in a well-defined location. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-140) when working with large process definitions, screen jumps to top whenever new nodes added in designer

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-140?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-140. --------------------------- Resolution: Out of Date > when working with large process definitions, screen jumps to top whenever new nodes added in designer > ----------------------------------------------------------------------------------------------------- > > Key: GPD-140 > URL: https://issues.jboss.org/browse/GPD-140 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0.beta2 > Environment: osx macbook pro, eclipse 3.3.0, designer plugin 3.1.0 beta 1, beta 2, CR1 > Reporter: Ross McDonald > Assignee: Koen Aers > Priority: Trivial > Fix For: jBPM jPDL Designer 3.x, jBPM jPDL Designer 4.x > > > Hi, > when working with large process diagrams, if I am scrolled down to the bottom of the view, and add a new node, when the screen is updated it jumps back up to the top, so I need to scroll down again. > Obviously when adding many nodes, this costs time, its just a trivial thing. > Cheers > Ross -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-244) Graphical editor does not allow configuring signal type

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-244?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-244. --------------------------- Resolution: Out of Date > Graphical editor does not allow configuring signal type > ------------------------------------------------------- > > Key: GPD-244 > URL: https://issues.jboss.org/browse/GPD-244 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.3, jBPM jPDL Designer 3.1.3.SP2, jBPM jPDL Designer 3.1.4, jBPM jPDL Designer 3.1.5 > Reporter: George Gastaldi > Assignee: Koen Aers > Priority: Trivial > Fix For: jBPM jPDL Designer 3.x > > > Each task-node may have a "signal" attribute associated, that is: > -unsynchronized > -first > -first-wait > -last > -last-wait > -never > . This is not shown on the Graphical Designer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-336) image generation fails

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-336?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-336. --------------------------- Resolution: Out of Date > image generation fails > ---------------------- > > Key: GPD-336 > URL: https://issues.jboss.org/browse/GPD-336 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Tom Baeyens > Assignee: Koen Aers > Priority: Optional > Fix For: jBPM jPDL Designer 4.x > > > image generation seems to work for org.jbpm.examples.async.activity > but it seems to fail for org.jbpm.examples.async.fork. in that case I get an image with only a diagonal line. > koen, do you get the same with that example ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-377) Saving Java file wrecks deployment settings

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-377?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-377. --------------------------- Resolution: Out of Date > Saving Java file wrecks deployment settings > ------------------------------------------- > > Key: GPD-377 > URL: https://issues.jboss.org/browse/GPD-377 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.7 > Environment: GDP 3.1.7 > Eclipse Galileo Java EE 20090621-0832 > Linux Ubuntu 2009.04 > Reporter: Nicolas Raoul > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 3.x > > > It works fine, but there is something silly: > Everytime I save a Java file, the deployment's "Java Classes and Resources" settings are automatically reconfigured to something that does not work. > It seems that all Java classes that are not directly called from the process definition file get deselected. Like if I would wrote all of the code in just one class... > (and of course if options could be saved to survive Eclipse restarts, that would be even better) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-206) Show simlane assignment in task node

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-206?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-206. --------------------------- Resolution: Out of Date > Show simlane assignment in task node > ------------------------------------ > > Key: GPD-206 > URL: https://issues.jboss.org/browse/GPD-206 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Ruben Marrero > Assignee: Koen Aers > Priority: Trivial > Fix For: jBPM jPDL Designer 3.x, jBPM jPDL Designer 4.x > > > It would be very useful if the task would show which swimlane is assigned to. > Thanks -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-154) process image rendered incorrectly for large process definition

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-154?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-154. --------------------------- Resolution: Out of Date > process image rendered incorrectly for large process definition > --------------------------------------------------------------- > > Key: GPD-154 > URL: https://issues.jboss.org/browse/GPD-154 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Environment: mac osx, tomcat 5.0.28 > Reporter: Ross McDonald > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 3.x > > > Hi, > then I create a large process, and extend to the left beyond the original boundary, by placing and element in the designer and dragging, so scrollbars appear, the image when rendered in the console is offset incorrectly while on any given node, > cheers > Ross -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-14) Lay out Algorithm

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-14?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-14. -------------------------- Resolution: Out of Date > Lay out Algorithm > ----------------- > > Key: GPD-14 > URL: https://issues.jboss.org/browse/GPD-14 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 3.x > > > Integrate a layout algorithm that is used when users add nodes to the xml directly to lay out the newly created components in an orderly fashion on the graphical canvas. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-123) Ability to zoom

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-123?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-123. --------------------------- Resolution: Out of Date > Ability to zoom > --------------- > > Key: GPD-123 > URL: https://issues.jboss.org/browse/GPD-123 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0.beta1 > Reporter: Matthew Sandoz > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 4.x > > > It would be nice especially for large flows to be able to zoom in and out of the process designer view. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-146) improve feedback when creating self referencing transitions

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-146?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-146. --------------------------- Resolution: Out of Date > improve feedback when creating self referencing transitions > ----------------------------------------------------------- > > Key: GPD-146 > URL: https://issues.jboss.org/browse/GPD-146 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0.GA > Reporter: Koen Aers > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 3.x, jBPM jPDL Designer 4.x > > > At the moment creating self referencing transitions is done by clicking twice on the source/target node. In the future some feedback (a dummy transition) should make this proces more obvious -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-167) Diagram should not scroll after adding nodes from palette

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-167?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-167. --------------------------- Resolution: Out of Date > Diagram should not scroll after adding nodes from palette > --------------------------------------------------------- > > Key: GPD-167 > URL: https://issues.jboss.org/browse/GPD-167 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.0.SP1 > Reporter: John Ruud > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 3.x > > > After adding nodes from the palette to diagrams where the scroll-bars are not in the top left corner position, the diagram will automatically scroll (to the top-left position). This is not desirable IMO, as it makes it easy to loose track of just-added nodes for large diagrams. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-150) In-place label edit box offset in scrolled editor

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-150?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-150. --------------------------- Resolution: Out of Date > In-place label edit box offset in scrolled editor > ------------------------------------------------- > > Key: GPD-150 > URL: https://issues.jboss.org/browse/GPD-150 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0.CR > Environment: Eclipse 3.3, Windows XP SP2, JDK 6 > Reporter: David Good > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 3.x > > Attachments: screenshot-1.jpg > > > When editing a diagram larger than the editor window, clicking on a node label causes the edit box to appear in an offset position if the scroll bars are not in the origin. (see attachment) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-232) add "binding" attribute to model class of subprocess in process designer

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-232?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-232. --------------------------- Resolution: Out of Date > add "binding" attribute to model class of subprocess in process designer > ------------------------------------------------------------------------ > > Key: GPD-232 > URL: https://issues.jboss.org/browse/GPD-232 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Environment: probably not important here, but: windows XP java 1.6 > Reporter: s p > Assignee: Koen Aers > Priority: Minor > Labels: attribute, binding, designer, gpd, late, model > Fix For: jBPM jPDL Designer 3.2 > > Attachments: supportBindingAttributeInSubprocess.path, supportBindingAttributeInSubprocess.path > > > There is optional attribute binding in SubProcess element, but it's not accessible from GPD, becouse in model of subprocess it isn't supported. > It would be nice to add it to model and to xmladapter classes, to allow people access to this attribute from their extensions of process designer. > At least it would be very usefull to me :) > I've attached a patch (updated - the bigger is wrong i it changes formatting, use the smaller (newer) file). > I use version 3.2.3 from svn of jbpm and it isn't in combo, so I've choosed unknow version. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-158) Have the formsgenerator put a required attribute on jsf components

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-158?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-158. --------------------------- Resolution: Out of Date > Have the formsgenerator put a required attribute on jsf components > ------------------------------------------------------------------ > > Key: GPD-158 > URL: https://issues.jboss.org/browse/GPD-158 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0.CR > Reporter: James Baxter > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 3.x > > > Tasks can have variables specified as 'required'. This is not built into the taskform, the forms are missing the following attribute from the h:input tag: > [code] > required="true" > [/code] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-307) make g the last attribute

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-307?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-307. --------------------------- Resolution: Out of Date > make g the last attribute > ------------------------- > > Key: GPD-307 > URL: https://issues.jboss.org/browse/GPD-307 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Tom Baeyens > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > koen, could you check if it is easy to make g the last attribute ? currently it seems to be systematically the first attribute. > <process name="EndState" xmlns="http://jbpm.org/4/jpdl"> > <start g="16,96,48,48"> > <transition to="get return code" name=""/> > </start> > <state g="96,94,110,52" name="get return code"> > <transition g="150,63:-36,11" name="200" to="ok"/> > <transition g=":-16,-27" name="400" to="bad request"/> > <transition g="150,177:-33,-32" name="500" to="internal server error"/> > </state> > <end g="239,40,48,48" name="ok" state="completed"/> > <end-cancel g="239,97,48,48" name="bad request"/> > <end-error g="240,154,48,48" name="internal server error"/> > </process> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-366) Process Definition not displayed correctly if xml is updated directly

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-366?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-366. --------------------------- Resolution: Out of Date > Process Definition not displayed correctly if xml is updated directly > --------------------------------------------------------------------- > > Key: GPD-366 > URL: https://issues.jboss.org/browse/GPD-366 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.2 > Environment: Windows Vista, Eclispe 3.4.2 , JBPM 3.2.1 > Reporter: TejJBPM > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > Whenever I edit the processdefinition.xml directly for example ( I add a mail action class)..the original display in the processdefinition goes strange. IT loses all the transitions. > This does not happen always. But intermittenly. Because of this whenever i change the xml file i save it and cross check it in the display whether everything is fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-35) enhancement drawing transitions

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-35?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-35. -------------------------- Resolution: Out of Date > enhancement drawing transitions > ------------------------------- > > Key: GPD-35 > URL: https://issues.jboss.org/browse/GPD-35 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > When the mousepointer is in the outer area of a node/state/task/.... but within it's boundaries, it should be possible to draw a transition. This is makes using the gpd a lot faster (not switching in the toolbar) > Maybe it should only be in the 'middle areas' of top, bottom, left and right and not the corners -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-305) GPD diagram are not in sync with text.

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-305?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-305. --------------------------- Resolution: Out of Date > GPD diagram are not in sync with text. > -------------------------------------- > > Key: GPD-305 > URL: https://issues.jboss.org/browse/GPD-305 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.6, jBPM jPDL Designer 3.1.7 > Reporter: Andrey Sobolev > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > Hi, > We found a problem then try to use GPD from our product. > Editor could be not in sync with diagram if eclipse file are changed then editor are opened. > With following simple scenario problem could be reproduced: > 1) Create new empty JPDL document. > Content will be following: > <?xml version="1.0" encoding="UTF-8"?> > <process-definition xmlns="" name="test"></process-definition> > 2)Then open processdefinition.xml file with generic text editor and change content to: > <?xml version="1.0" encoding="UTF-8"?> > <process-definition xmlns="" name="test"/> > 3) After text is saved. Source and diagram are not in sync. So then we add new elements, text are not modified. > Best regards, > Andrei. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-296) savnig problem on Persian/Arabic characters

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-296?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-296. --------------------------- Resolution: Out of Date > savnig problem on Persian/Arabic characters > ------------------------------------------- > > Key: GPD-296 > URL: https://issues.jboss.org/browse/GPD-296 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.5 > Reporter: mahdi asgari nea > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > Hi dear Help Desk > I have a problem to save process designer in Persian/Arabic language. > The process save correctly but when i reopen the process all tasks and nodes positions are bollixed but the names are saved correct. > In the gpd.xml file the task and node names saved like ????? symbols. > Is there any solution or configuration to fix this problem? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-299) The GUI does not support exception handling of invoked ESB services

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-299?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-299. --------------------------- Resolution: Out of Date > The GUI does not support exception handling of invoked ESB services > ------------------------------------------------------------------- > > Key: GPD-299 > URL: https://issues.jboss.org/browse/GPD-299 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.5 > Reporter: Jiri Pechanec > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > See the linked doc for the implementation > http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/4.3.GA/html-single/Se... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-193) Add the ability to drag new components into the workflow

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-193?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-193. --------------------------- Resolution: Out of Date > Add the ability to drag new components into the workflow > -------------------------------------------------------- > > Key: GPD-193 > URL: https://issues.jboss.org/browse/GPD-193 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Gunnar Hillert > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > In the workflow designer it would be nice if I could simply drag a new workflow component into the main workflow. > Right now you have to select the component from the component palette and then click again in the main workflow area to place the component. This seems to be slightly less intuitive than just drag-and-drop the new component into the workflow. > Also, it would be great if I could then drag a component from the palette onto an existing 'transition line' and the transition will automatically connect to the newly placed component. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-230) GenericElements don't update their attributes when changed from xml editor

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-230?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-230. --------------------------- Resolution: Out of Date > GenericElements don't update their attributes when changed from xml editor > -------------------------------------------------------------------------- > > Key: GPD-230 > URL: https://issues.jboss.org/browse/GPD-230 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Reporter: Marcin Slusarz > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.2 > > Attachments: GenericElementXmlAdapter.java.diff > > > If I modify any attribute of tag (represented as GenericElement) in XML source and switch back to "Diagram" tab, these changes are not propagated to GenericElements (only value of tag is updated). > I found that GenericElementXmlAdapter.doModelUpdate reacts only to "#text" changes... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-231) Editing task node's name in source view breaks XML, if node is used.

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-231?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-231. --------------------------- Resolution: Out of Date > Editing task node's name in source view breaks XML, if node is used. > -------------------------------------------------------------------- > > Key: GPD-231 > URL: https://issues.jboss.org/browse/GPD-231 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.3.SP2 > Environment: Windows XP SP3, Eclipse 3.3 > Reporter: N/A N/A > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > When switching to source code view and manually editing a task node's name which is used by an existing transition, breaks the XML. You can enter whatever you like, but the task's name attribute stays the same while the transition's to-attribute is cluttered with parts of the characters you have enter. Depending on whether you use backspace, the cursor may also jump around in the document, erasing some unrelated code. > Here is an example: > BEFORE > <start-state name="First step"> > <task name="First step" swimlane="Role"> > <controller> > <variable access="read,write,required" name="someVar" mapped-name="Some Var"/> > </controller> > </task> > <transition to="Second step"/> > </start-state> > <task-node name="Second Step">  > <task name="Second Step" swimlane="Second role"> > <controller> > <variable access="read,write,required" name="someOtherVar" mapped-name="Some Other Var"/> > </controller> > </task> > <transition to="Third step"/> > </task-node> > AFTER > <start-state name="First step"> > <task name="First step" swimlane="Role"> > <controller> > <variable access="read,write,required" name="someVar" mapped-name="Some Var"/> > </controller> > </task> > <transition to="Second"/>  > </start-state> > <task-node name="Second Ste>  > <task nme="Second Step" swimlane="Second role">  > <controller> > <variable access="read,write,required" name="someOtherVar" mapped-name="Some Other Var"/> > </controller> > </task> > <transition to="Third step"/> > </task-node> > Another option is adding something to the node's name... First look at the original once more, when trying to add " Part 1" to "Second Step" (so it should be Second Step Part 1) we get this as the result: > <start-state name="First step"> > <task name="First step" swimlane="Role"> > <controller> > <variable access="read,write,required" name="someVar" mapped-name="Some Var"/> > </controller> > </task> > <transition to="Second step Part 1"/>  > </start-state> > <task-node name="Second Step">  > <task name="Second Step" swimlane="Second role"> > <controller> > <variable access="read,write,required" name="someOtherVar" mapped-name="Some Other Var"/> > </controller> > </task> > <transition to="Third step"/> > </task-node> > This can be worked around by first changing the transition's to-attribute to something that isn't used, but it's nonetheless a bug which causes some grief. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-176) Add code completion inside attributes and values within the xml source

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-176?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-176. --------------------------- Resolution: Out of Date > Add code completion inside attributes and values within the xml source > ---------------------------------------------------------------------- > > Key: GPD-176 > URL: https://issues.jboss.org/browse/GPD-176 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-243) Cannot browse services while adding ESB Node

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-243?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-243. --------------------------- Resolution: Out of Date > Cannot browse services while adding ESB Node > -------------------------------------------- > > Key: GPD-243 > URL: https://issues.jboss.org/browse/GPD-243 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.4 > Reporter: Piotr Hrebieniuk > Assignee: Koen Aers > Labels: ESB_node, services, xml > Fix For: jBPM jPDL Designer 3.x > > > The ESB type node is used to tell the process, that the logic of this node is defined in ESB service body. But, unfortunately, we cannot choose between services defined in nearest esb file (or referenced somewhere in process definition). > What it causes, is that every time someone want to model a process, he has to search xml file. I suggest adding some kind of browser, it should be easy to implement with any xml parser. > P.S.: i could do it, if Koen doesn't have much time.. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-112) Super state node name is not displayed

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-112?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-112. --------------------------- Resolution: Out of Date > Super state node name is not displayed > -------------------------------------- > > Key: GPD-112 > URL: https://issues.jboss.org/browse/GPD-112 > Project: jBPM GPD > Issue Type: Sub-task > Components: jpdl > Environment: all > Reporter: vladimir mezhibovsky > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > Having a name of the super state shown on the process diagram would really help. Currently it is only visible in the outline window which make it hard to understand the process by just looking on the diagram. You have to click on the rectangle that represent super state to see the name. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-177) Add code completion in the text input fields on the properties view

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-177?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-177. --------------------------- Resolution: Out of Date > Add code completion in the text input fields on the properties view > ------------------------------------------------------------------- > > Key: GPD-177 > URL: https://issues.jboss.org/browse/GPD-177 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-155) secure the gpd deployment servlet

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-155?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-155. --------------------------- Resolution: Out of Date > secure the gpd deployment servlet > --------------------------------- > > Key: GPD-155 > URL: https://issues.jboss.org/browse/GPD-155 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Tom Baeyens > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > the gpd deployment servlet should be secured. the gpd should add authentication information in the url like e.g. http://gpd:gpd:localhost/jbpm-console/upload or something like that. then the users will be able to control the authorization through the web interface itself. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-300) save process image as PNG

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-300?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-300. --------------------------- Resolution: Out of Date > save process image as PNG > ------------------------- > > Key: GPD-300 > URL: https://issues.jboss.org/browse/GPD-300 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Dan Lipofsky > Assignee: Koen Aers > Labels: png, processimage > Fix For: jBPM jPDL Designer 3.2 > > > It would be a big improvment to save the process image as PNG instead > of JPEG. The JPG compression artifacts are quite obvious and it is > the worst format for saving this type of image (sharp lines and words, > computer generated). PNG is made for this type of image and its > compression works well on this type of image so the resulting size > would probably not be much larger. Also PNG supports transparent > backgrounds so it would be nice if GPD supported this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-18) Reordering graph elements in outline view

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-18?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-18. -------------------------- Resolution: Out of Date > Reordering graph elements in outline view > ----------------------------------------- > > Key: GPD-18 > URL: https://issues.jboss.org/browse/GPD-18 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0 alpha1 > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > Reordering elements is possible by directly editing the xml. It should be possible to obtain the same effect by dragging and dropping elements in the outline view. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-19) Endpoint Editing

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-19?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-19. -------------------------- Resolution: Out of Date > Endpoint Editing > ---------------- > > Key: GPD-19 > URL: https://issues.jboss.org/browse/GPD-19 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0 alpha1 > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > Move endpoints of connections to wherever location on the edge of a node. Involves implementing a particular form of anchor point. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-242) Transitions coming from Superstates are not rendered correctly

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-242?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-242. --------------------------- Resolution: Out of Date > Transitions coming from Superstates are not rendered correctly > -------------------------------------------------------------- > > Key: GPD-242 > URL: https://issues.jboss.org/browse/GPD-242 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.3 > Environment: Kubuntu Hardy Heron, Java 1.6.0_06 Eclipse 3.3, Gef 3.3.2.v20080129 > Reporter: Mark Torres > Assignee: Koen Aers > Labels: gpd, jbpm, superstate, transition > Fix For: jBPM jPDL Designer 3.x > > Attachments: SuperStateTestCase.zip > > > Transitions coming from superstates are not rendered correctly on jpdl graphical editor. > Uploaded gpd.xml, processdefinition.xml, processimage_before.jpg(expected) , processimage_after.jpg(result). > Furthermore, upon saving after a minor change, the bendpoints from gpd.xml are removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-38) Comment in graphical editor (UML annotations)

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-38?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-38. -------------------------- Resolution: Out of Date > Comment in graphical editor (UML annotations) > --------------------------------------------- > > Key: GPD-38 > URL: https://issues.jboss.org/browse/GPD-38 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > It should be possible to annotate the graphical elements in the graphical editor with comments. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-54) Label and name support for graph elements

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-54?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-54. -------------------------- Resolution: Out of Date > Label and name support for graph elements > ----------------------------------------- > > Key: GPD-54 > URL: https://issues.jboss.org/browse/GPD-54 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-205) Designer adds script tag without expression

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-205?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-205. --------------------------- Resolution: Out of Date > Designer adds script tag without expression > ------------------------------------------- > > Key: GPD-205 > URL: https://issues.jboss.org/browse/GPD-205 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Reporter: Rafal Zukowski > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > Original Estimate: 4 minutes > Remaining Estimate: 4 minutes > > When You create transition and add "Script Action" to Actions in Properties, You can write some script which will run every time the transition will be used. > Designer puts this text into <script> element, when jbpm expects script as a text in <expression> element, not in <script> element. > sample correct xml: > <transition to="end-state1"> > <script> > <expression> > System.out.println("test"); > </expression> > </script> > </transition> > what designer does: > <transition to="end-state1"> > <script> > System.out.println("test"); > </script> > </transition> > I've made a patch to fix this problem, I'll attach it to this issue later... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-204) Additional Attribute for ESB Service Node

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-204?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-204. --------------------------- Resolution: Out of Date > Additional Attribute for ESB Service Node > ----------------------------------------- > > Key: GPD-204 > URL: https://issues.jboss.org/browse/GPD-204 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Jeff DeLong > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.2 > > Attachments: org.jbpm.gd.jpdl.diff > > > There are two other options of the ESBActionHandler described in the SOA_ESB_JBPM_Integration_Guide.pdf > default - optional attribute which can hold a default value if the esb MVEL expression does > not find a value set in the EsbMessage. > exceptionTransition - optional element. The name of the transition that should be taken if > an exception occurs while processing the Service. This requires the current node to have > more then one outgoing transition where one of the transition handles "exception > processing" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-233) Delete a Timer in a TaskNode

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-233?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-233. --------------------------- Resolution: Out of Date > Delete a Timer in a TaskNode > ---------------------------- > > Key: GPD-233 > URL: https://issues.jboss.org/browse/GPD-233 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.3 > Environment: Eclipse 3.3.2, JPDL Designer 3.1.2, 3.1.3sp2 > Reporter: Sven Daumann > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > step1: Create a timer in the properties-menu of a TaskNode > step2: Delete the created timer in the menu > problem: The timer is still visible. The timer is also visible after changing the tabs > workaround: deselect the TaskNode > Repeating step 1 and 2 with creating an event works fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-187) Expose properties of base classes in field/bean configuration of GPD

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-187?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-187. --------------------------- Resolution: Out of Date > Expose properties of base classes in field/bean configuration of GPD > -------------------------------------------------------------------- > > Key: GPD-187 > URL: https://issues.jboss.org/browse/GPD-187 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.0.SP1 > Environment: Windows XP (and others) > Reporter: s b > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.2 > > > In the process designer interface for setting bean/field properties for custom classes such as an AssignmentHandler, it would be desirable if the properties/fields of the base classes (that the custom class inherits from) are also exposed. Then we could use inheritance much more effectively in our custom class designs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7048) Servlet 3.x metadata-complete="true" does not honour absolute-ordering element

by Darryl Miles (JIRA)

[ https://issues.jboss.org/browse/WFLY-7048?page=com.atlassian.jira.plugin.... ] Darryl Miles updated WFLY-7048: ------------------------------- Description: Servlet 3.x metadata-complete="true" does not honour absolute-ordering element. If I have a web.xml that sets metadata-complete="true" in the <web-app> element. The container is expected to only allow the initialization of the named entries inside the <absolute-ordering> element that does not have the presence of an <others/> element inside it. So a metadata-complete="true" with a non-existing (or empty) <absolute-ordering> is expected to effectively filter and then exclude ALL ServletContainerInitializer found. Since nothing was specified by a <name> element, and the <others/> element is not present. This might also be considered a fast-path to prevent any package scanning for annotations / interfaces. The bug here is that I can observe no change in behaviour (regardless of metadata-complete="true" setting, or the contents I tried of the <absolute-ordering> element, it always has the same results of finding and processing everything found in the classpath JARs). Does WEB-INF/jboss-web.xml support undertow specific filtering of the packages to scan for ServletContainerInitializer ? Many other contains have support for this (jetty/tomcat) and the jboss-web.xml seems the obvious place to put it. I can provide references to this feature, since it still helps in the developmentMode scenario (where I spend most of my time and care most about startup performance). Also the servlet 3.x spec seem to have omited the notion of allowing WEB-INF/classes to contain a ServletContainerInitializer, they omitted having a section in web.xml to provide this, they omitted allowing a WAR to have WEB-INF/META-INF/services/javax.servlet.ServletContainerInitializer as well. was: Servlet 3.x metadata-complete="true" does not honour absolute-ordering element. If I have a web.xml that sets metadata-complete="true" in the <web-app> element. The container is expected to only allow the initialization of the named entries inside the <absolute-ordering> element that does not have the presense of an <others/> element inside it. So a metadata-complete="true" with a non-existing (or empty) <absolute-ordering> is expected to effectively filter and then exclude ALL ServletContainerInitializer found. Since nothing was specified by a <name> element, and the <others/> element is not present. This might also be considered a fast-path to prevent any package scanning for annotations / interfaces. The bug here is that I can observe no change in behaviour (regardless of metadata-complete="true" setting, or the contents I tried of the <absolute-ordering> element, it always has the same results of finding and processing everything found in the classpath JARs). Does WEB-INF/jboss-web.xml support undertow specific filtering of the packages to scan for ServletContainerInitializer ? Many other contains have support for this (jetty/tomcat) and the jboss-web.xml seems the obvious place to put it. I can provide references to this feature, since it still helps in the developmentMode scenario (where I spend most of my time and care most about startup performance). Also the servlet 3.x spec seem to have omited the notion of allowing WEB-INF/classes to contain a ServletContainerInitializer, they omitted having a section in web.xml to provide this, they omitted allowing a WAR to have WEB-INF/META-INF/services/javax.servlet.ServletContainerInitializer as well. > Servlet 3.x metadata-complete="true" does not honour absolute-ordering element > ------------------------------------------------------------------------------ > > Key: WFLY-7048 > URL: https://issues.jboss.org/browse/WFLY-7048 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Darryl Miles > Assignee: Stuart Douglas > > Servlet 3.x metadata-complete="true" does not honour absolute-ordering element. > If I have a web.xml that sets metadata-complete="true" in the <web-app> element. > The container is expected to only allow the initialization of the named entries inside the <absolute-ordering> element that does not have the presence of an <others/> element inside it. > So a metadata-complete="true" with a non-existing (or empty) <absolute-ordering> is expected to effectively filter and then exclude ALL ServletContainerInitializer found. Since nothing was specified by a <name> element, and the <others/> element is not present. > This might also be considered a fast-path to prevent any package scanning for annotations / interfaces. > The bug here is that I can observe no change in behaviour (regardless of metadata-complete="true" setting, or the contents I tried of the <absolute-ordering> element, it always has the same results of finding and processing everything found in the classpath JARs). > Does WEB-INF/jboss-web.xml support undertow specific filtering of the packages to scan for ServletContainerInitializer ? Many other contains have support for this (jetty/tomcat) and the jboss-web.xml seems the obvious place to put it. > I can provide references to this feature, since it still helps in the developmentMode scenario (where I spend most of my time and care most about startup performance). > Also the servlet 3.x spec seem to have omited the notion of allowing WEB-INF/classes to contain a ServletContainerInitializer, they omitted having a section in web.xml to provide this, they omitted allowing a WAR to have WEB-INF/META-INF/services/javax.servlet.ServletContainerInitializer as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-161) Overwriting a node in the source yields an out-of-sync diagram

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-161?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-161. --------------------------- Resolution: Out of Date > Overwriting a node in the source yields an out-of-sync diagram > -------------------------------------------------------------- > > Key: GPD-161 > URL: https://issues.jboss.org/browse/GPD-161 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0.CR > Environment: RHEL 5 > 3.1.0cr1 > Reporter: Micah Gideon Modell > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > Attachments: cheat.txt, processdefinition.xml, websale.par > > > I edited the source xml by pasting in the Decision Node from the cheat.txt (attached) over the "Evaluate web order" found in the example websale process. When I switched back to visual mode, I found an unattached Decision Node with no name and the "Evaluate web order" remained as before. > I'll attach the before and after JPDL as well as the substitution text after I open this bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-162) Deploying a process does not pull in necessary Java classes

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-162?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-162. --------------------------- Resolution: Out of Date > Deploying a process does not pull in necessary Java classes > ----------------------------------------------------------- > > Key: GPD-162 > URL: https://issues.jboss.org/browse/GPD-162 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0.CR > Environment: RHEL 5 > GPD 3.1.0.CR1 > Reporter: Micah Gideon Modell > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > Attachments: websale.par > > > When I try to deploy a process from the GPD, the class files referenced in the definition do not come across properly. > 1) Modified an existing process (as per GPD 161). > 2) Save the process. (.par will be attached) > 3) Use the Deployment tab to deploy the updated process. > 4) Execute the process and you get the following error: > In the web page: > Error completing task: An exception of type "org.jbpm.graph.def.DelegationException" was thrown. > On the console: > 12:48:35,403 ERROR [Delegation] couldn't instantiate delegation class 'org.jbpm.websale.DeciderHandler' > java.lang.NullPointerException > at org.jbpm.instantiation.FieldInstantiator.newInstance(FieldInstantiator.java:105) > at org.jbpm.instantiation.FieldInstantiator.instantiate(FieldInstantiator.java:48) > at org.jbpm.instantiation.Delegation.instantiate(Delegation.java:163) > at org.jbpm.instantiation.Delegation$$FastClassByCGLIB$$6bae1598.invoke(<generated>) > at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) > at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163) > at org.jbpm.instantiation.Delegation$$EnhancerByCGLIB$$a8c02805.instantiate(<generated>) > at org.jbpm.graph.node.Decision.execute(Decision.java:87) > at org.jbpm.graph.def.Node.enter(Node.java:318) > at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>) > at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) > at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163) > at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$2abd72ab.enter(<generated>) > at org.jbpm.graph.def.Transition.take(Transition.java:151) > at org.jbpm.graph.def.Node.leave(Node.java:393) > at org.jbpm.graph.node.StartState.leave(StartState.java:70) > at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>) > at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) > at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163) > at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$2abd72ab.leave(<generated>) > at org.jbpm.graph.exe.Token.signal(Token.java:194) > at org.jbpm.graph.exe.Token.signal(Token.java:139) > at org.jbpm.graph.exe.Token$$FastClassByCGLIB$$74df1c6e.invoke(<generated>) > at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) > at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163) > at org.jbpm.graph.exe.Token$$EnhancerByCGLIB$$5a16e027.signal(<generated>) > at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:476) > at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:390) > at org.jbpm.jsf.core.action.CompleteTaskActionListener.handleAction(CompleteTaskActionListener.java:47) > at org.jbpm.jsf.core.impl.JbpmActionListenerWrapper.processAction(JbpmActionListenerWrapper.java:82) > at javax.faces.event.ActionEvent.processListener(ActionEvent.java:77) > at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758) > at javax.faces.component.UICommand.broadcast(UICommand.java:368) > at org.jbpm.jsf.taskform.ui.UITaskFormButtonBase.broadcast(UITaskFormButtonBase.java:56) > at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:448) > at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752) > at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97) > at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248) > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) > at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) > at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) > at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) > at java.lang.Thread.run(Thread.java:595) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7048) Servlet 3.x metadata-complete="true" does not honour absolute-ordering element

by Darryl Miles (JIRA)

[ https://issues.jboss.org/browse/WFLY-7048?page=com.atlassian.jira.plugin.... ] Darryl Miles updated WFLY-7048: ------------------------------- Steps to Reproduce: Make a WAR project with 2 WEB-INF/lib/*.jar that have META-INF/services/javax.servlet.ServletContainerInitializer (that simply log the calls to #onStartup()) Now modify web.xml with various permutations of settings to observe behaviour doesn't seem to change. Test cases to cover: No web.xml web.xml (no metadata-complete attribute, no absolute-ordering element) web.xml (no metadata-complete="true" set, no absolute-ordering element) web.xml (no metadata-complete="true" set, absolute-ordering element with 1 name item) web.xml (no metadata-complete="true" set, no absolute-ordering element with 2 name items) web.xml (no metadata-complete="true" set, no absolute-ordering element with 1 name item and 1 others element item) web.xml (no metadata-complete="true" set, no absolute-ordering element with 1 name item and 1 others element item - the other way round the previous test) The result wants to be a List in order of what was invoked. was: Make a WAR project with 2 WEB-INF/lib/*.jar that have META-INF/services/javax.servlet.ServletContainerInitializer (that simply log the calls to #onStartup()) Now modify web.xml with various permutations of settings to observe behaviour doesn't seem to change. Test cases to over: No web.xml web.xml (no metadata-complete attribute, no absolute-ordering element) web.xml (no metadata-complete="true" set, no absolute-ordering element) web.xml (no metadata-complete="true" set, absolute-ordering element with 1 name item) web.xml (no metadata-complete="true" set, no absolute-ordering element with 2 name items) web.xml (no metadata-complete="true" set, no absolute-ordering element with 1 name item and 1 others element item) web.xml (no metadata-complete="true" set, no absolute-ordering element with 1 name item and 1 others element item - the other way round the previous test) The result wants to be a List in order of what was invoked. > Servlet 3.x metadata-complete="true" does not honour absolute-ordering element > ------------------------------------------------------------------------------ > > Key: WFLY-7048 > URL: https://issues.jboss.org/browse/WFLY-7048 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Darryl Miles > Assignee: Stuart Douglas > > Servlet 3.x metadata-complete="true" does not honour absolute-ordering element. > If I have a web.xml that sets metadata-complete="true" in the <web-app> element. > The container is expected to only allow the initialization of the named entries inside the <absolute-ordering> element that does not have the presense of an <others/> element inside it. > So a metadata-complete="true" with a non-existing (or empty) <absolute-ordering> is expected to effectively filter and then exclude ALL ServletContainerInitializer found. Since nothing was specified by a <name> element, and the <others/> element is not present. > This might also be considered a fast-path to prevent any package scanning for annotations / interfaces. > The bug here is that I can observe no change in behaviour (regardless of metadata-complete="true" setting, or the contents I tried of the <absolute-ordering> element, it always has the same results of finding and processing everything found in the classpath JARs). > Does WEB-INF/jboss-web.xml support undertow specific filtering of the packages to scan for ServletContainerInitializer ? Many other contains have support for this (jetty/tomcat) and the jboss-web.xml seems the obvious place to put it. > I can provide references to this feature, since it still helps in the developmentMode scenario (where I spend most of my time and care most about startup performance). > Also the servlet 3.x spec seem to have omited the notion of allowing WEB-INF/classes to contain a ServletContainerInitializer, they omitted having a section in web.xml to provide this, they omitted allowing a WAR to have WEB-INF/META-INF/services/javax.servlet.ServletContainerInitializer as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-183) Cut/Copy/Paste of transitions and nodes in the process designer

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-183?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-183. --------------------------- Resolution: Out of Date > Cut/Copy/Paste of transitions and nodes in the process designer > --------------------------------------------------------------- > > Key: GPD-183 > URL: https://issues.jboss.org/browse/GPD-183 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Matthew Sandoz > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > It would be very useful to support cut/copy/paste in the process designer. These operations would have the challenge of creating new element names where there were conflicts and determining which transitions to carry along - only connected transitions - that is those whose source and target nodes are also in the selection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7048) Servlet 3.x metadata-complete="true" does not honour absolute-ordering element

by Darryl Miles (JIRA)

Darryl Miles created WFLY-7048: ---------------------------------- Summary: Servlet 3.x metadata-complete="true" does not honour absolute-ordering element Key: WFLY-7048 URL: https://issues.jboss.org/browse/WFLY-7048 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.1.0.Final Reporter: Darryl Miles Assignee: Stuart Douglas Servlet 3.x metadata-complete="true" does not honour absolute-ordering element. If I have a web.xml that sets metadata-complete="true" in the <web-app> element. The container is expected to only allow the initialization of the named entries inside the <absolute-ordering> element that does not have the presense of an <others/> element inside it. So a metadata-complete="true" with a non-existing (or empty) <absolute-ordering> is expected to effectively filter and then exclude ALL ServletContainerInitializer found. Since nothing was specified by a <name> element, and the <others/> element is not present. This might also be considered a fast-path to prevent any package scanning for annotations / interfaces. The bug here is that I can observe no change in behaviour (regardless of metadata-complete="true" setting, or the contents I tried of the <absolute-ordering> element, it always has the same results of finding and processing everything found in the classpath JARs). Does WEB-INF/jboss-web.xml support undertow specific filtering of the packages to scan for ServletContainerInitializer ? Many other contains have support for this (jetty/tomcat) and the jboss-web.xml seems the obvious place to put it. I can provide references to this feature, since it still helps in the developmentMode scenario (where I spend most of my time and care most about startup performance). Also the servlet 3.x spec seem to have omited the notion of allowing WEB-INF/classes to contain a ServletContainerInitializer, they omitted having a section in web.xml to provide this, they omitted allowing a WAR to have WEB-INF/META-INF/services/javax.servlet.ServletContainerInitializer as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-141) IType.getCompilationUnit() can be null if handler class is in jar, leads to event loop exception

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-141?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-141. --------------------------- Resolution: Out of Date > IType.getCompilationUnit() can be null if handler class is in jar, leads to event loop exception > ------------------------------------------------------------------------------------------------ > > Key: GPD-141 > URL: https://issues.jboss.org/browse/GPD-141 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0.CR > Environment: Eclipse 3.2 on Windows 2000 > Reporter: Matthias Hanisch > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.2 > > Attachments: gpd-141.diff > > > Following part of my processdefinition.xml: > <event type="node-leave"> > <action class="x.y.z.MyClass" name="An Action"> > <arg> > anArg > </arg> > </action> > </event> > MyClass is in a jar which is added to the classpath of the Process Project. Saving throws an event loop exception in Error Log View with the following stack. > Caused by: org.eclipse.jface.util.Assert$AssertionFailedException: null argument; > at org.eclipse.jface.util.Assert.isNotNull(Assert.java:150) > at org.eclipse.jface.util.Assert.isNotNull(Assert.java:126) > at org.eclipse.jface.viewers.StructuredViewer.assertElementsNotNull(StructuredViewer.java:577) > at org.eclipse.jface.viewers.CheckboxTreeViewer.setCheckedElements(CheckboxTreeViewer.java:431) > at org.jbpm.gd.jpdl.deployment.IncludeInDeploymentTreeViewer.setCheckedElements(IncludeInDeploymentTreeViewer.java:61) > at org.jbpm.gd.jpdl.deployment.DeploymentForm$17.run(DeploymentForm.java:635) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) > at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) > The problem is, that DeploymentForm.getElementsToCheckFor() does not respect that MyClass returns null for getCompilationUnit(). As a consequence, setCheckedElements is called with null in the Object[]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-149) Creating tasks by editing XML source will prevent the XML file from being re-opened

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-149?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-149. --------------------------- Resolution: Out of Date > Creating tasks by editing XML source will prevent the XML file from being re-opened > ----------------------------------------------------------------------------------- > > Key: GPD-149 > URL: https://issues.jboss.org/browse/GPD-149 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM JPDL Designer 3.1.0.CR > Environment: Eclipse 3.3, Designer 3.1.0 CR > Reporter: jeffcwang > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > When you create new tasks by editing the source, it will break the process definition and not allow you to re-open it in Eclipse. > Steps to recreate: > 1) Create a new process definition > 2) Create a task node using the GUI > 3) Switch to the source tab > 4) Copy the task xml tag > 5) Rename the task name to something unique > 6) Close the file > 7) Re-open using the JBPM editor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-179) pages.xml doesn't work with pageflow editor

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-179?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-179. --------------------------- Resolution: Out of Date > pages.xml doesn't work with pageflow editor > ------------------------------------------- > > Key: GPD-179 > URL: https://issues.jboss.org/browse/GPD-179 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Reporter: Max Rydahl Andersen > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.2 > > > a pages.xml with a proper page flow syntax does not have the pageflow editor in the right click menu. > and when using Open with... and choosing jBpm pageflow designer (not the correct name is it ?) I get > java.lang.NullPointerException > at org.jbpm.ui.pageflow.editor.PageFlowContentProvider.addProcessDiagramDimension(Unknown Source) > at org.jbpm.ui.pageflow.editor.PageFlowContentProvider.addGraphicalInfo(Unknown Source) > at org.jbpm.ui.pageflow.editor.PageFlowContentProvider.addGraphicalInfo(Unknown Source) > at org.jbpm.ui.pageflow.editor.PageFlowContentProvider.addGraphicalInfo(Unknown Source) > at org.jbpm.ui.pageflow.editor.PageFlowGraphicalEditorPage.initInput(Unknown Source) > at org.jbpm.ui.pageflow.editor.PageFlowGraphicalEditorPage.init(Unknown Source) > at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:186) > at org.jbpm.ui.pageflow.editor.PageFlowEditor.addGraphPage(Unknown Source) > at org.jbpm.ui.pageflow.editor.PageFlowEditor.createPages(Unknown Source) > at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283) > at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661) > at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426) > at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592) > at org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:263) > at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2721) > at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-136) Widget is disposed in Task Controller Variables Table

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-136?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-136. --------------------------- Resolution: Out of Date > Widget is disposed in Task Controller Variables Table > ----------------------------------------------------- > > Key: GPD-136 > URL: https://issues.jboss.org/browse/GPD-136 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Environment: Eclipse 3.2.2 on Windows 2000 > Reporter: Matthias Hanisch > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.2 > > > Select a Task Node. Go to Properties View. > Select Tasks:<task>:Controller (default). > Add two variables, remove the second. > Error Log view contains the following SWT Exception: > org.eclipse.swt.SWTException: Widget is disposed > at org.eclipse.swt.SWT.error(SWT.java:3374) > at org.eclipse.swt.SWT.error(SWT.java:3297) > at org.eclipse.swt.SWT.error(SWT.java:3268) > at org.eclipse.swt.widgets.Widget.error(Widget.java:435) > at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:330) > at org.eclipse.swt.widgets.Control.setVisible(Control.java:2642) > at org.jbpm.gd.jpdl.util.VariableTableItemWrapper.applyName(VariableTableItemWrapper.java:164) > at org.jbpm.gd.jpdl.util.VariableTableItemWrapper.cancelEditing(VariableTableItemWrapper.java:150) > at org.jbpm.gd.jpdl.util.VariableTableCellClickedResolver.mouseDown(VariableTableCellClickedResolver.java:25) > at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:133) > at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) > at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) > at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1930) > at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894) > at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:422) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) > at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) > at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) > at org.eclipse.core.launcher.Main.basicRun(Main.java:280) > at org.eclipse.core.launcher.Main.run(Main.java:977) > at org.eclipse.core.launcher.Main.main(Main.java:952) > After that, table input is not working anymore ("Mapped Name" column not editable anymore, for example). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-364) Differentiate a human task from a programmatic task (java, sql ... or state) in the editor as you do between a decision and a task

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-364?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-364. --------------------------- Resolution: Out of Date > Differentiate a human task from a programmatic task (java, sql ... or state) in the editor as you do between a decision and a task > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: GPD-364 > URL: https://issues.jboss.org/browse/GPD-364 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Affects Versions: jBPM jPDL Designer 4.0.0.GA > Reporter: Alexandre Navarro > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > Differentiate a human task from a programmatic task (java, sql ... or state) in the editor as you do between a decision and a task -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-33) remember the previous form generation data fields

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-33?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-33. -------------------------- Resolution: Out of Date > remember the previous form generation data fields > ------------------------------------------------- > > Key: GPD-33 > URL: https://issues.jboss.org/browse/GPD-33 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > In the form generation, we currently start from the data entered in the task controller (if any) > Whenever a form is generated, I would like the form generation data to be stored in the gpd.xml. Then, whenever the user does a second generation, the taskform generation form is prefilled with the previous data instead of starting from the controller data again. > The motivation for this is that mostly people will not have controllers. Then if they have 5 data items to display and collect, it takes a lot of clicking. Users don't want to redo this effort for every little change they want to make to the form (additions and removals of fields). > I think users should be able to live with the fact that controller data items are not kept automatically in sync with the task form data items. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-40) A slash character in Node name causes crash. Graphical Process Designer allows the slash to be entered anyway.

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-40?page=com.atlassian.jira.plugin.sys... ] Koen Aers resolved GPD-40. -------------------------- Resolution: Out of Date > A slash character in Node name causes crash. Graphical Process Designer allows the slash to be entered anyway. > -------------------------------------------------------------------------------------------------------------- > > Key: GPD-40 > URL: https://issues.jboss.org/browse/GPD-40 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > The Graphical Process Designer allows the user to enter a Task Node name that includes a slash, such as "Accounting/Finance". The slash causes a crash later on when the process is run, and it isn't obvious what the source of the problem is. Suggestion: somehow prevent the user from entering a name that includes a slash. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-355) offer conversion support for files from jBPM 3 to jBPM 4

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-355?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-355. --------------------------- Resolution: Out of Date > offer conversion support for files from jBPM 3 to jBPM 4 > -------------------------------------------------------- > > Key: GPD-355 > URL: https://issues.jboss.org/browse/GPD-355 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Priority: Optional > Fix For: jBPM jPDL Designer 4.x > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-286) support deployment of process archives to runtime

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-286?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-286. --------------------------- Resolution: Out of Date > support deployment of process archives to runtime > ------------------------------------------------- > > Key: GPD-286 > URL: https://issues.jboss.org/browse/GPD-286 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > should be based on ant targets. > for each process file, an action "Create Deploy Target" will be exposed > Create Deploy Target will create a target in an ant build file. The generated target should look like the one below. > I think we can assume a "build.xml" in the root as the build file. If not present, the build file should be created. If the file already exists, the target for deployment of the new process definition should be added to the existing build file. Maybe an macrodef can be used. > It is assumed that the processes and process classes that are to be deployed as a business archive are part of one src directory. > The jPDL process designer plugin should leverage the ant view to allow users to activate the build. If a user decides to create a deploy target for a process definition, then the ant view should be made visible and the build file should be added to the list of build files if not already present. Ideally the build file would be expanded so that the process deploy target is immediately visible. > <?xml version="1.0" encoding="UTF-8"?> > <project name="zzz" default="deploy.zzz"> > <property name="database" value="hsqldb" /> > <property name="jbpm.home" value="c:/Software/jbpm-4.1-SNAPSHOT" /> > <target name="deploy.zzz"> >  > <path id="compile.classpath"> > <fileset dir="${jbpm.home}"> > <include name="jbpm.jar" /> > </fileset> > <fileset dir="${jbpm.home}/lib" /> > </path> > <mkdir dir="target/classes" /> > <javac srcdir="src" > destdir="target/classes" > classpathref="compile.classpath" /> > <copy todir="target/classes"> > <fileset dir="src"> > <exclude name="**/*.java" /> > </fileset> > </copy> >  > <jar destfile="target/zzz.bar"> > <fileset dir="target/classes" /> > </jar> >  > <mkdir dir="target/deploycfg" /> > <copy file="${jbpm.home}/install/src/cfg/hibernate/jdbc/${database}.hibernate.cfg.xml" > tofile="target/deploycfg/jbpm.hibernate.cfg.xml" > overwrite="true"> > <filterset filtersfile="${jbpm.home}/install/jdbc/${database}.properties" /> > </copy> > <copy file="${jbpm.home}/install/src/cfg/jbpm/standalone.testsuite.jbpm.cfg.xml" > tofile="target/deploycfg/jbpm.cfg.xml" > overwrite="true" /> >  > <path id="deploy.classpath"> > <pathelement location="target/classes" /> > <pathelement location="target/deploycfg" /> > <path refid="compile.classpath" /> > </path> > <taskdef name="jbpm-deploy" > classname="org.jbpm.pvm.internal.ant.JbpmDeployTask" > classpathref="deploy.classpath" /> >  > <jbpm-deploy file="target/zzz.bar" /> > </target> > </project> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-360) Refine wire object configuration

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-360?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-360. --------------------------- Resolution: Out of Date > Refine wire object configuration > -------------------------------- > > Key: GPD-360 > URL: https://issues.jboss.org/browse/GPD-360 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-359) Events attached to activities

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-359?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-359. --------------------------- Resolution: Out of Date > Events attached to activities > ------------------------------ > > Key: GPD-359 > URL: https://issues.jboss.org/browse/GPD-359 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > This means adding the capability of the gpd to place BPMN events on the border of activities. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-339) pageflow designer

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-339?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-339. --------------------------- Resolution: Out of Date > pageflow designer > ----------------- > > Key: GPD-339 > URL: https://issues.jboss.org/browse/GPD-339 > Project: jBPM GPD > Issue Type: Feature Request > Components: seam > Reporter: Tom Baeyens > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > new version of the pageflow designer -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-306) Self Referencing Connections

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-306?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-306. --------------------------- Resolution: Out of Date > Self Referencing Connections > ---------------------------- > > Key: GPD-306 > URL: https://issues.jboss.org/browse/GPD-306 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 4.x > > > There should be a convenient way to create connections that reference the same node as source and target -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-309) CDATA sections in custom elements of actions with config-type="bean" cause a NPE in the jBPM GPD.

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-309?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-309. --------------------------- Resolution: Out of Date > CDATA sections in custom elements of actions with config-type="bean" cause a NPE in the jBPM GPD. > ------------------------------------------------------------------------------------------------- > > Key: GPD-309 > URL: https://issues.jboss.org/browse/GPD-309 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.6 > Environment: Eclipse 3.4.1 > Reporter: Roman Heinz > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.2 > > > CDATA sections in custom elements of actions with config-type="bean" cause a NPE in the jBPM GPD. > <?xml version="1.0" encoding="UTF-8"?> > <process-definition > xmlns="urn:jbpm.org:jpdl-3.2" > name="simple"> > <start-state name="start"> > <transition name="to_state" to="first"> > </transition> > </start-state> > <state name="first"> > <event type="node-enter"> > <action class="foo.Bar" name="fooAction" config-type="bean"> > <rowdocid><![CDATA[ Test ]]></rowdocid> > </action> > </event> > <transition name="to_end" to="end"> > </transition> > </state> > <end-state name="end"></end-state> > </process-definition> > Result: > java.lang.NullPointerException > at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source) > at org.jbpm.gd.common.xml.GenericElementXmlAdapter.doModelAdd(Unknown Source) > at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source) > at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source) > at org.jbpm.gd.jpdl.xml.ActionDomAdapter.doModelAdd(Unknown Source) > at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source) > at org.jbpm.gd.jpdl.xml.ActionDomAdapter.initialize(Unknown Source) > at org.jbpm.gd.jpdl.xml.EventDomAdapter.doModelAdd(Unknown Source) > ... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-289) Process Debugger

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-289?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-289. --------------------------- Resolution: Out of Date > Process Debugger > ---------------- > > Key: GPD-289 > URL: https://issues.jboss.org/browse/GPD-289 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > It should be possible to add breakpoints to the process definition. When the process is run from a unit test in debugging mode, the execution should stop at the appropriate breakpoint, giving the developer the possibility to inspect process variables, etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-284) Create an RCP version of the GPD

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-284?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-284. --------------------------- Resolution: Out of Date > Create an RCP version of the GPD > -------------------------------- > > Key: GPD-284 > URL: https://issues.jboss.org/browse/GPD-284 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Priority: Optional > Fix For: jBPM jPDL Designer 4.x > > > Part of it is already done. The remaining chunk of work is making sure the build produces the artifacts for the different target platforms and including/enabling some standard actions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-293) Enhance the graphical view

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-293?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-293. --------------------------- Resolution: Out of Date > Enhance the graphical view > -------------------------- > > Key: GPD-293 > URL: https://issues.jboss.org/browse/GPD-293 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > - (optional) labels for transitions, events and gateways > - labels should be movable > - preferences pages (enable/disable nodes) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-285) Support form generation for the new GWT console

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-285?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-285. --------------------------- Resolution: Out of Date > Support form generation for the new GWT console > ----------------------------------------------- > > Key: GPD-285 > URL: https://issues.jboss.org/browse/GPD-285 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 4.x > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Ideally we should be able to produce a file that respects a 'standard' for which there already exist graphical gui builders. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-330) support ESB attributes and elements

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-330?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-330. --------------------------- Resolution: Out of Date > support ESB attributes and elements > ----------------------------------- > > Key: GPD-330 > URL: https://issues.jboss.org/browse/GPD-330 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > attributes: category, service > elements: part -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-291) Enhance the xml source page

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-291?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-291. --------------------------- Resolution: Out of Date > Enhance the xml source page > --------------------------- > > Key: GPD-291 > URL: https://issues.jboss.org/browse/GPD-291 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 4.x > > > - Code completion for class attributes > - Errors shown in problems view (cfr GPD-288) when invalid values are given (e.g. unexisting class, unexisting node name) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-234) Two Nodes with the same name

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-234?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-234. --------------------------- Resolution: Out of Date > Two Nodes with the same name > ---------------------------- > > Key: GPD-234 > URL: https://issues.jboss.org/browse/GPD-234 > Project: jBPM GPD > Issue Type: Bug > Components: jpdl > Affects Versions: jBPM jPDL Designer 3.1.3 > Environment: Eclipse 3.3.2 > Reporter: Sven Daumann > Assignee: Koen Aers > Fix For: jBPM jPDL Designer 3.x > > > step1: Create a Node and put a transition to this Node. > step2: Rename the Node and use the name of an existing Node. > The GPD show both Nodes with Transitions. > step3: Close the diagram > step4: Reopen the diagram > problem: Only one Node is visible, the two transitions go to the one Node. > step5: Move the Node. The moving Node has no transition. Under the moved Node, the other Node is now visible, with both transitions. > During rename, there is no warning, that another Node with the same name exist. > The XML data contains two Nodes. > processdefinition.xml > <?xml version="1.0" encoding="UTF-8"?> > <process-definition xmlns="" name="Test"> > <start-state name="start-state1"> > <transition to="node1" name="startet"></transition> > </start-state> > <node name="node1"> > <transition to="node2" name="ok"></transition> > <transition to="Test" name="toTest"></transition> > </node> > <node name="node2"> > <transition to="end-state1" name="ok"></transition> > <transition to="Test" name="toTest"></transition> > </node> > <task-node name="Test"></task-node> > <task-node name="Test"></task-node> > <end-state name="end-state1"></end-state> > </process-definition> > gpd.xml > <?xml version="1.0" encoding="UTF-8"?> > <root-container name="Test" width="675" height="634"> > <node name="start-state1" x="375" y="272" width="132" height="36"> > <edge> > <label x="5" y="-10"/> > </edge> > </node> > <node name="node1" x="374" y="353" width="132" height="36"> > <edge> > <label x="5" y="-10"/> > </edge> > <edge> > <label x="5" y="-10"/> > </edge> > </node> > <node name="node2" x="378" y="448" width="132" height="36"> > <edge> > <label x="5" y="-10"/> > </edge> > <edge> > <label x="5" y="-10"/> > </edge> > </node> > <node name="end-state1" x="383" y="548" width="132" height="36"/> > <node name="Test" x="172" y="347" width="132" height="36"/> > <node name="Test" x="174" y="451" width="132" height="36"/> > </root-container> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (GPD-337) image clipping

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/GPD-337?page=com.atlassian.jira.plugin.sy... ] Koen Aers resolved GPD-337. --------------------------- Resolution: Out of Date > image clipping > -------------- > > Key: GPD-337 > URL: https://issues.jboss.org/browse/GPD-337 > Project: jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Tom Baeyens > Assignee: Koen Aers > Priority: Minor > Fix For: jBPM jPDL Designer 4.x > > > the generated images are too large. clipping them would be nice to have. > watch out with clipping the top left corner (i assume that is coordinates 0,0). if you clip that while saving the image, then the coordinates in the process, used by the console might be affected. > while clipping the bottom right corner should be possible without problem for the console. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7045) domain-elytron.xml, missing singelton subsystem, different ejb cache type

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7045?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7045: ---------------------------------------- On the EJB3 subsystem it turns out the includes ordering needed reversing for the Elytron configuration. Changes applied to this branch ready to be bundled in a PR upstream: - https://github.com/wildfly-security-incubator/wildfly/tree/elytron_phase_I > domain-elytron.xml, missing singelton subsystem, different ejb cache type > ------------------------------------------------------------------------- > > Key: WFLY-7045 > URL: https://issues.jboss.org/browse/WFLY-7045 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > When I compare domain-elytron.xml to domain.xml, > 1) There is missing org.wildfly.extension.clustering.singleton extension installed. > 2) There is changed ejb cache configuration > 1254c1129 > < <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/> > --- > > <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7045) domain-elytron.xml, missing singelton subsystem, different ejb cache type

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7045?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7045: ---------------------------------------- >From what I can see the latter appears to be a bug in feature pack assembly. The EJB3 Subsystem is defined as: - {code:xml} <subsystem supplement="ha-elytron">ejb3.xml</subsystem> {code} In the subsystem this is defined as: - {code:xml} <supplement name="ha-elytron" includes="ha elytron"/> {code} These in turn are defined as : - {code:xml} <supplement name="ha"> <replacement placeholder="STATEFUL-BEAN"> <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/> </replacement> </supplement> <supplement name="elytron" includes="default"> <replacement placeholder="ELYTRON"> <application-security-domains> <application-security-domain name="other" security-domain="ApplicationDomain"/> </application-security-domains> </replacement> </supplement> {code} But default is defines as: - {code:xml} <supplement name="default"> <replacement placeholder="STATEFUL-BEAN"> <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/> </replacement> </supplement> {code} So somehow the replacement defined in default is used instead of the one defined in ha. > domain-elytron.xml, missing singelton subsystem, different ejb cache type > ------------------------------------------------------------------------- > > Key: WFLY-7045 > URL: https://issues.jboss.org/browse/WFLY-7045 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > When I compare domain-elytron.xml to domain.xml, > 1) There is missing org.wildfly.extension.clustering.singleton extension installed. > 2) There is changed ejb cache configuration > 1254c1129 > < <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/> > --- > > <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1270: ---------------------------------- Component/s: core engine > support fact handle operations for REST APIs on kie server > ---------------------------------------------------------- > > Key: DROOLS-1270 > URL: https://issues.jboss.org/browse/DROOLS-1270 > Project: Drools > Issue Type: Enhancement > Components: core engine, kie server > Affects Versions: 6.5.0.CR1 > Environment: kie server > Reporter: Dan Cimpoesu > Assignee: Mario Fusco > Fix For: 6.5.0.Final > > > Please support fact handle operations for REST APIs on kie server. > Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules. > Operations that require fact handles are: > - delete facts > - update facts -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7044) standalone-elytron.xml , unnecessary unsecure interface

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7044?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7044: ---------------------------------------- Changes applied to this branch ready to be bundled in a PR upstream: - https://github.com/wildfly-security-incubator/wildfly/tree/elytron_phase_I > standalone-elytron.xml , unnecessary unsecure interface > ------------------------------------------------------- > > Key: WFLY-7044 > URL: https://issues.jboss.org/browse/WFLY-7044 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > When I compare standalone-elytron.xml to standalone.xml, there is additional section > {noformat} > </interface> >  > <interface name="unsecure"> >  > <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/> > {noformat} > Is it necessary? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1270: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > support fact handle operations for REST APIs on kie server > ---------------------------------------------------------- > > Key: DROOLS-1270 > URL: https://issues.jboss.org/browse/DROOLS-1270 > Project: Drools > Issue Type: Enhancement > Components: kie server > Affects Versions: 6.5.0.CR1 > Environment: kie server > Reporter: Dan Cimpoesu > Assignee: Mario Fusco > Fix For: 6.5.0.Final > > > Please support fact handle operations for REST APIs on kie server. > Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules. > Operations that require fact handles are: > - delete facts > - update facts -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7047) host-elytron.xml, different jvm settings, unnecesarry unsecure interface

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7047?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7047: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > host-elytron.xml, different jvm settings, unnecesarry unsecure interface > ------------------------------------------------------------------------ > > Key: WFLY-7047 > URL: https://issues.jboss.org/browse/WFLY-7047 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > host-elytron.xml, different jvm settings, unnecesarry unsecure interface > When I compare host-elytron.xml to host.xml, > 1) jvm settings use permgen element > 2) probably unnecesarry configuration of unsecure profile stays there > Is it worth provide elytron-like host-master/host-slave configuration files for convenience? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 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