[JBoss JIRA] (WFCORE-561) Class loading problem with XAResource and XADataSource
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-561?page=com.atlassian.jira.plugin... ]
David Lloyd updated WFCORE-561:
-------------------------------
Description:
We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}} and strange CCEs under certain circumstances.
The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
One solution is to ensure that the {{jdk.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{jdk.api}} module.
was:
We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}}s and strange CCEs under certain circumstances.
The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
One solution is to ensure that the {{jdk.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{jdk.api}} module.
> Class loading problem with XAResource and XADataSource
> ------------------------------------------------------
>
> Key: WFCORE-561
> URL: https://issues.jboss.org/browse/WFCORE-561
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha19
>
>
> We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}} and strange CCEs under certain circumstances.
> The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
> One solution is to ensure that the {{jdk.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{jdk.api}} module.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (SECURITY-746) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by Arjan t (JIRA)
[ https://issues.jboss.org/browse/SECURITY-746?page=com.atlassian.jira.plug... ]
Arjan t commented on SECURITY-746:
----------------------------------
p.s.
There's a test for this case in the Java EE 7 samples project, which is indeed failing for WildFly 8.2. See here: https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/ejb-...
> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
> Key: SECURITY-746
> URL: https://issues.jboss.org/browse/SECURITY-746
> Project: PicketBox
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
>
> After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
> The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
> This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
> However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
> The problematic part in {{SimpleSecurityManager}}:
> {code}
> public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
> boolean contextPushed = false;
> boolean securityContextEstablished = false;
> final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
> try {
> contexts.push(previous);
> contextPushed = true;
> SecurityContext current = establishSecurityContext(securityDomain);
> securityContextEstablished = true;
> if (previous != null) {
> current.setSubjectInfo(previous.getSubjectInfo());
> current.setIncomingRunAs(previous.getOutgoingRunAs());
> }
> RunAs currentRunAs = current.getIncomingRunAs();
> boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
> if (trusted == false) {
>
> boolean authenticated = false;
> if (SecurityActions.remotingContextIsSet()) {
> // ...
> }
> // If we have a trusted identity no need for a re-auth.
> if (authenticated == false) {
> // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
> authenticated = authenticate(current, null);
> }
> {code}
> The (condensed) stack that will lead to an exception is the following:
> {noformat}
> javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
> {noformat}
> Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (SECURITY-746) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by Arjan t (JIRA)
[ https://issues.jboss.org/browse/SECURITY-746?page=com.atlassian.jira.plug... ]
Arjan t commented on SECURITY-746:
----------------------------------
This is still a problem in WildFly 8.2, even though that one has some alignment with the security domain of the web module (see WFLY-3102).
The code in Picketbox has changed a bit from the report, but still after JASPIC has successfully authenticated in the web tier and then calls a method on a protected EJB, {{org.jboss.as.ejb3.security.SecurityContextInterceptor}} still tries to authenticate with {{org.jboss.as.security.service.SimpleSecurityManager}}.
This now happens here:
{code:java}
public class SecurityContextInterceptor implements Interceptor {
private final PrivilegedAction<Void> pushAction;
private final PrivilegedAction<Void> popAction;
public SecurityContextInterceptor(final SecurityContextInterceptorHolder holder) {
this.pushAction = new PrivilegedAction<Void>() {
@Override
public Void run() {
holder.securityManager.push(holder.securityDomain);
try {
if (holder.skipAuthentication == false) {
holder.securityManager.authenticate(holder.runAs, holder.runAsPrincipal, holder.extraRoles);
}
if (holder.principalVsRolesMap != null) {
SecurityRolesAssociation.setSecurityRoles(holder.principalVsRolesMap);
}
} catch (Throwable t) {
{code}
{{holder.securityManager.authenticate}} will be called. This now contains the following code:
{code:java}
private boolean authenticate(SecurityContext context, Subject subject) {
SecurityContextUtil util = context.getUtil();
SubjectInfo subjectInfo = getSubjectInfo(context);
if (subject == null) {
subject = new Subject();
}
Principal principal = util.getUserPrincipal();
Principal auditPrincipal = principal;
Object credential = util.getCredential();
Identity unauthenticatedIdentity = null;
boolean authenticated = false;
if (principal == null) {
unauthenticatedIdentity = getUnauthenticatedIdentity();
subjectInfo.addIdentity(unauthenticatedIdentity);
auditPrincipal = unauthenticatedIdentity.asPrincipal();
subject.getPrincipals().add(auditPrincipal);
authenticated = true;
} else {
subject.getPrincipals().add(principal);
}
if (authenticated == false) {
AuthenticationManager authenticationManager = context.getAuthenticationManager();
authenticated = authenticationManager.isValid(principal, credential, subject);
}
{code}
The 2nd line {{SubjectInfo subjectInfo = getSubjectInfo(context);}} will retrieve the authenticated identity as established by the JASPIC auth module, but instead of using it, it will call {{authenticationManager.isValid(principal, credential, subject);}}, which will call through to a JAAS login module.
This will now cause the following exception:
{noformat}
javax.ejb.EJBAccessException: JBAS013323: Invalid User
at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:66) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:46) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:92) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
{noformat}
> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
> Key: SECURITY-746
> URL: https://issues.jboss.org/browse/SECURITY-746
> Project: PicketBox
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
>
> After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
> The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
> This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
> However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
> The problematic part in {{SimpleSecurityManager}}:
> {code}
> public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
> boolean contextPushed = false;
> boolean securityContextEstablished = false;
> final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
> try {
> contexts.push(previous);
> contextPushed = true;
> SecurityContext current = establishSecurityContext(securityDomain);
> securityContextEstablished = true;
> if (previous != null) {
> current.setSubjectInfo(previous.getSubjectInfo());
> current.setIncomingRunAs(previous.getOutgoingRunAs());
> }
> RunAs currentRunAs = current.getIncomingRunAs();
> boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
> if (trusted == false) {
>
> boolean authenticated = false;
> if (SecurityActions.remotingContextIsSet()) {
> // ...
> }
> // If we have a trusted identity no need for a re-auth.
> if (authenticated == false) {
> // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
> authenticated = authenticate(current, null);
> }
> {code}
> The (condensed) stack that will lead to an exception is the following:
> {noformat}
> javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
> {noformat}
> Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (WFLY-4380) Remove usage of jboss-common-core in web services
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-4380:
---------------------------------
Summary: Remove usage of jboss-common-core in web services
Key: WFLY-4380
URL: https://issues.jboss.org/browse/WFLY-4380
Project: WildFly
Issue Type: Sub-task
Components: Web Services
Reporter: Tomaz Cerar
Assignee: Alessio Soldano
Fix For: 9.0.0.CR1
We are getting rid of this ultra old dependency.
Web services uses it in jbossws-common and jbossws-cxf-server
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (WFLY-4362) Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4362?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4362:
-----------------------------------
Send PR that also fixes SMAP (jsp debugging) generation when using java8 sources https://github.com/undertow-io/jastow/pull/16
> Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4362
> URL: https://issues.jboss.org/browse/WFLY-4362
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Alpha1
> Environment: jdk1.8
> Reporter: Radim Hatlapatka
> Assignee: Tomaz Cerar
> Priority: Critical
> Attachments: lambda-expression-test.war
>
>
> Accessing JSP with JDK8 specific code (namely lambda expressions) fails due compilation error [1].
> It didn't help setting
> {code}
> <jsp-config source-vm="1.8" target-vm="1.8"/> in <servlet-container name="default">
> {code}
> It is caused due ecj-4.3.1.jar supports only JDKs till 1.7.
> [1]
> {noformat}
> 09:58:44,480 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /lambda-expression-test/jsp-with-lambdas.jsp: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> Syntax error on token "-", -- expected
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> Syntax error on token "-", -- expected
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004211: Stacktrace:
> at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:451) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (WFLY-4363) Class (own class) not found Exception during trial of getting of StepExecutions with own classes in PersistentUserData
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4363?page=com.atlassian.jira.plugin.... ]
Cheng Fang commented on WFLY-4363:
----------------------------------
You will need a more recent WildFly installation for the drop-in replacement to work. The use of wildfly-security-mananger was introduced on 7/28/2014:
https://github.com/wildfly/wildfly/pull/6537/files
> Class (own class) not found Exception during trial of getting of StepExecutions with own classes in PersistentUserData
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4363
> URL: https://issues.jboss.org/browse/WFLY-4363
> Project: WildFly
> Issue Type: Bug
> Components: Batch, EJB
> Affects Versions: 8.2.0.Final
> Environment: JRE 7, Maven build
> Reporter: Serg Jackbean
> Assignee: Cheng Fang
>
> Exception Class (own class that is saved as Serialisable in PersistentUserData) not Found (in JBeret?) disappears in some in some minutes after some calls of EJB with Batch Jobs according some sequence after new start of server.
> (there was exception -class not found for own class for checkpointInfo also)
> Log:
> 09:55:22,252 ERROR [org.jboss.as.ejb3.invocation] (default task-3) JBAS014134: EJB Invocation failed on component BatchRuntimeService for method public test.Job test.BatchRuntimeService.getJobStepExecutions(java.lang.String,int) throws test.ServiceException: javax.ejb.EJBException: javax.batch.operations.BatchRuntimeException: JBERET000626: Failed to run SELECT * FROM STEP_EXECUTION WHERE JOBEXECUTIONID=? ORDER BY STEPEXECUTIONID
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at test.BatchRuntimeService$$$view4.getJobStepExecutions(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at test.BatchRuntimeService$Proxy$_$$_Weld$EnterpriseProxy$.getJobStepExecutions(Unknown Source) [classes:]
> at test.web.rest.JobTimerResource.listJobExecutions(JobTimerResource.java:122) [classes:]
> at test.web.rest.JobTimerResource$Proxy$_$$_WeldClientProxy.listJobExecutions(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.10.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: javax.batch.operations.BatchRuntimeException: JBERET000626: Failed to run SELECT * FROM STEP_EXECUTION WHERE JOBEXECUTIONID=? ORDER BY STEPEXECUTIONID
> at org.jberet.repository.JdbcRepository.selectStepExecutions(JdbcRepository.java:651) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.getStepExecutions(JdbcRepository.java:256) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.getStepExecutions(JobOperatorImpl.java:263) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at test.BatchRuntimeService.getJobStepExecutions(BatchRuntimeService.java:153) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> ... 85 more
> Caused by: java.lang.ClassNotFoundException: test.JobBatchResult from [Module "org.jberet.jberet-core:main" from local module loader @675dd521 (finder: local module finder @41539e8b (roots: C:\server\wildfly-8.2.0.Final\modules,C:\server\wildfly-8.2.0.Final\modules\system\layers\base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_45]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:625) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_45]
> at org.jberet.util.BatchUtil.bytesToSerializableObject(BatchUtil.java:111) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.createStepExecutionsFromResultSet(JdbcRepository.java:746) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.selectStepExecutions(JdbcRepository.java:649) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> ... 123 more
> 09:55:22,265 ERROR [test.web.rest.ExceptionHttpStatusResolver] (default task-3) javax.batch.operations.BatchRuntimeException: JBERET000626: Failed to run SELECT * FROM STEP_EXECUTION WHERE JOBEXECUTIONID=? ORDER BY STEPEXECUTIONID
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (WFLY-4362) Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4362?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-4362:
------------------------------
Git Pull Request: https://github.com/undertow-io/jastow/pull/16 (was: https://github.com/undertow-io/jastow/pull/15)
> Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4362
> URL: https://issues.jboss.org/browse/WFLY-4362
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Alpha1
> Environment: jdk1.8
> Reporter: Radim Hatlapatka
> Assignee: Tomaz Cerar
> Priority: Critical
> Attachments: lambda-expression-test.war
>
>
> Accessing JSP with JDK8 specific code (namely lambda expressions) fails due compilation error [1].
> It didn't help setting
> {code}
> <jsp-config source-vm="1.8" target-vm="1.8"/> in <servlet-container name="default">
> {code}
> It is caused due ecj-4.3.1.jar supports only JDKs till 1.7.
> [1]
> {noformat}
> 09:58:44,480 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /lambda-expression-test/jsp-with-lambdas.jsp: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> Syntax error on token "-", -- expected
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 7: // System.out.println(answerToEverything);
> 8:
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> Syntax error on token "-", -- expected
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp
> n cannot be resolved to a variable
> 9: List<Integer> list = Arrays.asList(1, 2, 3);
> 10: Arrays.asList(1).forEach(n-> System.out.println(n));
> 11:
> 12: list.forEach(n -> response.getWriter().write("<p>" + n + "</p>"));
> 13:
> 14: %>
> 15: </body>
> JBWEB004211: Stacktrace:
> at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:451) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (WFLY-3991) JDK 1.8 javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3991?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3991:
-----------------------------------
David, last time I checked this, it does ignore failed ones, but still report them.
So loading scriptengine still work but you end up with ugly error message in log
> JDK 1.8 javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3991
> URL: https://issues.jboss.org/browse/WFLY-3991
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Manuel Blechschmidt
> Assignee: Jason Greene
> Labels: JS223, JavaScript, Scripting
>
> When using the ScriptManager in a JSF bean the following happens:
> ERROR [stderr] (default task-21) ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> {code}
> package de.example.log.jsf;
> import java.io.ByteArrayOutputStream;
> import java.io.IOException;
> import java.io.PrintStream;
> import javax.enterprise.inject.Model;
> import javax.faces.application.FacesMessage;
> import javax.faces.context.FacesContext;
> import javax.inject.Inject;
> import javax.script.Bindings;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.ScriptException;
> @Model
> public class Scripting {
> private String script;
> private String output;
> private ScriptEngineManager mgr = new ScriptEngineManager();
> public static String utilJavaScript = "var print = function (s) { __newOut.print(s); }; var println = function (s) { __newOut.println(s); };";
> public String execute() {
> ScriptEngine jsEngine = mgr.getEngineByName("JavaScript");
> ByteArrayOutputStream outputBuffer = new ByteArrayOutputStream(8192);
> PrintStream newOut = new PrintStream(outputBuffer, true);
> Bindings bindings = jsEngine.createBindings();
> bindings.put("__newOut", newOut);
> try {
> jsEngine.eval(utilJavaScript + getScript(), bindings);
> } catch (ScriptException from) {
> FacesContext.getCurrentInstance().addMessage(
> null,
> new FacesMessage(from.getColumnNumber() + " "
> + from.getFileName() + " " + from.getLineNumber()
> + " " + from.getMessage()));
> return null;
> }
> newOut.close();
> String returnString = outputBuffer.toString();
> setOutput(returnString);
> try {
> outputBuffer.close();
> } catch (IOException e) {
> FacesContext.getCurrentInstance().addMessage(
> null,
> new FacesMessage(e.getLocalizedMessage()));
> }
> return null;
> }
> public String getScript() {
> return script;
> }
> public void setScript(String script) {
> this.script = script;
> }
> public String getOutput() {
> return output;
> }
> public void setOutput(String output) {
> this.output = output;
> }
> }
> {code}
> The script engines are configured in the following file:
> WILDFLY_HOME/modules/system/layers/base/sun/jdk/main/service-loader-resources/META-INF/services/javax.script.ScriptEngineFactory
> {code}
> com.sun.script.javascript.RhinoScriptEngineFactory
> jdk.nashorn.api.scripting.NashornScriptEngineFactory
> {code}
> It should be made sure that with every JDK JSR 223 compliant requests for a JavaScript engine will work out of the box.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (WFLY-4014) TransactionReaper wedged and not responding to interrupts (ARJUNA012378, ARJUNA012120)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-4014?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed WFLY-4014.
-------------------------------
Resolution: Partially Completed
The ability for an app to provide its own CheckedAction was implemented in https://issues.jboss.org/browse/JBTM-2279 which is in WFLY now. I don't think the default behaviour should be to interrupt the drivers as per the discussion on the forum post. Its an option for a savvy user to implement their own CheckedAction to do the interrupt but they will do it with knowledge of how their set of drivers respond to Thread.interrup() - if you need help how to implement a CheckedAction to interrupt threads please do ask over on: https://community.jboss.org/en/jbosstm
> TransactionReaper wedged and not responding to interrupts (ARJUNA012378, ARJUNA012120)
> --------------------------------------------------------------------------------------
>
> Key: WFLY-4014
> URL: https://issues.jboss.org/browse/WFLY-4014
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.1.0.Final
> Environment: Darwin Keith-Yarbroughs-MBPro.local 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
> Reporter: Arcadiy Ivanov
> Assignee: Tom Jenkinson
> Attachments: cluster_logs.2014-10-23T23-37-03.tar.gz, cluster_logs.2014-10-24T16-50-50.tar.gz, stuck-shutdown-wedged-reaper-logs.tar.gz
>
>
> This issue is definitely intermittent and appeared first time ever in several months. It is severe enough, however (server node becomes unresponsive and can only be killed with SIGKILL) that I'm reporting it.
> Issue occurred while running an Arquillian test. I don't know how to reproduce it.
> The system is as follows:
> * There is a multi-host multi-node WildFly domain cluster residing on a single machine (127.0.0.(1+N) IPs, N > 0).
> * There is a multi-node Postgres-XL cluster configured (127.0.1.(1+N) IPs, N > 0) configured.
> * There is a HAJDBC module configured. HAJDBC cluster is configured with datasources from WildFly datasources subsystem which has a datasource for each node of Postgres-XL cluster.
> There is [another mention on the Inet of the same problem|https://developer.jboss.org/thread/240172] without such an exotic setup, but rather with simply a MySQL 5.6, although information is scarce.
> {noformat}
> 2014-10-23 23:19:47,127 INFO [org.wildfly.extension.undertow] (MSC service thread 1-16) JBAS017534: Registered web context: /test
> 2014-10-23 23:19:47,154 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) JBAS018559: Deployed "1208cb8c-2b19-4d9a-a8b9-101f6e9e778f.ear" (runtime-name : "1208cb8c-2b19-4d9a-a8b9-101f6e9e778f.ear")
> 2014-10-23 23:24:47,417 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f in state RUN
> 2014-10-23 23:24:47,420 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffffc0a801f4:-475d22cc:5449ccbe:2f invoked while multiple threads active within it.
> 2014-10-23 23:24:47,420 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffffc0a801f4:-475d22cc:5449ccbe:2f aborting with 1 threads active!
> 2014-10-23 23:24:47,918 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f in state CANCEL
> 2014-10-23 23:24:47,920 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012378: ReaperElement appears to be wedged: sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:229)
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.lock(BaseWrapperManagedConnection.java:373)
> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.rollback(LocalManagedConnection.java:113)
> org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.rollback(LocalXAResourceImpl.java:242)
> com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.rollback(XAOnePhaseResource.java:196)
> com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelAbort(LastResourceRecord.java:126)
> com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2939)
> com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2918)
> com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1632)
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:116)
> com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:215)
> com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:377)
> com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:78)
> 2014-10-23 23:24:48,421 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f in state CANCEL_INTERRUPTED
> 2014-10-23 23:24:48,422 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012120: TransactionReaper::check worker Thread[Transaction Reaper Worker 0,5,main] not responding to interrupt when cancelling TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f -- worker marked as zombie and TX scheduled for mark-as-rollback
> 2014-10-23 23:24:48,422 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012110: TransactionReaper::check successfuly marked TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f as rollback only
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months