[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)
9 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)
9 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)
9 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:
----------------------------------------
If the folks at Intellij need help translating the above CLI into a low level management op, I'll be glad to help.
> 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)
9 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:
----------------------------------------
IMO this is primarily a problem with Intellij.
This works fine from the CLI (with ~/tmp/hello being an exploded deployment):
{code}
[standalone@localhost:9990 /] deploy ~/tmp/hello --runtime-name=helloworld.war --unmanaged
{code}
That's CLI command syntax that results in a low level management op that Intellij could certainly execute as well. The key part is adding the "runtime-name" parameter to the op, with a value that indicates the deployment is a war. Presumably the tooling knows this.
Perhaps there is still a valid feature request here, if the idea is somehow WildFly just knows it's a war. But I doubt that will change. Note that Tomcat can make an assumption about a deployment just being a war because it doesn't deploy ears and ejb jars and sars and datasources and driver jars and...
> 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)
9 years, 7 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3509 to WFCORE-433:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-433 (was: WFLY-3509)
Component/s: Domain Management
(was: Domain Management)
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
> Priority: Critical
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-3509) git backend for loading/storing the configuration XML for wildfly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3509?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3509:
-----------------------------------
Component/s: Domain Management
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFLY-3509
> URL: https://issues.jboss.org/browse/WFLY-3509
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
> Priority: Critical
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-3166) can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3166:
-----------------------------------
Component/s: (was: CLI)
> can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-3166
> URL: https://issues.jboss.org/browse/WFLY-3166
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Web Console
> Affects Versions: 8.0.0.Final
> Environment: Red Hat Enterprise Linux Server release 5.5
> Reporter: Fai Gao
> Assignee: Stefano Maestri
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but the lable of enabled didn't turn to √(enabled).
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
> "rolled-back" => true
> }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1] ("subsystem" => "datasources"),
> [Server:fserver1] ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]
> I tried in the standalone mode,it worked.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-1180) CLI: Embedded Arrays need to be updatable easily
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1180?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-1180.
-------------------------------
Resolution: Done
implemented as part of WFCORE-14
> CLI: Embedded Arrays need to be updatable easily
> ------------------------------------------------
>
> Key: WFLY-1180
> URL: https://issues.jboss.org/browse/WFLY-1180
> Project: WildFly
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jim Tyrrell
> Assignee: Alexey Loubyansky
> Labels: eap6-ux
>
> In the EAP 6 pilot we were presented a long string to create a Database Security Realm, it appears there is no way to update a single value. For example being able to change the string of the SQL of a principalsQuery or rolesQuery for example. Without having to put in the entire vale.
> /profile=default/subsystem=security/security-domain=DB_domain:add(authentication=[{"code" => "Database", "flag" => "required", "module-options"=>[("principalsQuery"=>"Select password from UsersTable.....
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months