[JBoss JIRA] (DROOLS-974) Activation group doesn't work as expected
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-974?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-974.
--------------------------------
Fix Version/s: 7.0.0.Final
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/bd4674dc4
> Activation group doesn't work as expected
> -----------------------------------------
>
> Key: DROOLS-974
> URL: https://issues.jboss.org/browse/DROOLS-974
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Environment: Mac OS X 10.8.3
> jdk 1.7.0_60
> Reporter: Hanbing Luo
> Assignee: Mario Fusco
> Fix For: 7.0.0.Final
>
>
> In some rare cases activation group doesn't work as expected. For example, two rules with same ruleflow-group and activation-group but different salience are both get fired if reuse kie session.
> Some investigation notes to help address.
> 1) This issue never happen if use a new fresh kie session.
> 2) I also tried to write a drools style unit test (testActivationGroupIssue in ExecutionFlowControlTest.java) but can't reproduce this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2028) GMS sometimes ignores view bundling timeout
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2028?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2028:
---------------------------
Fix Version/s: 3.6.9
4.0
> GMS sometimes ignores view bundling timeout
> -------------------------------------------
>
> Key: JGRP-2028
> URL: https://issues.jboss.org/browse/JGRP-2028
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.9, 4.0
>
>
> {{GMS.ViewHandler.run()}} has this code:
> {code}
> wait_time=timeout - (System.nanoTime() - start_time);
> if(wait_time > 0 && firstRequest.canBeProcessedTogether(firstRequest)) { // JGRP-1438
> long wait_time_ms=TimeUnit.MILLISECONDS.convert(wait_time, TimeUnit.NANOSECONDS);
> queue.waitUntilClosed(wait_time_ms); // misnomer: waits until element has been added or q closed
> }
> {code}
> The problem is {{wait_time_ms}} will be {{0}} if {{0 < wait_time < 1_000_000}}. {{queue.waitUntilClosed(wait_time_ms)}} then calls {{Object.wait(0)}} and blocks forever.
> Fortunately, the joiners re-sends the {{JOIN_REQ}} message after {{GMS.join_timeout}} (3s by default), so all that happens is that the view is delayed by 3s. It does cause some random failures in tests that expect the view to form in a precise amount of time, though.
> {noformat}
> 17:04:53,034 DEBUG (ForkThread-3,InitialClusterSizeTest:) [GMS] NodeF-49399: sending JOIN(NodeF-49399) to NodeE-37644
> 17:04:53,034 TRACE (ForkThread-3,InitialClusterSizeTest:) [TCP_NIO2] NodeF-49399: sending msg to NodeE-37644, src=NodeF-49399, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN]
> 17:04:53,035 DEBUG (ForkThread-4,InitialClusterSizeTest:) [GMS] NodeG-49307: sending JOIN(NodeG-49307) to NodeE-37644
> 17:04:53,035 TRACE (ForkThread-4,InitialClusterSizeTest:) [TCP_NIO2] NodeG-49307: sending msg to NodeE-37644, src=NodeG-49307, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN]
> 17:04:53,060 TRACE (INT-1,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeF-49399 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN]
> 17:04:53,060 TRACE (INT-2,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeG-49307 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN]
> 17:04:53,060 TRACE (INT-1,NodeE-37644:) [UNICAST3] NodeE-37644 <-- DATA(NodeF-49399: #1, conn_id=0, first)
> 17:04:53,060 TRACE (INT-2,NodeE-37644:) [UNICAST3] NodeE-37644 <-- DATA(NodeG-49307: #1, conn_id=0, first)
> 17:04:53,061 TRACE (INT-2,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeG-49307#1
> 17:04:53,061 TRACE (INT-1,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeF-49399#1
> 17:04:56,035 WARN (ForkThread-3,InitialClusterSizeTest:) [GMS] NodeF-49399: JOIN(NodeF-49399) sent to NodeE-37644 timed out (after 3000 ms), on try 1
> 17:04:56,035 WARN (ForkThread-4,InitialClusterSizeTest:) [GMS] NodeG-49307: JOIN(NodeG-49307) sent to NodeE-37644 timed out (after 3000 ms), on try 1
> 17:04:56,036 DEBUG (ForkThread-3,InitialClusterSizeTest:) [GMS] NodeF-49399: sending JOIN(NodeF-49399) to NodeE-37644
> 17:04:56,036 TRACE (ForkThread-3,InitialClusterSizeTest:) [TCP_NIO2] NodeF-49399: sending msg to NodeE-37644, src=NodeF-49399, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN]
> 17:04:56,036 DEBUG (ForkThread-4,InitialClusterSizeTest:) [GMS] NodeG-49307: sending JOIN(NodeG-49307) to NodeE-37644
> 17:04:56,036 TRACE (ForkThread-4,InitialClusterSizeTest:) [TCP_NIO2] NodeG-49307: sending msg to NodeE-37644, src=NodeG-49307, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN]
> 17:04:56,057 TRACE (INT-1,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeF-49399 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN]
> 17:04:56,057 TRACE (INT-2,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeG-49307 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN]
> 17:04:56,057 TRACE (INT-2,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeG-49307#2
> 17:04:56,057 TRACE (INT-1,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeF-49399#2
> # finally
> 17:04:56,057 TRACE (ViewHandler,NodeE-37644:) [GMS] NodeE-37644: joiners=[NodeG-49307, NodeF-49399], suspected=[], leaving=[], new view: [NodeE-37644|1] (3) [NodeE-37644, NodeG-49307, NodeF-49399]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6377) Composite Keys -- org.hibernate.property.access.spi.PropertyAccessException: Error accessing field
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6377?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-6377.
------------------------------
Fix Version/s: 10.1.0.Final
Resolution: Done
Closing as will be fixed by Hibernate 5.0.9 which is already in the WildFly master branch.
> Composite Keys -- org.hibernate.property.access.spi.PropertyAccessException: Error accessing field
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6377
> URL: https://issues.jboss.org/browse/WFLY-6377
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Environment: Mac OSX, Wildfly 10.0, Hibernate 5.0/5.1, PostgreSQL 9.3
> Reporter: Akhbar Falafel
> Assignee: Scott Marlow
> Fix For: 10.1.0.Final
>
> Attachments: out.log
>
>
> I have 2 entity classes mapped in Hibernate 5.1: ProductBean and CommentBean. They are pretty simple, and look something like this...
> {code:java}
> @Entity(name = "Comment")
> @Table(name = "tbl_comment")
> public class CommentBean implements Serializable {
> @Id
> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_comment_id")
> @SequenceGenerator(name = "seq_comment_id", sequenceName = "seq_comment_id", allocationSize = 1)
> private Long id = null;
> ...
> }
> @Entity(name = "Product")
> @Table(name = "tbl_product")
> public class CommentBean implements Serializable {
> @Id
> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_product_id")
> @SequenceGenerator(name = "seq_product_id", sequenceName = "seq_product_id", allocationSize = 1)
> private Long id = null;
> @ManyToMany(cascade = CascadeType.MERGE)
> @JoinTable(name = "tbl_product_comments", joinColumns = {
> @JoinColumn(name = "product_id", referencedColumnName = "id") }, inverseJoinColumns = {
> @JoinColumn(name = "comment_id", referencedColumnName = "id") }, uniqueConstraints = {
> @UniqueConstraint(columnNames = { "product_id", "comment_id" }) })
> @IndexedEmbedded
> @OrderBy(value = "createdDate ASC")
> private Set<CommentBean> comments = new LinkedHashSet<>();
> ...
> }
> {code}
> I'm trying to map the Many-To-Many relation for the comments property in its own class, so that I can add additional properties to the relation in the future. The mapping class looks like this:
> {code:java}
> @Entity(name = "ProductComment")
> @Table(name = "tbl_product_comments")
> public class ProductCommentBean implements Serializable {
> private static final long serialVersionUID = 4730115318809856150L;
> @ManyToOne(optional = false)
> @JoinColumn(name = "productID", referencedColumnName = "id", nullable = false, insertable = false, updatable = false)
> @NotNull
> private ProductBean answer = null;
> @ManyToOne(optional = false)
> @JoinColumn(name = "comment_id", referencedColumnName = "id", nullable = false, insertable = false, updatable = false)
> @NotNull
> private CommentBean comment = null;
> @EmbeddedId
> private ID id = new ID();
> @Embeddable
> public static class ID implements Serializable {
> @Column(name = "product_id")
> private Long productID = null;
> @Column(name = "comment_id")
> private Long commentID = null;
> @Override
> public boolean equals(final Object other) {
> if (this == other) {
> return true;
> }
> if (!(other instanceof ID)) {
> return false;
> }
> ID castOther = (ID) other;
> return new EqualsBuilder().append(productID, castOther. productID).append(commentID, castOther.commentID)
> .isEquals();
> }
> @Override
> public int hashCode() {
> return new HashCodeBuilder(-2081682373, -1619249).append(productID).append(commentID).toHashCode();
> }
> public ID() {
> super();
> // TODO Auto-generated constructor stub
> }
> public ID(Long productID, Long commentID) {
> super();
> this.productID = productID;
> this.commentID = commentID;
> }
> }
> public ProductCommentBean(ProductBean product, CommentBean comment) {
> super();
> this.product = product;
> this.comment = comment;
> this.id.productID =product.getId();
> this.id.commentID = comment.getId();
> }
> }
> ...
> }
> {code}
> Upon my first deployment, I am able to create a ProductCommentBean object and save it to the database successfully. However, if I run a "clean" during development, the subsequent call to save a ProductCommentBean object results in the following exception:
> ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.hibernate.property.access.spi.PropertyAccessException: Error accessing field [private java.lang.Long com.test.ProductCommentBean$ID.productID] by reflection for persistent property [com.test.ProductCommentBean$ID#productID] : com.test.ProductCommentBean$ID@a8a90e31
> If I do a shutdown and restart of the server, I am once again able to save a ProductCommentBean object the first time. A clean again, however, will set it back to the error state.
> I have tested this code on Wildfly 10 and JBoss EAP 7.0 Beta, and receive the same results. I've also tested it using Hibernate 5.0 and 5.1, also with the same results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6377) Composite Keys -- org.hibernate.property.access.spi.PropertyAccessException: Error accessing field
by Akhbar Falafel (JIRA)
[ https://issues.jboss.org/browse/WFLY-6377?page=com.atlassian.jira.plugin.... ]
Akhbar Falafel commented on WFLY-6377:
--------------------------------------
[~smarlow] Looks like you are correct. I just added a 5.0.9 Hibernate module to Wildfly and was unable to reproduce the problem.
> Composite Keys -- org.hibernate.property.access.spi.PropertyAccessException: Error accessing field
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6377
> URL: https://issues.jboss.org/browse/WFLY-6377
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Environment: Mac OSX, Wildfly 10.0, Hibernate 5.0/5.1, PostgreSQL 9.3
> Reporter: Akhbar Falafel
> Assignee: Scott Marlow
> Attachments: out.log
>
>
> I have 2 entity classes mapped in Hibernate 5.1: ProductBean and CommentBean. They are pretty simple, and look something like this...
> {code:java}
> @Entity(name = "Comment")
> @Table(name = "tbl_comment")
> public class CommentBean implements Serializable {
> @Id
> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_comment_id")
> @SequenceGenerator(name = "seq_comment_id", sequenceName = "seq_comment_id", allocationSize = 1)
> private Long id = null;
> ...
> }
> @Entity(name = "Product")
> @Table(name = "tbl_product")
> public class CommentBean implements Serializable {
> @Id
> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_product_id")
> @SequenceGenerator(name = "seq_product_id", sequenceName = "seq_product_id", allocationSize = 1)
> private Long id = null;
> @ManyToMany(cascade = CascadeType.MERGE)
> @JoinTable(name = "tbl_product_comments", joinColumns = {
> @JoinColumn(name = "product_id", referencedColumnName = "id") }, inverseJoinColumns = {
> @JoinColumn(name = "comment_id", referencedColumnName = "id") }, uniqueConstraints = {
> @UniqueConstraint(columnNames = { "product_id", "comment_id" }) })
> @IndexedEmbedded
> @OrderBy(value = "createdDate ASC")
> private Set<CommentBean> comments = new LinkedHashSet<>();
> ...
> }
> {code}
> I'm trying to map the Many-To-Many relation for the comments property in its own class, so that I can add additional properties to the relation in the future. The mapping class looks like this:
> {code:java}
> @Entity(name = "ProductComment")
> @Table(name = "tbl_product_comments")
> public class ProductCommentBean implements Serializable {
> private static final long serialVersionUID = 4730115318809856150L;
> @ManyToOne(optional = false)
> @JoinColumn(name = "productID", referencedColumnName = "id", nullable = false, insertable = false, updatable = false)
> @NotNull
> private ProductBean answer = null;
> @ManyToOne(optional = false)
> @JoinColumn(name = "comment_id", referencedColumnName = "id", nullable = false, insertable = false, updatable = false)
> @NotNull
> private CommentBean comment = null;
> @EmbeddedId
> private ID id = new ID();
> @Embeddable
> public static class ID implements Serializable {
> @Column(name = "product_id")
> private Long productID = null;
> @Column(name = "comment_id")
> private Long commentID = null;
> @Override
> public boolean equals(final Object other) {
> if (this == other) {
> return true;
> }
> if (!(other instanceof ID)) {
> return false;
> }
> ID castOther = (ID) other;
> return new EqualsBuilder().append(productID, castOther. productID).append(commentID, castOther.commentID)
> .isEquals();
> }
> @Override
> public int hashCode() {
> return new HashCodeBuilder(-2081682373, -1619249).append(productID).append(commentID).toHashCode();
> }
> public ID() {
> super();
> // TODO Auto-generated constructor stub
> }
> public ID(Long productID, Long commentID) {
> super();
> this.productID = productID;
> this.commentID = commentID;
> }
> }
> public ProductCommentBean(ProductBean product, CommentBean comment) {
> super();
> this.product = product;
> this.comment = comment;
> this.id.productID =product.getId();
> this.id.commentID = comment.getId();
> }
> }
> ...
> }
> {code}
> Upon my first deployment, I am able to create a ProductCommentBean object and save it to the database successfully. However, if I run a "clean" during development, the subsequent call to save a ProductCommentBean object results in the following exception:
> ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.hibernate.property.access.spi.PropertyAccessException: Error accessing field [private java.lang.Long com.test.ProductCommentBean$ID.productID] by reflection for persistent property [com.test.ProductCommentBean$ID#productID] : com.test.ProductCommentBean$ID@a8a90e31
> If I do a shutdown and restart of the server, I am once again able to save a ProductCommentBean object the first time. A clean again, however, will set it back to the error state.
> I have tested this code on Wildfly 10 and JBoss EAP 7.0 Beta, and receive the same results. I've also tested it using Hibernate 5.0 and 5.1, also with the same results.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1437) Using JKS truststore leads to "FIPS mode: only SunJSSE TrustManagers may be used"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1437?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-3853 to WFCORE-1437:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1437 (was: JBEAP-3853)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.1.0.CR1
(was: 7.0.0.ER6)
> Using JKS truststore leads to "FIPS mode: only SunJSSE TrustManagers may be used"
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-1437
> URL: https://issues.jboss.org/browse/WFCORE-1437
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.1.0.CR1
> Environment: Oracle java in Fips mode
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> User can't start domain in FIPS mode when JKS truststore is used in master <-> slave host controllers communication. (Using PKCS11 keystore works well)
> {code}
> [Host Controller] ^[[0m^[[31m15:52:23,822 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.server.controller.management.security_realm.SlaveManagementRealm.ssl-context-trust-only: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.SlaveManagementRealm.ssl-context-trust-only: WFLYDM0018: Unable to start service^[[0m
> [Host Controller] ^[[31m at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:124)^[[0m
> [Host Controller] ^[[31m at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)^[[0m
> [Host Controller] ^[[31m at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)^[[0m
> [Host Controller] ^[[31m at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)^[[0m
> [Host Controller] ^[[31m at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)^[[0m
> [Host Controller] ^[[31m at java.lang.Thread.run(Thread.java:745)^[[0m
> [Host Controller] ^[[31mCaused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used^[[0m
> [Host Controller] ^[[31m at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:124)^[[0m
> [Host Controller] ^[[31m at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:87)^[[0m
> [Host Controller] ^[[31m at javax.net.ssl.SSLContext.init(SSLContext.java:282)^[[0m
> [Host Controller] ^[[31m at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:87)^[[0m
> [Host Controller] ^[[31m ... 5 more^[[0m
> [Hos
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1437) Using JKS truststore leads to "FIPS mode: only SunJSSE TrustManagers may be used"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1437?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1437:
-------------------------------------
Fix Version/s: 2.1.0.CR2
> Using JKS truststore leads to "FIPS mode: only SunJSSE TrustManagers may be used"
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-1437
> URL: https://issues.jboss.org/browse/WFCORE-1437
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.1.0.CR1
> Environment: Oracle java in Fips mode
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 2.1.0.CR2
>
>
> User can't start domain in FIPS mode when JKS truststore is used in master <-> slave host controllers communication. (Using PKCS11 keystore works well)
> {code}
> [Host Controller] ^[[0m^[[31m15:52:23,822 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.server.controller.management.security_realm.SlaveManagementRealm.ssl-context-trust-only: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.SlaveManagementRealm.ssl-context-trust-only: WFLYDM0018: Unable to start service^[[0m
> [Host Controller] ^[[31m at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:124)^[[0m
> [Host Controller] ^[[31m at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)^[[0m
> [Host Controller] ^[[31m at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)^[[0m
> [Host Controller] ^[[31m at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)^[[0m
> [Host Controller] ^[[31m at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)^[[0m
> [Host Controller] ^[[31m at java.lang.Thread.run(Thread.java:745)^[[0m
> [Host Controller] ^[[31mCaused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used^[[0m
> [Host Controller] ^[[31m at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:124)^[[0m
> [Host Controller] ^[[31m at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:87)^[[0m
> [Host Controller] ^[[31m at javax.net.ssl.SSLContext.init(SSLContext.java:282)^[[0m
> [Host Controller] ^[[31m at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:87)^[[0m
> [Host Controller] ^[[31m ... 5 more^[[0m
> [Hos
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-1730) Wrong TCCL during ValidatorFactory retrieval
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1730?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-1730:
---------------------------------------
[~brian.stansberry] WFLY-6384 created to fix this, thanks.
> Wrong TCCL during ValidatorFactory retrieval
> --------------------------------------------
>
> Key: WFLY-1730
> URL: https://issues.jboss.org/browse/WFLY-1730
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.0.0.Alpha3
> Reporter: Jozef Hartinger
> Assignee: Eduardo Martins
> Fix For: 8.0.0.Alpha4
>
>
> Here https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss...
> the TCCL is set to the classloader of the ValidatorFactory. If the ValidatorFactory is LazyValidatorFactory which delegates to a client proxy obtained from Weld, this call fails with
> {noformat}
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for ModuleClassLoader for Module "org.jboss.as.ee:main" from local module loader @76724357 (finder: local module finder @47a34181 (r$
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75) [wildfly-weld-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> at org.jboss.weld.Container.instance(Container.java:54) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:70) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.proxies.ValidatorFactory$618047133$Proxy$_$$_WeldClientProxy.getValidator(Unknown Source) [weld-core-impl-2.0.2.Final.jar:]
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:83)
> at org.jboss.as.ee.beanvalidation.ValidatorJndiInjectable.getInstanceSafely(ValidatorJndiInjectable.java:53)
> at org.jboss.as.ee.beanvalidation.ValidatorJndiInjectable.getInstanceClassName(ValidatorJndiInjectable.java:61)
> at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:176)
> at org.jboss.as.naming.NamingContext.list(NamingContext.java:323)
> at org.jboss.as.naming.InitialContext.list(InitialContext.java:140)
> at org.jboss.as.naming.NamingContext.list(NamingContext.java:339)
> at javax.naming.InitialContext.list(InitialContext.java:455) [rt.jar:1.7.0_25]
> at org.jboss.as.test.integration.web.injection.SimpleServlet.testAS7_5347(SimpleServlet.java:59) [classes:]
> ... 29 more
> {noformat}
> My assumption is that setting the TCCL is not necessary here at all though I may be wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month