[JBoss JIRA] (WFLY-3983) Unknown deployment type: resource-adapters when user click on resource adapter in admin console
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3983?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3983:
-----------------------------------
Priority: Major (was: Critical)
> Unknown deployment type: resource-adapters when user click on resource adapter in admin console
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-3983
> URL: https://issues.jboss.org/browse/WFLY-3983
> Project: WildFly
> Issue Type: Bug
> Affects Versions: JBoss AS7 7.2.0.Final
> Environment: JBOSS EAP 6.2 , Windows
> Reporter: Sri chilukuri
> Assignee: Jason Greene
>
> We have myproduct.ear which is deployed in JBoss EAP 6.2. myproduct.ear contains following modules. All the modules are deployed and everything works as expected. We are having 'Unknown deployment type: resource-adapters' error message when we click on myproduct.ear.myadapter.rar in Runtime.Deployments.Available Deployments in Admin console. This is working fine in JBoss EAP 6.1 and issue is showing up from JBoss EAP 6.2 to wildfly-8.1.0.Final. myproduct.ear.myweb.war and myweb.war.mybeans.jar works as expected when user click on them.
> EAR modules:
> myproduct.ear
> ------ myweb.war
> ------ mybeans.jar
> -------myadapter.rar
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFLY-4028) Can't register cache-container with more than one local-cache entries
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4028?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4028:
-----------------------------------
Component/s: Clustering
> 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: Jason Greene
>
> 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)
11 years, 7 months
[JBoss JIRA] (WFLY-4028) Can't register cache-container with more than one local-cache entries
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4028?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4028:
-----------------------------------
Assignee: Paul Ferraro (was: Jason Greene)
> 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
>
> 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)
11 years, 7 months
[JBoss JIRA] (WFLY-4043) Cannot load custom login module
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4043?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-4043:
----------------------------------------
What does the login-module config look like? Are you correctly setting the "module" attribute?
> Cannot load custom login module
> -------------------------------
>
> Key: WFLY-4043
> URL: https://issues.jboss.org/browse/WFLY-4043
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Environment: Java 1.8.0_25
> Reporter: Rostyslav Smirnov
> Assignee: Jason Greene
>
> When security realm authentication is configured to use JAAS domain, it is not possible to use custom login module, because there is no loader present for deployed classes. LoginContext attempts to load the login module class and fails with ClassNotFoundException.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFLY-4043) Cannot load custom login module
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4043?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4043:
-----------------------------------
Component/s: Security
> Cannot load custom login module
> -------------------------------
>
> Key: WFLY-4043
> URL: https://issues.jboss.org/browse/WFLY-4043
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Environment: Java 1.8.0_25
> Reporter: Rostyslav Smirnov
> Assignee: Jason Greene
>
> When security realm authentication is configured to use JAAS domain, it is not possible to use custom login module, because there is no loader present for deployed classes. LoginContext attempts to load the login module class and fails with ClassNotFoundException.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFLY-4055) Show more details for the EJB SessionBean statistic
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4055?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4055:
-----------------------------------
Component/s: EJB
> Show more details for the EJB SessionBean statistic
> ---------------------------------------------------
>
> Key: WFLY-4055
> URL: https://issues.jboss.org/browse/WFLY-4055
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
>
> The JMX MBeans in former versions <7 show more statistics.
> As this counters can be important they should be collected in WildFly as well.
> SLSB:
> Current- Available- Max- (pool), Remove, Create
> SFSB:
> CacheSize, CreateSize, InvocStat, PassivatedCount, Current, RemoveCount, Available, Max, Total
> As there is no pool possible for SFSB there is no Create and Remove counter for pooling and no counter of current instances.
> These counters should be added
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFLY-4081) Do not force that the exploded directory ends with ".war"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4081?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-4081:
----------------------------------------
Low-level CLI syntax for the above high-level command:
{code}
[standalone@localhost:9990 /] /deployment=hello:add(runtime-name=helloworld.war,enabled=true,content=[{path=/home/me/tmp/hello,archive=false}])
{"outcome" => "success"}
{code}
The CLI echo-dmr command translates that into DMR text format, so a custom client like a plugin that uses a ModelControllerClient would construct an operation ModelNode like this output from the echo-dmr command:
{code}
[standalone@localhost:9990 /] echo-dmr /deployment=hello:add(runtime-name=helloworld.war,enabled=true,content=[{path=/Users/bstansberry/tmp/hello,archive=false}])
{
"address" => [("deployment" => "hello")],
"operation" => "add",
"content" => [{
"path" => "/home/mey/tmp/hello",
"archive" => "false"
}],
"runtime-name" => "helloworld.war",
"enabled" => true
}
{code}
> Do not force that the exploded directory ends with ".war"
> ---------------------------------------------------------
>
> Key: WFLY-4081
> URL: https://issues.jboss.org/browse/WFLY-4081
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Geoffrey De Smet
> Assignee: Jason Greene
>
> In a standard webapp, maven creates the following directory and file:
> // Exploded directory
> target/mywebapp-1.0/
> // War file
> target/mywebapp-1.0.war
> *Unfortunately, WildFly forces that exploded directories should have the suffix ".war"*. At least the IntelliJ JBoss app server plugin enforces this, if that's no longer the case, they should fix it asap. This has 2 side effects:
> 1) Every noob fails to deploy an exploded dir to WildFly in IntelliJ. By the time they realize that it's because they haven't adjusted the exploded artifact's output path, they're already using Jetty or Tomcat (which "just work" in IntelliJ).
> 2) As a result, maven and IntelliJ are potentially incompatible for WildFly:
> If you just suffix the exploded directory with ".war", the exploded directory clashes with maven's war file.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-296) Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-296?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFCORE-296:
------------------------------------
We'd better visit these changes upon JMX as well, as it's using the even weirder "http-remoting-jmx" when it should just use plain old "remote+http" (and likewise for other variations).
> Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-296
> URL: https://issues.jboss.org/browse/WFCORE-296
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI, Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> From [~dmlloyd]
> {quote}
> When we have multi-layer protocol going on, the URI scheme we should use
> is like this:
> outer+middle+inner://
> {quote}
> Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> The existing schemes will be needed for backwards compatibility but somehow deprecated.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months