[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-7210:
-----------------------------------------------
Attachment: after-wfly7024.png
> Expose JAX-RS resources as children of the subsystem
> ----------------------------------------------------
>
> Key: WFLY-7210
> URL: https://issues.jboss.org/browse/WFLY-7210
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Lin Gao
> Attachments: after-wfly7024.png, hal-jaxrs.png
>
>
> Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean)
> This makes it specially easy to navigate trough the web console (attached screenshot).
> To read JAX-RS resources, the command would be:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources()
> I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7568) Sporadic UT000010: Session is invalid
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-7568:
--------------------------------------------------
Summary: Sporadic UT000010: Session is invalid
Key: WFLY-7568
URL: https://issues.jboss.org/browse/WFLY-7568
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Environment: WildFly 10.1 (patched from 10.0) in domain mode. One single node behing a ModCluster balancer running on another server group of the same WildFly domain.
SO: RedHat Linux
Reporter: Guillermo González de Agüero
Assignee: Stuart Douglas
I'm occasionally getting stacktraces of invalid sessions on our JSF application.
Some details:
- The whole page is role protected (url-pattern: /*)
- Login and logout are programmatically done on a Servlet, using HttpServletRequest#login and HttpServletRequest#logout methods (form login).
- Application is not marked <distributable />, and there's only one node.
I have two stacktraces. The first one is from the user request:
{quote}
java.lang.IllegalStateException: UT000010: Session is invalid qx9ZygAt_gKYG__SAFEOI1ojrUXvN5lZ2wXl0c9O
at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:471)
at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122)
at com.sun.faces.context.SessionMap.put(SessionMap.java:127)
at com.sun.faces.context.SessionMap.put(SessionMap.java:61)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.getResponseEncoding(FaceletViewHandlingStrategy.java:1310)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1198)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:405)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:134)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:93)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at xx.xxxxxxx.xxxxxxx.xxxxxxx.xxxxx.ServletFilter.doFilter(PermisosFilter.java:56)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:201)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:178)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
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:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{quote}
It seems to pass the security checks (so I should assume the session is still valid?), but then it fails on the JSF part.
After that, the error page is shown, but if fails again since it uses a view scoped bean:
{quote}
java.lang.IllegalStateException: UT000010: Session is invalid qx9ZygAt_gKYG__SAFEOI1ojrUXvN5lZ2wXl0c9O
at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:471)
at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122)
at com.sun.faces.context.SessionMap.get(SessionMap.java:118)
at com.sun.faces.application.view.ViewScopeContextManager.getContextMap(ViewScopeContextManager.java:244)
at com.sun.faces.application.view.ViewScopeContextManager.getContextMap(ViewScopeContextManager.java:228)
at com.sun.faces.application.view.ViewScopeContextManager.getBean(ViewScopeContextManager.java:201)
at com.sun.faces.application.view.ViewScopeContext.get(ViewScopeContext.java:108)
at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:70)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
at xx.xxxxxxx.xxxxxxx.xxxxxxx.xxxxxxxxxxxxx.ViewScopedCDIBean$Proxy$_$$_WeldClientProxy.isActivado(Unknown Source)
at xx.xxxxxxx.xxxxxxx.xxxxxxx.xxxxxxxxxxxxx.JSFPhaseCycleListener.afterPhase(SistemaToDo.java:37)
at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:189)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:107)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:209)
at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:480)
at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:413)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:319)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
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:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{quote}
This traces appear every two days or so. I don't have much insight on the user steps involved, but I can set an HttpSessionListener to check if sessions are really invalid.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (JASSIST-264) avassist.ModuleClassPath throws NoSuchMethodError when running on Jigsaw EA build
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-264?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-264:
---------------------------------------
The next release of Javassist is now being developed to follow Java 9 EA releases.
So it would be good to modify Javassist to support the latest updates to jigsaw after the updates are merged into Java 9. I'm subscribing Java 9 EA release announcements so will do this as soon as the things are ready.
> avassist.ModuleClassPath throws NoSuchMethodError when running on Jigsaw EA build
> ---------------------------------------------------------------------------------
>
> Key: JASSIST-264
> URL: https://issues.jboss.org/browse/JASSIST-264
> Project: Javassist
> Issue Type: Bug
> Reporter: Mandy Chung
> Assignee: Shigeru Chiba
>
> Project Jigsaw EA build is available for download at
> http://openjdk.java.net/projects/jigsaw/ea
> The Jigsaw EA build is the latest prototype implementation of JSR 376, the Java Platform Module System, that implements the proposals to resolve the JSR 376 open issues:
> http://openjdk.java.net/projects/jigsaw/spec/issues/
> java.lang.NoSuchMethodError: java.lang.reflect.Layer.parent()Ljava/util/Optional;
> at javassist.ModuleClassPath.<init>(ModuleClassPath.java:53)
> at javassist.ModuleClassPath.<init>(ModuleClassPath.java:39)
> at javassist.ClassPoolTail.appendSystemPath(ClassPoolTail.java:249)
> at javassist.ClassPool.appendSystemPath(ClassPool.java:944)
> at javassist.ClassPool.<init>(ClassPool.java:179)
> is calling java.lang.reflect.Layer::parent method. Layer::parent method is not present due to the solution #NonHierarchicalLayers issue.
> Looks like ModuleClassPath class is added to resolved JASSIST-261 and unclear why Layer::parent is needed. But looks like this is related to #ClassFilesAsResources issue in JDK 9 that encapsulate .class file from access.
> The Jigsaw EA build has resolved #ClassFilesAsResources to allow ClassLoader::getResource* methods to access .class files. Note that this is not in JDK 9 yet. Please subscribe to jigsaw-dev(a)openjdk.java.net for announcement.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7554) Singleton: @AccessTimeout and @Lock on superclass method not
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7554?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-7554:
--------------------------------------
I can't reproduce this (in fact we have a test that covers it, org.jboss.as.test.integration.ejb.singleton.concurrency.inheritance.SingletonConcurrencyInheritanceTestCase). Can you provide a reproducer?
> Singleton: @AccessTimeout and @Lock on superclass method not
> -------------------------------------------------------------
>
> Key: WFLY-7554
> URL: https://issues.jboss.org/browse/WFLY-7554
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.2.Final, 10.1.0.Final
> Environment: Win7_64, Oracle Java 8/102
> Reporter: Stefan Lindner
> Assignee: Stuart Douglas
>
> {code:java}
> @AccessTimeout(value=54321)
> class MySuperclass {
> @AccessTimeout(value=1200000000000L)
> public void whileBlocked() {....}
> }
> @Singleton
> @Startup
> @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)
> @DependsOn("BenutzerControllerImpl")
> @AccessTimeout(value=54321)
> @Lock(LockType.READ)
> class MyClass extends MySuperclass {
> @Lock(LockType.WRITE)
> public void myBlocker() {....}
> }
> {code}
> Calling method {code:java}whileBlocked{code} when another thread has called {code:java}myBlocker{code} leads to Exception
> javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on MyClass - could not obtain lock within 5000MILLISECONDS
> The standard says:
> {quote}The AccessTimeout annotation can be specified on a business method or on a bean class (or superclass).
> {quote}
> In short:
> # @AccessTimeout annotations on bean's class or method work as expected
> # Annotations on superclass do not
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7554) Singleton: @AccessTimeout and @Lock on superclass method not
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7554?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-7554:
------------------------------------
Assignee: Stuart Douglas
> Singleton: @AccessTimeout and @Lock on superclass method not
> -------------------------------------------------------------
>
> Key: WFLY-7554
> URL: https://issues.jboss.org/browse/WFLY-7554
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.2.Final, 10.1.0.Final
> Environment: Win7_64, Oracle Java 8/102
> Reporter: Stefan Lindner
> Assignee: Stuart Douglas
>
> {code:java}
> @AccessTimeout(value=54321)
> class MySuperclass {
> @AccessTimeout(value=1200000000000L)
> public void whileBlocked() {....}
> }
> @Singleton
> @Startup
> @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)
> @DependsOn("BenutzerControllerImpl")
> @AccessTimeout(value=54321)
> @Lock(LockType.READ)
> class MyClass extends MySuperclass {
> @Lock(LockType.WRITE)
> public void myBlocker() {....}
> }
> {code}
> Calling method {code:java}whileBlocked{code} when another thread has called {code:java}myBlocker{code} leads to Exception
> javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on MyClass - could not obtain lock within 5000MILLISECONDS
> The standard says:
> {quote}The AccessTimeout annotation can be specified on a business method or on a bean class (or superclass).
> {quote}
> In short:
> # @AccessTimeout annotations on bean's class or method work as expected
> # Annotations on superclass do not
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7567) Getting an unexpected token : UNION when running a query
by Prasanth Reddy (JIRA)
Prasanth Reddy created WFLY-7567:
------------------------------------
Summary: Getting an unexpected token : UNION when running a query
Key: WFLY-7567
URL: https://issues.jboss.org/browse/WFLY-7567
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 10.1.0.Final
Environment: Wildfly 10.1.0 Final
Cent OS 6
JAVA 1.8.0_40
Reporter: Prasanth Reddy
Assignee: Scott Marlow
Priority: Critical
When running the below EJBQL wildfly 10.1.0 throws an exception. The same works fine in wildfly 9.2.0. I have manually edited the sql below to change the names of tables (so please ignore if there is an error in the sql). The data types of the columns selected are the same.
SELECT a.pID FROM Arrangement a WHERE a.pID=30947 AND a.effectiveDate = '08/21/2001' UNION SELECT e.yID FROM Event e WHERE e.policyID=30947 AND e.proceedsDate = '08/20/2001'
Caused by: org.hibernate.hql.internal.ast.QuerySyntaxException: unexpected token: UNION near line 1, column 86 [SELECT a.pID FROM Arrangement a WHERE a.pID=30947 AND a.effectiveDate = '08/21/2001' UNION SELECT e.yID FROM Event e WHERE e.policyID=30947 AND e.proceedsDate = '08/20/2001']
at org.hibernate.hql.internal.ast.QuerySyntaxException.convert(QuerySyntaxException.java:74)
at org.hibernate.hql.internal.ast.ErrorCounter.throwQueryException(ErrorCounter.java:91)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:288)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:187)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:142)
at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:115)
at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:76)
at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:150)
at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:302)
at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:240)
at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1894)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:291)
... 89 more
Thanks,
Prasanth
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1977) Embedded Server ignores system properties when starting.
by Ken Wills (JIRA)
Ken Wills created WFCORE-1977:
---------------------------------
Summary: Embedded Server ignores system properties when starting.
Key: WFCORE-1977
URL: https://issues.jboss.org/browse/WFCORE-1977
Project: WildFly Core
Issue Type: Bug
Reporter: Ken Wills
Assignee: Ken Wills
Currently, using jboss-cli.sh with (for example) -Djboss.server.base.dir=/foo/bar, then starting an embedded server ignores the specified base dir.
This should be used in the same way as standalone currently does, as should the rest of the commonly passed properties (log.dir etc etc).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7566) connections-per-thread description and default value
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7566?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-7090 to WFLY-7566:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7566 (was: JBEAP-7090)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: mod_cluster
Web (Undertow)
(was: mod_cluster)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.DR7)
> connections-per-thread description and default value
> ----------------------------------------------------
>
> Key: WFLY-7566
> URL: https://issues.jboss.org/browse/WFLY-7566
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Minor
>
> Description for {{/subsystem=undertow/configuration=filter/mod-cluster=load-balancer\[connections-per-thread\]}}
> {code}
> "connections-per-thread" => {
> "type" => INT,
> "description" => "The number of connections that will be maintained to backend servers, per IO thread. Defaults to 10.",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => 40,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> {code}
> and for {{/profile=load-balancer/subsystem=undertow/configuration=handler/reverse-proxy=my-rev-proxy\[connections-per-thread\]}}
> {code}
> "connections-per-thread" => {
> "type" => INT,
> "description" => "The number of connections that will be maintained to backend servers, per IO thread. Defaults to 10.",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => 10,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> {code}
> I can see one or maybe two problems there:
> # Description for {{connections-per-thread}} in {{mod-cluster}} element is wrong as it does not reflect reality as it says that default value for that attribute is {{10}}, but in fact default value there is {{40}}. Maybe we should just remove information about default value from the description completely?
> # Is not actually wrong that those two attributes have different default value as they basically reffer to the same thing althgouth one in the {{mod-cluster}} and second in the {{reverse-proxy}}?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7565) Server provides very generic error when 'management-access-predicate' attribute is set badly
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7565?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-7089 to WFLY-7565:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7565 (was: JBEAP-7089)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: mod_cluster
Web (Undertow)
(was: mod_cluster)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.DR7)
> Server provides very generic error when 'management-access-predicate' attribute is set badly
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-7565
> URL: https://issues.jboss.org/browse/WFLY-7565
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> When I set a {{management-access-predicate}} attribute in {{mod-cluster}} filter to some non-sense value and perform reload as requested, server prints following error in server.log:
> {code}
> 11:18:13,442 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: {
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined,
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.ejb.default-local-ejb-receiver-service",
> "jboss.ejb3.ejbClientContext.default",
> "jboss.ejb3.localEjbReceiver.value"
> ],
> "Services that may be the cause:" => [
> "jboss.remoting.remotingConnectorInfoService.http-remoting-connector",
> "jboss.undertow",
> "jboss.web.common.server"
> ]
> }
> }
> 11:18:13,443 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb3.connector is missing [jboss.remoting.remotingConnectorInfoService.http-remoting-connector]"]
> }
> 11:18:13,443 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "webservices")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => [
> "jboss.web.common.server",
> "jboss.undertow"
> ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ws.config is missing [jboss.undertow, jboss.web.common.server]"]
> }
> {code}
> From that error it is very hard to see what is actually causing the problem. Only what I can see is that some of the subsystems probably did not started and I need to investigate.
> It would be nice if either this error would point me more precisely to the badly set {{management-access-predicate}} attribute or (what would be probably even better) if I the operation when I tried to set that attribute with invalid value ended with error with appropriate message directly.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months