[JBoss JIRA] (WFLY-4028) Can't register cache-container with more than one local-cache entries
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4028?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-4028.
------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Out of Date
This works on master, thus won't be a problem in the next 9.0.0 milestone release.
> Can't register cache-container with more than one local-cache entries
> ---------------------------------------------------------------------
>
> Key: WFLY-4028
> URL: https://issues.jboss.org/browse/WFLY-4028
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Dmitry Lisovsky
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> When I try to add my cache-container with more then one local-cache entries in standalone-full.xml I got error:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 38) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "infinispan"),
> ("cache-container" => "my-container-name"),
> ("local-cache" => "my-2nd-local-cache-name")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.naming.context.java.jboss.true is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1866) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.installJndiService(CacheAddHandler.java:318)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.installRuntimeServices(CacheAddHandler.java:225)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAddHandler.performRuntime(CacheAddHandler.java:180)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:131) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:695) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:530) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:298) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:355) [wildfly-controller-1.0.0.Alpha8.jar:1.0.0.Alpha8]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {noformat}
> The XML I'm trying to add:
> {noformat}
> <cache-container name="my-container-name" jndi-name="java:jboss/infinispan/container/my-container-name">
> <local-cache name="my-1st-local-cache-name" batching="true">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <local-cache name="my-2nd-local-cache-name" batching="true">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <local-cache name="my-3rd-local-cache-name" batching="true">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> </cache-container>
> {noformat}
> In the Wildfly 8.1.0 it worked OK.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service
by Chezy Palani (JIRA)
[ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.... ]
Chezy Palani commented on WFLY-4126:
------------------------------------
Can someone please help with this one? Do you think that the servlet-api.jar or jstl.jar we are using could cause this issue?
> java.lang.ExceptionInInitializerError when invoking BIRT service
> ----------------------------------------------------------------
>
> Key: WFLY-4126
> URL: https://issues.jboss.org/browse/WFLY-4126
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 and JDK 1.8
> Reporter: Chezy Palani
> Assignee: Stuart Douglas
> Attachments: server.log.2014-11-25
>
>
> There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception.
> Context Path:
> /actuatejavacomponent
> Servlet Path:
> /iv
> Path Info:
> null
> Query String:
> __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US
> Stack Trace
> javax.servlet.ServletException: java.lang.ExceptionInInitializerError
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198)
> io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279)
> com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261)
> com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144)
> com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-4142) ear-sub-deployments-isolated is still ignored from jboss-deployment-structure.xml
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4142?page=com.atlassian.jira.plugin.... ]
Stuart Douglas closed WFLY-4142.
--------------------------------
Resolution: Cannot Reproduce Bug
We have a test for this in the test suite that is present in the 8.1.0.Final tag, and even though the initial fix was reverted an updated one was applied the next day.
If this is still a problem for you you are going to need to provide a reproducer that demonstrates the issue.
> ear-sub-deployments-isolated is still ignored from jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------
>
> Key: WFLY-4142
> URL: https://issues.jboss.org/browse/WFLY-4142
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
> Reporter: Gabriele Garuglieri
> Assignee: Stuart Douglas
>
> The default processor runs later, and overwrites the value provided by this file.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFCORE-208) Expose 'singleton' type information in read-children-types
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-208?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet reassigned WFCORE-208:
----------------------------------------
Assignee: Emmanuel Hugonnet
> Expose 'singleton' type information in read-children-types
> ----------------------------------------------------------
>
> Key: WFCORE-208
> URL: https://issues.jboss.org/browse/WFCORE-208
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
> The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
> The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
> If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
> {code}
> "result"=> ["service"]
> {code}
> If the "include-singletons" parameter was set to 'true' it would be:
> {code}
> "result"=> ["service=remote", "service=async"]
> {code}
> Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
> The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
> Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
> However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
> {code}
> "result"=> ["datasource", "datasource=ExampleDS"]
> {code}
> A client that sees both "key" and "key=xxx" in a result can safely assume that "key=xxx" represents an override registration, overriding the basic type registered under "key=*".
> Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
> {code}
> "result"=> ["datasource=ExampleDS", "datasource"]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFCORE-361) CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-361?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-361:
---------------------------------------
Assignee: Emmanuel Hugonnet (was: Brian Stansberry)
Emmanuel, once WFCORE-400 is resolved, please just resolve this one as Out of Date.
> CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error)
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-361
> URL: https://issues.jboss.org/browse/WFCORE-361
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Pavel Janousek
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> The same situation is with every shipped and supported configuration/profile. As base for my explanation I'm using standalone.xml. Standalone.xml declares xmlns as:
> {code}
> <server xmlns="urn:jboss:domain:1.3">
> {code}
> The real XSD file which defined elements is jboss-eap-6.0/docs/schema/jboss-as-config_1_3.xsd.
> The very common Linux system has implemented and enabled dualstack in these days. If we instruct AS instance to bind to +any+ IPv4 address via {code}<interface name="public">
> <any-ipv4-address />
> </interface>{code}
> The real result is to bind running AS instance to +any+ IP address, not only in IPv4 address space but in IPv6 too!
> With default setting (= -Djava.net.preferIPv4Stack=true), result is correct - it is bound to ANY IPv4 addresses only.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months