[JBoss JIRA] (WFLY-8966) EJB subsystem thread-pool statistics largest-thread-count is counting threads instead of show the peak of parallel use
by Petr Jurak (JIRA)
[ https://issues.jboss.org/browse/WFLY-8966?page=com.atlassian.jira.plugin.... ]
Petr Jurak reassigned WFLY-8966:
--------------------------------
Assignee: Petr Jurak (was: Tomasz Adamski)
> EJB subsystem thread-pool statistics largest-thread-count is counting threads instead of show the peak of parallel use
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8966
> URL: https://issues.jboss.org/browse/WFLY-8966
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Wolf-Dieter Fink
> Assignee: Petr Jurak
> Attachments: ejb31-timer.jar
>
>
> The description of "largest-thread-count" is
> => "The largest number of threads that have ever simultaneously been in the pool."
> But the behaviour at runtime shows that it is handled similar to task-count.
> If only one thread is used it will increased for every invocation until max-threads.
> As result the largest-thread-count is == max-threads after a short time.
> The helpful metrict to check whether the threads are exhaused is missing!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9487) Missing transformers for iona in jacorb subsystem (JacORB to IIOP-OpenJDK :migrate operation)
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-9487?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-9487:
--------------------------------------
I've updated the MR. iona was included in collection of attributes to ignore which was not applied for expressions (I'll file a jira for this, but this is not a serious issue).
> Missing transformers for iona in jacorb subsystem (JacORB to IIOP-OpenJDK :migrate operation)
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-9487
> URL: https://issues.jboss.org/browse/WFLY-9487
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
> Priority: Blocker
>
> Server not staring after succesful migration operation. This issue happens when interoperability IONA on subsystem JacORB is turned on. Tthis functionality was added to IIOP-OpenJDK(see JBEAP-12912) In the latest build(7.1.0.CR3).
> When IONA is turned on, configuration file contains setting
> {code}
> <interop iona="on">
> {code}
> During migration from JacORB to IIOP-OpenJDK using /subsystem=jacorb:migrate this setting is also migrated:
> {code}
> <interop iona="on">.
> {code}
> However, the IIOP-OpenJDK cannot parse this setting because it accepts boolean.
> {code}
> <interop iona="true">
> {code}
> Due to this, server cannot parse the configuration and fails to boot.
> The issue is caused by missing transformer for iona. The issue is a regression agains previous releases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9487) Missing transformers for iona in jacorb subsystem (JacORB to IIOP-OpenJDK :migrate operation)
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-9487?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-9487:
--------------------------------------
I've got the fix also for the other issue, will update the MRs in the moment.
> Missing transformers for iona in jacorb subsystem (JacORB to IIOP-OpenJDK :migrate operation)
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-9487
> URL: https://issues.jboss.org/browse/WFLY-9487
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
> Priority: Blocker
>
> Server not staring after succesful migration operation. This issue happens when interoperability IONA on subsystem JacORB is turned on. Tthis functionality was added to IIOP-OpenJDK(see JBEAP-12912) In the latest build(7.1.0.CR3).
> When IONA is turned on, configuration file contains setting
> {code}
> <interop iona="on">
> {code}
> During migration from JacORB to IIOP-OpenJDK using /subsystem=jacorb:migrate this setting is also migrated:
> {code}
> <interop iona="on">.
> {code}
> However, the IIOP-OpenJDK cannot parse this setting because it accepts boolean.
> {code}
> <interop iona="true">
> {code}
> Due to this, server cannot parse the configuration and fails to boot.
> The issue is caused by missing transformer for iona. The issue is a regression agains previous releases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9487) Missing transformers for iona in jacorb subsystem (JacORB to IIOP-OpenJDK :migrate operation)
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-9487?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-9487:
--------------------------------------
Apparently the MR fixes only the case when this is used in expression like $\{iiop-iona:on\} as this was our testing use case.
> Missing transformers for iona in jacorb subsystem (JacORB to IIOP-OpenJDK :migrate operation)
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-9487
> URL: https://issues.jboss.org/browse/WFLY-9487
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
> Priority: Blocker
>
> Server not staring after succesful migration operation. This issue happens when interoperability IONA on subsystem JacORB is turned on. Tthis functionality was added to IIOP-OpenJDK(see JBEAP-12912) In the latest build(7.1.0.CR3).
> When IONA is turned on, configuration file contains setting
> {code}
> <interop iona="on">
> {code}
> During migration from JacORB to IIOP-OpenJDK using /subsystem=jacorb:migrate this setting is also migrated:
> {code}
> <interop iona="on">.
> {code}
> However, the IIOP-OpenJDK cannot parse this setting because it accepts boolean.
> {code}
> <interop iona="true">
> {code}
> Due to this, server cannot parse the configuration and fails to boot.
> The issue is caused by missing transformer for iona. The issue is a regression agains previous releases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9455) WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-9455?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on WFLY-9455:
---------------------------------------
Possible solution is having a WS handler bound before XTS txbridge handler to suspend WFTC transaction before the Narayana one is suspended:
https://github.com/wildfly/wildfly/compare/master...ochaloup:WFLY-9455-su...
> WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions
> -------------------------------------------------------------------------------------
>
> Key: WFLY-9455
> URL: https://issues.jboss.org/browse/WFLY-9455
> Project: WildFly
> Issue Type: Bug
> Components: XTS
> Affects Versions: 11.0.0.CR1
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
>
> It happens to get exception
> {code}
> ERROR [org.jboss.as.txn] (default task-12) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0
> ERROR [org.jboss.as.txn] (default task-12) WFLYTX0001: Unable to roll back active transaction: javax.transaction.SystemException: WFTXN0032: Rollback not allowed on imported transaction
> at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:100)
> at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83)
> at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137)
> at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1510)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 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:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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)
> {code}
> when using XTS transactions bridged to JTA for EJB handling. This happens on change of integration layer for WFTC in WFLY11.
> The integration issues were already discussed as part of the JBTM-2853.
> Here I hit a trouble of having log filled with the exception mentioned above. This does not cause a functionality trouble but the log is ugly filled with ERRORs.
> The trouble seems to be caused by the fact that transaction is imported on ivocation of WS
> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra...
> but as it was suspended in the integration code before
> https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/or...
> now the WFTC holds the notion about the transaction even on call of
> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
> and such transaction is tried to be rollback which is forbidden on WFTC for imported ones and thus at least ERROR msg is written to the log.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JBJCA-1355) set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1355?page=com.atlassian.jira.plugin... ]
Stefano Maestri resolved JBJCA-1355.
------------------------------------
Resolution: Done
> set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second
> ----------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1355
> URL: https://issues.jboss.org/browse/JBJCA-1355
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Reporter: Masafumi Miura
> Assignee: Stefano Maestri
>
> {{set-tx-query-timeout}} setting does not work when the remaining transaction timeout is shorter than one second (between 0-999 millis) due to incorrect round-up in IronJacamar {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}}.
> ---
> {{WrappedConnection#checkConfiguredQueryTimeout()}} checks the returned value from {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} and set the value to query timeout if it's larger than 0. If it's not larger than 0, the configured query timeout ({{query-timeout}} in datasource setting) is used. This behavior itself is ok.
> However, {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} incorrectly rounds up the returned value from transaction manager's {{TransactionTimeoutConfiguration#getTimeLeftBeforeTransactionTimeout()}}. And it results in returning 0 when the remaining transaction timeout is between 0-999 millis. This causes the issue.
> Here's the related code from 1.3.7.Final (It's same in the latest 1.3 branch and 1.4 branch):
> - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a...
> {code}
> 2022 /**
> 2023 * Check configured query timeout
> 2024 * @param ws The statement
> 2025 * @param explicitTimeout An explicit timeout value set
> 2026 * @exception SQLException Thrown if an error occurs
> 2027 */
> 2028 void checkConfiguredQueryTimeout(WrappedStatement ws, int explicitTimeout) throws SQLException
> 2029 {
> 2030 if (mc == null || dataSource == null)
> 2031 return;
> 2032
> 2033 int timeout = 0;
> 2034
> 2035 // Use the transaction timeout
> 2036 if (mc.isTransactionQueryTimeout())
> 2037 {
> 2038 timeout = dataSource.getTimeLeftBeforeTransactionTimeout();
> 2039 if (timeout > 0 && explicitTimeout > 0 && timeout > explicitTimeout)
> 2040 timeout = explicitTimeout;
> 2041 }
> 2042
> 2043 // Look for a configured value
> 2044 if (timeout <= 0 && explicitTimeout <= 0)
> 2045 timeout = mc.getQueryTimeout();
> 2046
> 2047 if (timeout > 0)
> 2048 ws.setQueryTimeout(timeout);
> 2049 }
> {code}
> - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a...
> {code}
> 190 /**
> 191 * Get the time left before a transaction timeout
> 192 * @return The amount in seconds; <code>-1</code> if no timeout
> 193 * @exception SQLException Thrown if an error occurs
> 194 */
> 195 protected int getTimeLeftBeforeTransactionTimeout() throws SQLException
> 196 {
> 197 try
> 198 {
> 199 if (cm instanceof TransactionTimeoutConfiguration)
> 200 {
> 201 long timeout = ((TransactionTimeoutConfiguration) cm).getTimeLeftBeforeTransactionTimeout(true);
> 202 // No timeout
> 203 if (timeout == -1)
> 204 return -1;
> 205 // Round up to the nearest second
> 206 long result = timeout / 1000;
> 207 if ((result % 1000) != 0)
> 208 ++result;
> 209 return (int) result;
> 210 }
> 211 else
> 212 return -1;
> 213 }
> 214 catch (RollbackException e)
> 215 {
> 216 throw new SQLException(e);
> 217 }
> 218 }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JBJCA-1355) set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1355?page=com.atlassian.jira.plugin... ]
Stefano Maestri reassigned JBJCA-1355:
--------------------------------------
Assignee: Stefano Maestri
> set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second
> ----------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1355
> URL: https://issues.jboss.org/browse/JBJCA-1355
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Reporter: Masafumi Miura
> Assignee: Stefano Maestri
>
> {{set-tx-query-timeout}} setting does not work when the remaining transaction timeout is shorter than one second (between 0-999 millis) due to incorrect round-up in IronJacamar {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}}.
> ---
> {{WrappedConnection#checkConfiguredQueryTimeout()}} checks the returned value from {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} and set the value to query timeout if it's larger than 0. If it's not larger than 0, the configured query timeout ({{query-timeout}} in datasource setting) is used. This behavior itself is ok.
> However, {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} incorrectly rounds up the returned value from transaction manager's {{TransactionTimeoutConfiguration#getTimeLeftBeforeTransactionTimeout()}}. And it results in returning 0 when the remaining transaction timeout is between 0-999 millis. This causes the issue.
> Here's the related code from 1.3.7.Final (It's same in the latest 1.3 branch and 1.4 branch):
> - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a...
> {code}
> 2022 /**
> 2023 * Check configured query timeout
> 2024 * @param ws The statement
> 2025 * @param explicitTimeout An explicit timeout value set
> 2026 * @exception SQLException Thrown if an error occurs
> 2027 */
> 2028 void checkConfiguredQueryTimeout(WrappedStatement ws, int explicitTimeout) throws SQLException
> 2029 {
> 2030 if (mc == null || dataSource == null)
> 2031 return;
> 2032
> 2033 int timeout = 0;
> 2034
> 2035 // Use the transaction timeout
> 2036 if (mc.isTransactionQueryTimeout())
> 2037 {
> 2038 timeout = dataSource.getTimeLeftBeforeTransactionTimeout();
> 2039 if (timeout > 0 && explicitTimeout > 0 && timeout > explicitTimeout)
> 2040 timeout = explicitTimeout;
> 2041 }
> 2042
> 2043 // Look for a configured value
> 2044 if (timeout <= 0 && explicitTimeout <= 0)
> 2045 timeout = mc.getQueryTimeout();
> 2046
> 2047 if (timeout > 0)
> 2048 ws.setQueryTimeout(timeout);
> 2049 }
> {code}
> - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a...
> {code}
> 190 /**
> 191 * Get the time left before a transaction timeout
> 192 * @return The amount in seconds; <code>-1</code> if no timeout
> 193 * @exception SQLException Thrown if an error occurs
> 194 */
> 195 protected int getTimeLeftBeforeTransactionTimeout() throws SQLException
> 196 {
> 197 try
> 198 {
> 199 if (cm instanceof TransactionTimeoutConfiguration)
> 200 {
> 201 long timeout = ((TransactionTimeoutConfiguration) cm).getTimeLeftBeforeTransactionTimeout(true);
> 202 // No timeout
> 203 if (timeout == -1)
> 204 return -1;
> 205 // Round up to the nearest second
> 206 long result = timeout / 1000;
> 207 if ((result % 1000) != 0)
> 208 ++result;
> 209 return (int) result;
> 210 }
> 211 else
> 212 return -1;
> 213 }
> 214 catch (RollbackException e)
> 215 {
> 216 throw new SQLException(e);
> 217 }
> 218 }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9487) Missing transformers for iona in jacorb subsystem (JacORB to IIOP-OpenJDK :migrate operation)
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-9487?page=com.atlassian.jira.plugin.... ]
Petr Kremensky moved JBEAP-13625 to WFLY-9487:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9487 (was: JBEAP-13625)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: IIOP
(was: IIOP)
(was: Migration)
Affects Version/s: (was: 7.1.0.CR3)
> Missing transformers for iona in jacorb subsystem (JacORB to IIOP-OpenJDK :migrate operation)
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-9487
> URL: https://issues.jboss.org/browse/WFLY-9487
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
> Priority: Blocker
>
> Server not staring after succesful migration operation. This issue happens when interoperability IONA on subsystem JacORB is turned on. Tthis functionality was added to IIOP-OpenJDK(see JBEAP-12912) In the latest build(7.1.0.CR3).
> When IONA is turned on, configuration file contains setting
> {code}
> <interop iona="on">
> {code}
> During migration from JacORB to IIOP-OpenJDK using /subsystem=jacorb:migrate this setting is also migrated:
> {code}
> <interop iona="on">.
> {code}
> However, the IIOP-OpenJDK cannot parse this setting because it accepts boolean.
> {code}
> <interop iona="true">
> {code}
> Due to this, server cannot parse the configuration and fails to boot.
> The issue is caused by missing transformer for iona. The issue is a regression agains previous releases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1780) JDK 9 kie-internal: javadoc plugin fails with NPE
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1780?page=com.atlassian.jira.plugi... ]
Petr Široký commented on DROOLS-1780:
-------------------------------------
Updstream OpenJDK issue: https://bugs.openjdk.java.net/browse/JDK-8181854.
Based on the comments there, the error is caused by wrong link tag at my javadoc like: {{@link Classname<_E>}}. Fixing the javadoc should be enough.
> JDK 9 kie-internal: javadoc plugin fails with NPE
> -------------------------------------------------
>
> Key: DROOLS-1780
> URL: https://issues.jboss.org/browse/DROOLS-1780
> Project: Drools
> Issue Type: Bug
> Components: build
> Affects Versions: 7.4.1.Final
> Reporter: Petr Široký
> Assignee: Petr Široký
> Labels: java9
>
> Running on latest JDK 9 (9.0.1) + Maven 3.5.2, maven-javadoc-plugin (3.0.0-M1) fails with NPE when generating the javadoc for kie-internal. The plugin is supposed to be compatible with JDK 9. Based on the reported error this could also be a bug in the javadoc tool itself:
> {code}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:javadoc (default-cli) on project kie-internal: An error has occurred in Javadoc report generation:
> [ERROR] Exit code: 1 - javadoc: error - An exception occurred while building a component: MethodsSummary
> [ERROR] (java.lang.NullPointerException)
> [ERROR] Please file a bug against the javadoc tool via the Java bug reporting page
> [ERROR] (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com)
> [ERROR] for duplicates. Include error messages and the following diagnostic in your report. Thank you.
> [ERROR] java.lang.NullPointerException
> [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTrees.attributeDocReference(JavacTrees.java:445)
> [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getElement(JavacTrees.java:405)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.CommentHelper.getElement(CommentHelper.java:178)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.CommentHelper$3.visitReference(CommentHelper.java:459)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.CommentHelper$3.visitReference(CommentHelper.java:433)
> [ERROR] at jdk.compiler/com.sun.tools.javac.tree.DCTree$DCReference.accept(DCTree.java:631)
> [ERROR] at jdk.compiler/com.sun.source.util.SimpleDocTreeVisitor.visit(SimpleDocTreeVisitor.java:79)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.CommentHelper$3.visitLink(CommentHelper.java:444)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.CommentHelper$3.visitLink(CommentHelper.java:433)
> [ERROR] at jdk.compiler/com.sun.tools.javac.tree.DCTree$DCLink.accept(DCTree.java:500)
> [ERROR] at jdk.compiler/com.sun.source.util.SimpleDocTreeVisitor.visit(SimpleDocTreeVisitor.java:79)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.CommentHelper.getReferencedElement(CommentHelper.java:476)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.util.CommentHelper.getReferencedClass(CommentHelper.java:365)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.seeTagToContent(HtmlDocletWriter.java:1510)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter$2.visitLink(HtmlDocletWriter.java:1949)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter$2.visitLink(HtmlDocletWriter.java:1797)
> [ERROR] at jdk.compiler/com.sun.tools.javac.tree.DCTree$DCLink.accept(DCTree.java:500)
> [ERROR] at jdk.compiler/com.sun.source.util.SimpleDocTreeVisitor.visit(SimpleDocTreeVisitor.java:79)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.commentTagsToContent(HtmlDocletWriter.java:2017)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.addCommentTags(HtmlDocletWriter.java:1719)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.addCommentTags(HtmlDocletWriter.java:1700)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDocletWriter.addSummaryComment(HtmlDocletWriter.java:1670)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.SubWriterHolderWriter.addIndexComment(SubWriterHolderWriter.java:207)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.SubWriterHolderWriter.addSummaryLinkComment(SubWriterHolderWriter.java:243)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.AbstractMemberWriter.addMemberSummary(AbstractMemberWriter.java:533)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.MemberSummaryBuilder.buildSummary(MemberSummaryBuilder.java:359)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.MemberSummaryBuilder.addSummary(MemberSummaryBuilder.java:515)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.MemberSummaryBuilder.buildMethodsSummary(MemberSummaryBuilder.java:309)
> [ERROR] at jdk.internal.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
> [ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:157)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:87)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.AbstractBuilder.buildChildren(AbstractBuilder.java:200)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.buildMemberSummary(ClassBuilder.java:333)
> [ERROR] at jdk.internal.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> [ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:157)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.AbstractBuilder.buildChildren(AbstractBuilder.java:200)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:155)
> [ERROR] at jdk.internal.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> [ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:157)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.builders.ClassBuilder.build(ClassBuilder.java:125)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:263)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:273)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:207)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.doclets.toolkit.AbstractDoclet.run(AbstractDoclet.java:117)
> [ERROR] at jdk.javadoc/jdk.javadoc.doclet.StandardDoclet.run(StandardDoclet.java:72)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:574)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:423)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:340)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63)
> [ERROR] at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52)
> [ERROR]
> [ERROR] Command line was: /opt/tools/jdk9/bin/javadoc -J-Xmx512m -J-Xms128m @options @packages
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months