[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-273:
-----------------------------------------
[~luck3y], given the statement in the description "Otherwise the process will just get removed, however started with the next :reload of the HC", I *think* the original "bug" scenario was this:
1) Start an HC "foo" with a server "bar" that has auto-start=true in its server-config
2) /host=foo/server=bar:stop
3) reload --host=foo --restart-servers=false
When step 3 is done, server "bar" would still be stopped. Because the --restart-servers param is set to false, the user is indicating the reload is not meant to change what servers are running. So, the auto-start=true should not take precedence over the fact the server was stopped.
Arguably the same could be said with --restart-servers=true as well, i.e. that a reload is not the same thing as a new boot.
I think the thing to do here is to have a solution that fits best with the WFCORE-297 fix, but adds in clear semantics for the --restart-servers=false case. Double check with [~ehugonnet] but I believe what was done with 297 was adding that update-auto-start-with-server-status = true to cause the HC to "remember" whether a server is stopped/started and then use that when it restarts. And if that attribute isn't true, then the HC doesn't "remember" and all that matters is what's in host.xml. My instinct is the right thing to do is to be consistent when doing a reload as well. A reload is really just a faster restart that preserves the same process. It's behavior should be as close to restart as possible.
It's quite likely that WFCORE-297 has fixed this as well.
BTW, regardless of these attributes, in the "reload --host=foo --restart-servers=false" case, if a server was running before the reload, the HC needs to properly trigger a reconnect. We can never have a situation where after a reload a disconnected server is left floating unmanaged as a zombie.
> ServerInventory#reconnectServer should take auto-start into account
> -------------------------------------------------------------------
>
> Key: WFCORE-273
> URL: https://issues.jboss.org/browse/WFCORE-273
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha1
>
>
> When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBASMP-71) JBoss Maven Plugin fails deploy in domain mode if one server is stopped
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-71?page=com.atlassian.jira.plugin.... ]
James Perkins resolved JBASMP-71.
---------------------------------
Fix Version/s: 7.8.Final
Resolution: Done
> JBoss Maven Plugin fails deploy in domain mode if one server is stopped
> -----------------------------------------------------------------------
>
> Key: JBASMP-71
> URL: https://issues.jboss.org/browse/JBASMP-71
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Components: deploy
> Affects Versions: 7.5.Final
> Reporter: Jorge Solorzano
> Assignee: Filippe Spolti
> Fix For: 7.8.Final
>
>
> I have a cluster in domain mode and configured my project to do the deploy on a server group (jboss-as:deploy), but if I have one server stopped the deploy fails.
> I think it should do the deploy even if all servers are stopped, after all the master is the one who get the deploy and when the servers come back online then the master sends the content to the servers.
> If I do the deploy directly from the manangement console it don't care if all servers (in the server group) are stopped.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6433) Getting internal server error
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6433?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-6433.
-----------------------------
Resolution: Rejected
Questions like this belong to user forums not bug tracker.
You can find forums at https://developer.jboss.org/en/wildfly
> Getting internal server error
> -----------------------------
>
> Key: WFLY-6433
> URL: https://issues.jboss.org/browse/WFLY-6433
> Project: WildFly
> Issue Type: Bug
> Reporter: Amiruddin Awakhalwala
> Assignee: Jason Greene
> Priority: Blocker
>
> Getting Internal Server Error.
> --- Log Trace ---
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /login: javax.servlet.ServletException: Filtered request failed.
> at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:384)
> at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 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.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 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.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.hdiv.idGenerator.RandomGuid
> at org.hdiv.idGenerator.RandomGuidUidGenerator.generateUid(RandomGuidUidGenerator.java:56)
> at org.hdiv.dataComposer.AbstractDataComposer.getStateSuffix(AbstractDataComposer.java:654)
> at org.hdiv.dataComposer.DataComposerMemory.endRequest(DataComposerMemory.java:213)
> at org.hdiv.dataComposer.DataComposerMemory.endPage(DataComposerMemory.java:253)
> at org.hdiv.filter.ValidatorHelperRequest.endPage(ValidatorHelperRequest.java:1203)
> at org.hdiv.filter.ValidatorFilter.processRequest(ValidatorFilter.java:252)
> at org.hdiv.filter.ValidatorFilter.doFilterInternal(ValidatorFilter.java:181)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
> at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
> at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
> at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
> at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
> at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
> at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
> at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
> at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6433) Getting internal server error
by Amiruddin Awakhalwala (JIRA)
Amiruddin Awakhalwala created WFLY-6433:
-------------------------------------------
Summary: Getting internal server error
Key: WFLY-6433
URL: https://issues.jboss.org/browse/WFLY-6433
Project: WildFly
Issue Type: Bug
Reporter: Amiruddin Awakhalwala
Assignee: Jason Greene
Priority: Blocker
Getting Internal Server Error.
--- Log Trace ---
ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /login: javax.servlet.ServletException: Filtered request failed.
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:384)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
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.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
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.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
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)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.hdiv.idGenerator.RandomGuid
at org.hdiv.idGenerator.RandomGuidUidGenerator.generateUid(RandomGuidUidGenerator.java:56)
at org.hdiv.dataComposer.AbstractDataComposer.getStateSuffix(AbstractDataComposer.java:654)
at org.hdiv.dataComposer.DataComposerMemory.endRequest(DataComposerMemory.java:213)
at org.hdiv.dataComposer.DataComposerMemory.endPage(DataComposerMemory.java:253)
at org.hdiv.filter.ValidatorHelperRequest.endPage(ValidatorHelperRequest.java:1203)
at org.hdiv.filter.ValidatorFilter.processRequest(ValidatorFilter.java:252)
at org.hdiv.filter.ValidatorFilter.doFilterInternal(ValidatorFilter.java:181)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-355:
------------------------------------
Priority: Blocker (was: Major)
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-355:
-----------------------------------------
Jigsaw is now part of JDK 9. Raising priority of this issue.
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1107) Upgrade to JPA 2.1 and Hibernate 5
by Petar Tahchiev (JIRA)
Petar Tahchiev created DROOLS-1107:
--------------------------------------
Summary: Upgrade to JPA 2.1 and Hibernate 5
Key: DROOLS-1107
URL: https://issues.jboss.org/browse/DROOLS-1107
Project: Drools
Issue Type: Enhancement
Reporter: Petar Tahchiev
Assignee: Mark Proctor
Hello,
my app is running with Hibernate5 and JPA2.1 and when I try to use latest {{drools-persistence-jpa}} I get this exception:
{code}
Caused by: java.lang.NoSuchMethodError: javax.persistence.CollectionTable.indexes()[Ljavax/persistence/Index;
at org.hibernate.cfg.AnnotationBinder.bindJoinedTableAssociation(AnnotationBinder.java:2378)
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:2094)
at org.hibernate.cfg.AnnotationBinder.processIdPropertiesIfNotAlready(AnnotationBinder.java:906)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:733)
{code}
Hibernate5 is already stable. Please update to it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6294) Session draining always takes maximum configured timeout
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6294?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6294:
-----------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1314792|https://bugzilla.redhat.com/show_bug.cgi?id=1314792] from NEW to POST
> Session draining always takes maximum configured timeout
> --------------------------------------------------------
>
> Key: WFLY-6294
> URL: https://issues.jboss.org/browse/WFLY-6294
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Aaron Ogburn
> Assignee: Radoslav Husar
> Priority: Minor
>
> The mod_cluster session drain wait is not ending as expected. mod_cluster adds a session listener to be notified of session destruction. That is fired appropriately, but when the listener is invoked, the infinispan session manager still reports the session as active. Thus, this drain loop doesn't end after the notify because it still sees the active session:
> {code}
> while ((remainingSessions > 0) && (noTimeout || (timeout > 0))) {
> ModClusterLogger.LOGGER.drainSessions(remainingSessions, context.getHost(), context);
> listener.wait(noTimeout ? 0 : timeout);
> current = System.currentTimeMillis();
> timeout = end - current;
> remainingSessions = context.getActiveSessionCount();
> }
> {code}
> Can the listeners be invoked when the session is fully removed and no longer considered active?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month