[JBoss JIRA] (WFLY-10728) RESTEASY008200: JSON Binding deserialization error for valid JSON
by Guido Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-10728?page=com.atlassian.jira.plugin... ]
Guido Schmidt commented on WFLY-10728:
--------------------------------------
On Wildfly 13 it works with a clean WEB-INF/lib folder as well.
Looks like is issue is not reproducable anymore.
> RESTEASY008200: JSON Binding deserialization error for valid JSON
> -----------------------------------------------------------------
>
> Key: WFLY-10728
> URL: https://issues.jboss.org/browse/WFLY-10728
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Environment: JDK-10.0.1
> Reporter: Guido Schmidt
> Assignee: Ron Sigal
> Attachments: TestRestEasy.war, User.java, UserQueryForm.java, UsersApi.java, single-application.zip
>
>
> I found the following regression issue running the code inside an ejb jar:
> In the context of a search for a user for a user via the Wordpress REST API, I get e.g. following String:
> {code:JavaScript}
> {{[{
> "id": 15,
> "username": "wpx1",
> "name": "Word Press1",
> "first_name": "Word",
> "last_name": "Press1",
> "email": "wpx1(a)pb.com",
> "url": "",
> "description": "",
> "link": "http:\/\/www.pbpiazza.com\/dayc\/archives\/author\/wpx1",
> "locale": "en_US",
> "nickname": "wpx1",
> "slug": "wpx1",
> "roles": ["contributor"],
> "registered_date": "2018-07-23T08:59:13+00:00",
> "capabilities": {
> "edit_posts": true,
> "read": true,
> "level_1": true,
> "level_0": true,
> "delete_posts": true,
> "manage_bookings": true,
> "upload_event_images": true,
> "delete_events": true,
> "edit_events": true,
> "read_private_events": true,
> "delete_recurring_events": true,
> "edit_recurring_events": true,
> "edit_locations": true,
> "read_private_locations": true,
> "read_others_locations": true,
> "contributor": true
> },
> "extra_capabilities": {
> "contributor": true
> },
> "avatar_urls": {
> "24": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=24&d=mm&r=g",
> "48": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=48&d=mm&r=g",
> "96": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=96&d=mm&r=g"
> },
> "meta": [],
> "_links": {
> "self": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users\/15"
> }
> ],
> "collection": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users"
> }
> ]
> }
> }
> ]}}
> {code}
> This is achieved by a call of the UsersApi method listUsersAsString:
>
> ResteasyWebTarget target = (ResteasyWebTarget)restEasy.target(uri);
> target.proxy(UsersApi.class);
> The call rendering the result into a List<User> fails with error message in the subject.
> The result is perfectly fine running Wildfly 11.Plain test cases with Wildfly 13 libraries is also fine. It seems to be a runtime configuration issue of RESTEasy in WIldfly 13.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10872) Missing translation for writing simple-load-provider attribute in mod_cluster subsystem
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-10872?page=com.atlassian.jira.plugin... ]
Jan Kašík updated WFLY-10872:
-----------------------------
Workaround Description:
{code}
/subsystem=modcluster/proxy=default/load-provider=simple:add(factor=0)
{code}
Workaround: Workaround Exists
> Missing translation for writing simple-load-provider attribute in mod_cluster subsystem
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-10872
> URL: https://issues.jboss.org/browse/WFLY-10872
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
>
> Following should add simple load provider with factor=0:
> {code}
> /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=simple-load-provider, value=0)
> {code}
> Instead, this error shows up:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"modcluster\"),
> (\"proxy\" => \"default\"),
> (\"load-provider\" => \"simple\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> There is missing translation to create the resource, same is the situation for undefine operation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10728) RESTEASY008200: JSON Binding deserialization error for valid JSON
by Guido Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-10728?page=com.atlassian.jira.plugin... ]
Guido Schmidt commented on WFLY-10728:
--------------------------------------
[^TestRestEasy.war] Sorry, I'm a bit stressed out currently. Attached is a small war with sources which comes with its own Jackson dependencies and a hard coded access to a Wordpress instance.
"Unfortunately" this example runs fine in all Wildfly versions. The difference to my real world project is however that it nails down the used Jackson libraries in the lib.
> RESTEASY008200: JSON Binding deserialization error for valid JSON
> -----------------------------------------------------------------
>
> Key: WFLY-10728
> URL: https://issues.jboss.org/browse/WFLY-10728
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Environment: JDK-10.0.1
> Reporter: Guido Schmidt
> Assignee: Ron Sigal
> Attachments: TestRestEasy.war, User.java, UserQueryForm.java, UsersApi.java, single-application.zip
>
>
> I found the following regression issue running the code inside an ejb jar:
> In the context of a search for a user for a user via the Wordpress REST API, I get e.g. following String:
> {code:JavaScript}
> {{[{
> "id": 15,
> "username": "wpx1",
> "name": "Word Press1",
> "first_name": "Word",
> "last_name": "Press1",
> "email": "wpx1(a)pb.com",
> "url": "",
> "description": "",
> "link": "http:\/\/www.pbpiazza.com\/dayc\/archives\/author\/wpx1",
> "locale": "en_US",
> "nickname": "wpx1",
> "slug": "wpx1",
> "roles": ["contributor"],
> "registered_date": "2018-07-23T08:59:13+00:00",
> "capabilities": {
> "edit_posts": true,
> "read": true,
> "level_1": true,
> "level_0": true,
> "delete_posts": true,
> "manage_bookings": true,
> "upload_event_images": true,
> "delete_events": true,
> "edit_events": true,
> "read_private_events": true,
> "delete_recurring_events": true,
> "edit_recurring_events": true,
> "edit_locations": true,
> "read_private_locations": true,
> "read_others_locations": true,
> "contributor": true
> },
> "extra_capabilities": {
> "contributor": true
> },
> "avatar_urls": {
> "24": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=24&d=mm&r=g",
> "48": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=48&d=mm&r=g",
> "96": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=96&d=mm&r=g"
> },
> "meta": [],
> "_links": {
> "self": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users\/15"
> }
> ],
> "collection": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users"
> }
> ]
> }
> }
> ]}}
> {code}
> This is achieved by a call of the UsersApi method listUsersAsString:
>
> ResteasyWebTarget target = (ResteasyWebTarget)restEasy.target(uri);
> target.proxy(UsersApi.class);
> The call rendering the result into a List<User> fails with error message in the subject.
> The result is perfectly fine running Wildfly 11.Plain test cases with Wildfly 13 libraries is also fine. It seems to be a runtime configuration issue of RESTEasy in WIldfly 13.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4002) JDK11 Some security tests fail on closed channel exception
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4002?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-4002:
-------------------------------------
Summary: JDK11 Some security tests fail on closed channel exception (was: Some security tests fail on closed channel exception)
> JDK11 Some security tests fail on closed channel exception
> ----------------------------------------------------------
>
> Key: WFCORE-4002
> URL: https://issues.jboss.org/browse/WFCORE-4002
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Test Suite
> Affects Versions: 6.0.0.Alpha5
> Reporter: Richard Opalka
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: jdk11
> Fix For: 6.0.0.CR2
>
>
> With latest JDK11 (build 11-ea+25) the following tests fail due to closed channel exception:
> * domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AuditLogHandlerBootEnabledTestCase.java
> * testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/HTTPSManagementInterfaceTestCase.java
> * testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java
> * testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/ScramPlusMgmtSaslTestCase.java
> * testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfaceTestCase.java
> Is there a known SSL issue in JDK11? Could somebody from our security team investigate this issue?
> When these tests will start passing WFCORE test suite will be passing 100% of tests on JDK11.
> Potential investigator from our security team may want to include this PR:
> https://github.com/wildfly/wildfly-core/pull/3420
> to fix known JDK11 issues.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10812) JDK11 Some security tests fail on closed channel exception
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-10812?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFLY-10812:
------------------------------------
Summary: JDK11 Some security tests fail on closed channel exception (was: Some security tests fail on closed channel exception)
> JDK11 Some security tests fail on closed channel exception
> ----------------------------------------------------------
>
> Key: WFLY-10812
> URL: https://issues.jboss.org/browse/WFLY-10812
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Richard Opalka
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> With latest JDK11 (build 11-ea+25) the following tests fail due to closed channel exception: modified:
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapExtLikeAdvancedLdapLMTestCase.java
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapExtLoginModuleTestCase.java
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapLoginModuleTestCase.java
> * testsuite/integration/elytron/src/test/java/org/wildfly/test/integration/elytron/ssl/UndertowTwoWaySslNeedClientAuthTestCase.java
> * testsuite/integration/iiop/src/test/java/org/jboss/as/test/iiopssl/basic/IIOPSslInvocationTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/security/OutboundLdapConnectionClientCertTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/security/OutboundLdapConnectionTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/CertificateRolesLoginModuleTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/DatabaseCertLoginModuleTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/HTTPSWebConnectorTestCase.java
> * testsuite/integration/ws/src/test/java/org/jboss/as/test/integration/ws/wsse/trust/WSTrustTestCase.java
> Is there a known SSL issue in JDK11? Could somebody from our security team investigate this issue?
> When these tests will start passing WF test suite will be passing 100% of tests on JDK11.
> Potential investigator from our security team may want to include this PR:
> https://github.com/wildfly/wildfly/pull/11499
> to fix known JDK11 issues.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10728) RESTEASY008200: JSON Binding deserialization error for valid JSON
by Guido Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-10728?page=com.atlassian.jira.plugin... ]
Guido Schmidt updated WFLY-10728:
---------------------------------
Attachment: TestRestEasy.war
> RESTEASY008200: JSON Binding deserialization error for valid JSON
> -----------------------------------------------------------------
>
> Key: WFLY-10728
> URL: https://issues.jboss.org/browse/WFLY-10728
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Environment: JDK-10.0.1
> Reporter: Guido Schmidt
> Assignee: Ron Sigal
> Attachments: TestRestEasy.war, User.java, UserQueryForm.java, UsersApi.java, single-application.zip
>
>
> I found the following regression issue running the code inside an ejb jar:
> In the context of a search for a user for a user via the Wordpress REST API, I get e.g. following String:
> {code:JavaScript}
> {{[{
> "id": 15,
> "username": "wpx1",
> "name": "Word Press1",
> "first_name": "Word",
> "last_name": "Press1",
> "email": "wpx1(a)pb.com",
> "url": "",
> "description": "",
> "link": "http:\/\/www.pbpiazza.com\/dayc\/archives\/author\/wpx1",
> "locale": "en_US",
> "nickname": "wpx1",
> "slug": "wpx1",
> "roles": ["contributor"],
> "registered_date": "2018-07-23T08:59:13+00:00",
> "capabilities": {
> "edit_posts": true,
> "read": true,
> "level_1": true,
> "level_0": true,
> "delete_posts": true,
> "manage_bookings": true,
> "upload_event_images": true,
> "delete_events": true,
> "edit_events": true,
> "read_private_events": true,
> "delete_recurring_events": true,
> "edit_recurring_events": true,
> "edit_locations": true,
> "read_private_locations": true,
> "read_others_locations": true,
> "contributor": true
> },
> "extra_capabilities": {
> "contributor": true
> },
> "avatar_urls": {
> "24": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=24&d=mm&r=g",
> "48": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=48&d=mm&r=g",
> "96": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=96&d=mm&r=g"
> },
> "meta": [],
> "_links": {
> "self": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users\/15"
> }
> ],
> "collection": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users"
> }
> ]
> }
> }
> ]}}
> {code}
> This is achieved by a call of the UsersApi method listUsersAsString:
>
> ResteasyWebTarget target = (ResteasyWebTarget)restEasy.target(uri);
> target.proxy(UsersApi.class);
> The call rendering the result into a List<User> fails with error message in the subject.
> The result is perfectly fine running Wildfly 11.Plain test cases with Wildfly 13 libraries is also fine. It seems to be a runtime configuration issue of RESTEasy in WIldfly 13.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10833) Wildfly 13.0.0.Final deployment failed due to WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-10833?page=com.atlassian.jira.plugin... ]
Tom Jenkinson reassigned WFLY-10833:
------------------------------------
Assignee: Ondra Chaloupka (was: Tom Jenkinson)
> Wildfly 13.0.0.Final deployment failed due to WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10833
> URL: https://issues.jboss.org/browse/WFLY-10833
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 13.0.0.Final
> Environment: JDK 8
> Wildfly 13.0.0.Final
> Reporter: Angela Yuan
> Assignee: Ondra Chaloupka
>
> Able to deploy the same WAR and EAR to Wildfly 10.0.0.Final but not to 13.0.0.Final with the following error:
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."xxxxx.war".WeldStartService: org.jboss.msc.service.S
> tartException in service jboss.deployment.unit."fwdm-services-1.0-SNAPSHOT.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default
> at injection point [UnbackedAnnotatedField] @Inject org.jboss.narayana.compensations.impl.CancelOnFailureInterceptor.compensationManager
> at org.jboss.narayana.compensations.impl.CancelOnFailureInterceptor.compensationManager(CancelOnFailureInterceptor.java:0)
> Possible dependencies:
> - Managed Bean [class org.jboss.narayana.compensations.internal.CompensationManagerImpl] with qualifiers [@Any @Default],
> - Managed Bean [class org.jboss.narayana.compensations.impl.CompensationManagerImpl] with qualifiers [@Any @Default]
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:386)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
> at org.jboss.weld.bootstrap.Validator.validateInterceptor(Validator.java:564)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:81)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:79)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-72) Critical IO Error ... when starting Artemis with HA JDBC store
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-72?page=com.atlassian.jira.plugin.s... ]
Erich Duda commented on WFWIP-72:
---------------------------------
This issue is fixed in Artemis master by commit [06f6892|https://github.com/apache/activemq-artemis/commit/06f689245427e95...] but the fix is not in Artemis 1.5.x.
> Critical IO Error ... when starting Artemis with HA JDBC store
> --------------------------------------------------------------
>
> Key: WFWIP-72
> URL: https://issues.jboss.org/browse/WFWIP-72
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: log-node-1.zip
>
>
> One of the servers in collocated HA topology with JDBC store can fail on critical IO exception and stop itself.
> This was hit on Artemis 1.5.5.012 and WF: https://github.com/jmesnil/wildfly - WFLY-9513_messaging_jdbc_HA_shared-store branch.
> Test scenario:
> * Start 2 WF/EAP servers in collocated topology with Artemis HA JDBC store
> * Start client which are sending and consuming messages to/from queue from 1st server
> Result:
> There is intermittent failure when client start to send/receive messages on 1st server. 1st fails on Critical IO Error with exception:
> {code}
> 10:19:27,965 WARN [org.apache.activemq.artemis.journal] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7de7cbe3)) AMQ142021: Error on IO callback, null
> 10:19:27,965 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7de7cbe3)) AMQ222010: Critical IO Error, shutting down the server. file=org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile@407c5d8f, message=Error writing to JDBC file.: java.lang.NullPointerException
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.internalWrite(JDBCSequentialFile.java:161) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.internalWrite(JDBCSequentialFile.java:186) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.lambda$scheduleWrite$1(JDBCSequentialFile.java:197) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
> NPE happens at {{JDBCSequentialFile.internalWrite}} line 161:
> {code}
> private synchronized int internalWrite(byte[] data, IOCallback callback) {
> try {
> open();
> 161 synchronized (writeLock) { <-- NPE is thrown here
> ...
> {code}
> .
> Attaching logs from the test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4030) Upgrade to Galleon and WildFly Galleon Plugins 2.0.0.Beta1
by Grzegorz Grzybek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4030?page=com.atlassian.jira.plugi... ]
Grzegorz Grzybek commented on WFCORE-4030:
------------------------------------------
[~aloubyansky] I tried building wildfly/wildfly-core (master branch) with this fix, but the build stopped at {{wildfly-core-galleon-pack}} artifact with this thread blocked:
{noformat}
"main" #1 prio=5 os_prio=0 tid=0x00007f408800c800 nid=0x4b0d in Object.wait() [0x00007f40908fd000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x000000071dd23760> (a org.jboss.as.server.FutureServiceContainer)
at java.lang.Object.wait(Object.java:502)
at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:174)
- locked <0x000000071dd23760> (a org.jboss.as.server.FutureServiceContainer)
at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:248)
- locked <0x000000071dd23760> (a org.jboss.as.server.FutureServiceContainer)
at org.wildfly.core.embedded.EmbeddedStandaloneServerFactory$StandaloneServerImpl.start(EmbeddedStandaloneServerFactory.java:301)
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.wildfly.core.embedded.EmbeddedManagedProcessImpl.invokeOnServer(EmbeddedManagedProcessImpl.java:88)
at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.start(EmbeddedManagedProcessImpl.java:58)
at org.wildfly.galleon.plugin.featurespec.generator.FeatureSpecGenerator.readFeatureSpecs(FeatureSpecGenerator.java:265)
at org.wildfly.galleon.plugin.featurespec.generator.FeatureSpecGenerator.forkedForEmbedded(FeatureSpecGenerator.java:213)
at org.wildfly.galleon.plugin.server.ForkedEmbeddedUtil.main(ForkedEmbeddedUtil.java:195)
{noformat}
After I reverted [this commit|https://github.com/wildfly/wildfly-core/commit/396b936bd12bc9be58a...] the build went fine...
> Upgrade to Galleon and WildFly Galleon Plugins 2.0.0.Beta1
> ----------------------------------------------------------
>
> Key: WFCORE-4030
> URL: https://issues.jboss.org/browse/WFCORE-4030
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Build System
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Fix For: 6.0.0.CR1
>
>
> Upgrade to the latest Galleon and WFGP 2.x release.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months