[JBoss JIRA] (WFLY-4485) Don't Expose JDT Compiler to Web Applications
by Philippe Marschall (JIRA)
Philippe Marschall created WFLY-4485:
----------------------------------------
Summary: Don't Expose JDT Compiler to Web Applications
Key: WFLY-4485
URL: https://issues.jboss.org/browse/WFLY-4485
Project: WildFly
Issue Type: Enhancement
Components: Web (Undertow)
Affects Versions: 9.0.0.Beta2
Reporter: Philippe Marschall
Assignee: Stuart Douglas
Currently the Eclipse JDT compiler is exposed to web applications because the undertow servlet module exposes all its dependencies.
This can break applications that ship their own version of the Eclipse JDT compiler like the Cocoon web framework.
This seems to be a regression. It was already fixed once in WFLY-1770 but seems to be an issue again since undertow JSP is now once again one instead of two modules.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (JASSIST-245) Javassist 3.19.0-GA causes compilation warnings with -Xlint:classfile
by David Carr (JIRA)
[ https://issues.jboss.org/browse/JASSIST-245?page=com.atlassian.jira.plugi... ]
David Carr updated JASSIST-245:
-------------------------------
Steps to Reproduce:
To reproduce, put the javassist JAR and DescribingHandlers.java (https://gist.github.com/davidmc24/17e120b67ce35831a07a) in a directory and run the following command:
{code}javac -Werror -Xlint:classfile -classpath javassist-3.19.0-GA.jar DescribingHandlers.java{code}
You should get something like the following output:
{code}
javassist-3.19.0-GA.jar(javassist/ClassPool.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/CtBehavior.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/CtClass.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/NotFoundException.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/bytecode/ClassFile.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
error: warnings found and -Werror specified
javassist-3.19.0-GA.jar(javassist/CtMember.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/bytecode/MethodInfo.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
1 error
7 warnings
{code}
was:
To reproduce, put the javassist JAR the attached DescribingHandlers.java file in a directory and run the following command:
{code}javac -Werror -Xlint:classfile -classpath javassist-3.19.0-GA.jar DescribingHandlers.java{code}
You should get something like the following output:
{code}
javassist-3.19.0-GA.jar(javassist/ClassPool.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/CtBehavior.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/CtClass.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/NotFoundException.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/bytecode/ClassFile.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
error: warnings found and -Werror specified
javassist-3.19.0-GA.jar(javassist/CtMember.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
javassist-3.19.0-GA.jar(javassist/bytecode/MethodInfo.class): warning: [classfile] MethodParameters attribute introduced in version 52.0 class files is ignored in version 50.0 class files
1 error
7 warnings
{code}
> Javassist 3.19.0-GA causes compilation warnings with -Xlint:classfile
> ---------------------------------------------------------------------
>
> Key: JASSIST-245
> URL: https://issues.jboss.org/browse/JASSIST-245
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.19.0-GA
> Reporter: David Carr
> Assignee: Shigeru Chiba
>
> Tested using Oracle Java 1.8.0_40.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4478) Server won't shutdown until batch threads are done executing
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4478?page=com.atlassian.jira.plugin.... ]
Cheng Fang commented on WFLY-4478:
----------------------------------
Calling JobOperator.stop(jobExecutionId) should be able to stop the running job execution, though it's a request to stop. JBeret calls the batchlet's stop() method to stop the batchlet, and a properly implemented batchlet should stop there; or stops the chunk stop execution as soon as the current chunk ends.
> Server won't shutdown until batch threads are done executing
> ------------------------------------------------------------
>
> Key: WFLY-4478
> URL: https://issues.jboss.org/browse/WFLY-4478
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: James Perkins
> Assignee: James Perkins
>
> When the server is shutdown, even with {{SIGINT}}, the batch jobs keep running and the JVM will not exit until the batch jobs are complete. Ideally threads spawned from the {{BatchEnvironment}} will be daemon threads. At the least the thread should be interrupted.
> Another option would be for JBeret to have a way to stop all running jobs.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4334) CalendarBasedTimeoutTestCase fails consistently
by Peter Major (JIRA)
[ https://issues.jboss.org/browse/WFLY-4334?page=com.atlassian.jira.plugin.... ]
Peter Major edited comment on WFLY-4334 at 4/3/15 8:55 PM:
-----------------------------------------------------------
The test fails for Africa/Cairo timezone, and according to the [timezone informations|http://www.timeanddate.com/time/zone/egypt/cairo] it looks like there was no 0 o'clock on 2014 August 1st in Egypt... One way to more easily trigger this test failure would be to change "start" in testWithStartInThePast to
{noformat}
start.set(2014, 6, 18);
{noformat}
Since I was unable to reproduce the same build failure with master, I've looked at the code history, which showed that WFLY-3947 has removed this faulty test case. Backporting WFLY-3947 to 8.x resolved the build failures for me.
was (Author: aldaris):
The test fails for Africa/Cairo timezone, and according to the [http://www.timeanddate.com/time/zone/egypt/cairo|timezone informations] it looks like there was no 0 o'clock on 2014 August 1st in Egypt... One way to more easily trigger this test failure would be to change "start" in testWithStartInThePast to
{noformat}
start.set(2014, 6, 18);
{noformat}
Since I was unable to reproduce the same build failure with master, I've looked at the code history, which showed that WFLY-3947 has removed this faulty test case. Backporting WFLY-3947 to 8.x resolved the build failures for me.
> CalendarBasedTimeoutTestCase fails consistently
> -----------------------------------------------
>
> Key: WFLY-4334
> URL: https://issues.jboss.org/browse/WFLY-4334
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Thomas Diesler
> Assignee: David Lloyd
>
> Happens on branch 8.x
> {code}
> Running org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.352 sec <<< FAILURE! - in org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> testCalendarBasedTimeout(org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase) Time elapsed: 0.342 sec <<< FAILURE!
> java.lang.AssertionError: Eastern European Time
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testWithStartInThePast(CalendarBasedTimeoutTestCase.java:539)
> at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testCalendarBasedTimeout(CalendarBasedTimeoutTestCase.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4334) CalendarBasedTimeoutTestCase fails consistently
by Peter Major (JIRA)
[ https://issues.jboss.org/browse/WFLY-4334?page=com.atlassian.jira.plugin.... ]
Peter Major commented on WFLY-4334:
-----------------------------------
The test fails for Africa/Cairo timezone, and according to the [http://www.timeanddate.com/time/zone/egypt/cairo|timezone informations] it looks like there was no 0 o'clock on 2014 August 1st in Egypt... One way to more easily trigger this test failure would be to change "start" in testWithStartInThePast to
{noformat}
start.set(2014, 6, 18);
{noformat}
Since I was unable to reproduce the same build failure with master, I've looked at the code history, which showed that WFLY-3947 has removed this faulty test case. Backporting WFLY-3947 to 8.x resolved the build failures for me.
> CalendarBasedTimeoutTestCase fails consistently
> -----------------------------------------------
>
> Key: WFLY-4334
> URL: https://issues.jboss.org/browse/WFLY-4334
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Thomas Diesler
> Assignee: David Lloyd
>
> Happens on branch 8.x
> {code}
> Running org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.352 sec <<< FAILURE! - in org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> testCalendarBasedTimeout(org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase) Time elapsed: 0.342 sec <<< FAILURE!
> java.lang.AssertionError: Eastern European Time
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testWithStartInThePast(CalendarBasedTimeoutTestCase.java:539)
> at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testCalendarBasedTimeout(CalendarBasedTimeoutTestCase.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-625) Error message in CLI if extension existing on the server is not present in the CLI instalaltion
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-625?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-625:
------------------------------------------
This comes from ExtensionsLoader where the CLI is trying to load CommandHandlers from extension.
I'm wondering if marking this as an error is correct. Maybe a warning should be sufficient.
> Error message in CLI if extension existing on the server is not present in the CLI instalaltion
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-625
> URL: https://issues.jboss.org/browse/WFCORE-625
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: ehsavoie Hugonnet
> Assignee: Alexey Loubyansky
>
> When using the jboss-cli from a WildFly-Core installation to manage a WildFly Full server you get error messages about missing extensions :
> Errors caught while loading extensions:
> 1) Failed to load module org.jboss.as.clustering.infinispan for extension org.jboss.as.clustering.infinispan: org.jboss.as.clustering.infinispan:main
> 2) Failed to load module org.jboss.as.connector for extension org.jboss.as.connector: org.jboss.as.connector:main
> 3) Failed to load module org.jboss.as.ee for extension org.jboss.as.ee: org.jboss.as.ee:main
> 4) Failed to load module org.jboss.as.ejb3 for extension org.jboss.as.ejb3: org.jboss.as.ejb3:main
> 5) Failed to load module org.jboss.as.jaxrs for extension org.jboss.as.jaxrs: org.jboss.as.jaxrs:main
> 6) Failed to load module org.jboss.as.jdr for extension org.jboss.as.jdr: org.jboss.as.jdr:main
> 7) Failed to load module org.jboss.as.jpa for extension org.jboss.as.jpa: org.jboss.as.jpa:main
> 8) Failed to load module org.jboss.as.jsf for extension org.jboss.as.jsf: org.jboss.as.jsf:main
> 9) Failed to load module org.jboss.as.mail for extension org.jboss.as.mail: org.jboss.as.mail:main
> 10) Failed to load module org.jboss.as.naming for extension org.jboss.as.naming: org.jboss.as.naming:main
> 11) Failed to load module org.jboss.as.pojo for extension org.jboss.as.pojo: org.jboss.as.pojo:main
> 12) Failed to load module org.jboss.as.sar for extension org.jboss.as.sar: org.jboss.as.sar:main
> 13) Failed to load module org.jboss.as.security for extension org.jboss.as.security: org.jboss.as.security:main
> 14) Failed to load module org.jboss.as.transactions for extension org.jboss.as.transactions: org.jboss.as.transactions:main
> 15) Failed to load module org.jboss.as.webservices for extension org.jboss.as.webservices: org.jboss.as.webservices:main
> 16) Failed to load module org.jboss.as.weld for extension org.jboss.as.weld: org.jboss.as.weld:main
> 17) Failed to load module org.wildfly.extension.batch for extension org.wildfly.extension.batch: org.wildfly.extension.batch:main
> 18) Failed to load module org.wildfly.extension.bean-validation for extension org.wildfly.extension.bean-validation: org.wildfly.extension.bean-validation:main
> 19) Failed to load module org.wildfly.extension.security.manager for extension org.wildfly.extension.security.manager: org.wildfly.extension.security.manager:main
> 20) Failed to load module org.wildfly.extension.undertow for extension org.wildfly.extension.undertow: org.wildfly.extension.undertow:main
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-625) Error message in CLI if extension existing on the server is not present in the CLI instalaltion
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-625:
----------------------------------------
Summary: Error message in CLI if extension existing on the server is not present in the CLI instalaltion
Key: WFCORE-625
URL: https://issues.jboss.org/browse/WFCORE-625
Project: WildFly Core
Issue Type: Bug
Components: CLI, Domain Management
Affects Versions: 1.0.0.Beta2
Reporter: ehsavoie Hugonnet
Assignee: Alexey Loubyansky
When using the jboss-cli from a WildFly-Core installation to manage a WildFly Full server you get error messages about missing extensions :
Errors caught while loading extensions:
1) Failed to load module org.jboss.as.clustering.infinispan for extension org.jboss.as.clustering.infinispan: org.jboss.as.clustering.infinispan:main
2) Failed to load module org.jboss.as.connector for extension org.jboss.as.connector: org.jboss.as.connector:main
3) Failed to load module org.jboss.as.ee for extension org.jboss.as.ee: org.jboss.as.ee:main
4) Failed to load module org.jboss.as.ejb3 for extension org.jboss.as.ejb3: org.jboss.as.ejb3:main
5) Failed to load module org.jboss.as.jaxrs for extension org.jboss.as.jaxrs: org.jboss.as.jaxrs:main
6) Failed to load module org.jboss.as.jdr for extension org.jboss.as.jdr: org.jboss.as.jdr:main
7) Failed to load module org.jboss.as.jpa for extension org.jboss.as.jpa: org.jboss.as.jpa:main
8) Failed to load module org.jboss.as.jsf for extension org.jboss.as.jsf: org.jboss.as.jsf:main
9) Failed to load module org.jboss.as.mail for extension org.jboss.as.mail: org.jboss.as.mail:main
10) Failed to load module org.jboss.as.naming for extension org.jboss.as.naming: org.jboss.as.naming:main
11) Failed to load module org.jboss.as.pojo for extension org.jboss.as.pojo: org.jboss.as.pojo:main
12) Failed to load module org.jboss.as.sar for extension org.jboss.as.sar: org.jboss.as.sar:main
13) Failed to load module org.jboss.as.security for extension org.jboss.as.security: org.jboss.as.security:main
14) Failed to load module org.jboss.as.transactions for extension org.jboss.as.transactions: org.jboss.as.transactions:main
15) Failed to load module org.jboss.as.webservices for extension org.jboss.as.webservices: org.jboss.as.webservices:main
16) Failed to load module org.jboss.as.weld for extension org.jboss.as.weld: org.jboss.as.weld:main
17) Failed to load module org.wildfly.extension.batch for extension org.wildfly.extension.batch: org.wildfly.extension.batch:main
18) Failed to load module org.wildfly.extension.bean-validation for extension org.wildfly.extension.bean-validation: org.wildfly.extension.bean-validation:main
19) Failed to load module org.wildfly.extension.security.manager for extension org.wildfly.extension.security.manager: org.wildfly.extension.security.manager:main
20) Failed to load module org.wildfly.extension.undertow for extension org.wildfly.extension.undertow: org.wildfly.extension.undertow:main
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-624) Result transformation for composite op failures is broken
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-624:
---------------------------------------
Summary: Result transformation for composite op failures is broken
Key: WFCORE-624
URL: https://issues.jboss.org/browse/WFCORE-624
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Beta2
Reporter: Brian Stansberry
CompositeOperationTransformer.CompositeResultTransformer works by analyzing the "step-x" entries in the remote response's "result" node, and then transforming that node.
This breaks down when the failure actually occurs in the remote CompositeOperationHandler, as will be the case if the step refers to a resource or operation that is undefined on that node. In that case there is no "result" node with steps, just a top level failure.
CompositeResultTransformer will actually add a "result" node with the expected error message in this case, but that basically works by luck. And the high level error message for the overall op will no be transformed.
Possible improvements:
1) CompositeOperationHandler sets up a result node in this case, so CompositeResultTransformer can process it.
2) CompositeResultTransformer can try and fix up the top level error message as well.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-623) ModelControllerClient.Factory lacks some variants
by Ladislav Thon (JIRA)
Ladislav Thon created WFCORE-623:
------------------------------------
Summary: ModelControllerClient.Factory lacks some variants
Key: WFCORE-623
URL: https://issues.jboss.org/browse/WFCORE-623
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Beta2
Reporter: Ladislav Thon
Assignee: Ladislav Thon
In the {{ModelControllerClient.Factory}} class, each factory method in fact has two varians: with a {{protocol}} as a first parameter, and without it. There are two exceptions -- two methods are lacking a {{protocol}}-less variant:
- {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions)}}
- {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions, final String clientBindAddress)}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months