[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)
11 years, 5 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)
11 years, 5 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)
11 years, 5 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)
11 years, 5 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)
11 years, 5 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)
11 years, 5 months
[JBoss JIRA] (WFCORE-431) CLI should WARN about usage deprecated api
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-431?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3622 to WFCORE-431:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-431 (was: WFLY-3622)
Component/s: CLI
(was: CLI)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> CLI should WARN about usage deprecated api
> ------------------------------------------
>
> Key: WFCORE-431
> URL: https://issues.jboss.org/browse/WFCORE-431
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Tomaz Cerar
> Assignee: Alexey Loubyansky
> Fix For: 1.0.0.Beta1
>
>
> We added support for deprecating resources/attributes/operations/parameters some time ago.
> I would be a good thing that we would warn users if they are using deprecated API.
> Every resource/attribute/operation/param that is deprecated has extra element "deprecated" in metadata
> With sub elements
> - "since", which tells in what version it was deprecated
> - "reason", text description why it is deprecated.
> Reason in most cases also tells what is new replacement.
> This should be only displayed in case of interactive shell usage.
> Unless there is also some special CLI log file, it could be part of that even for non-interactive usage
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (WFCORE-432) CLI: Embedded Arrays need to be updatable easily
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-432?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-1180 to WFCORE-432:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-432 (was: WFLY-1180)
Component/s: CLI
(was: CLI)
> CLI: Embedded Arrays need to be updatable easily
> ------------------------------------------------
>
> Key: WFCORE-432
> URL: https://issues.jboss.org/browse/WFCORE-432
> Project: WildFly Core
> 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)
11 years, 5 months
[JBoss JIRA] (WFCORE-427) CLI doesn't read alias from .jbossclirc
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-427?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3824 to WFCORE-427:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-427 (was: WFLY-3824)
Affects Version/s: (was: 8.1.0.Final)
Component/s: CLI
(was: CLI)
> CLI doesn't read alias from .jbossclirc
> ---------------------------------------
>
> Key: WFCORE-427
> URL: https://issues.jboss.org/browse/WFCORE-427
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Osamu Nagano
> Assignee: Alexey Loubyansky
>
> By WFLY-1063, a variable can be defined in .jbossclirc and preloaded by CLI. But aliases are not able to define with {{org.jboss.as.cli.CliInitializationException}}.
> {code}
> $ cat .jbossclirc
> set prod_db=/subsystem=datasources/data-source=ExampleDS
> alias ll=ls -l
> $ $JBOSS_HOME/bin/jboss-cli.sh -c
> Unexpected command 'alias ll=ls -l'. Type 'help --commands' for the list of supported commands.
> org.jboss.as.cli.CliInitializationException: Failed to process /home/onagano/cases/01180422/wf810/.jbossclirc
> at org.jboss.as.cli.impl.CliLauncher.runcom(CliLauncher.java:352)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:305)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> {code}
> Enclosing by single quote or double quote won't help.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months