[JBoss JIRA] (WFLY-3104) datasource created with console cannot be enabled
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3104?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3104:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079241
> datasource created with console cannot be enabled
> -------------------------------------------------
>
> Key: WFLY-3104
> URL: https://issues.jboss.org/browse/WFLY-3104
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Final
> Environment: Wildfly 8.0.0 Final
> Reporter: Gabriele Garuglieri
> Assignee: Stefano Maestri
>
> Consider the following cli file:
> {noformat}
> /subsystem=datasources/data-source=fai-bfsa:add( \
> driver-name=PostgresJDBCDriver, \
> driver-class="org.postgresql.Driver", \
> jndi-name=java:jboss/jdbc/fai-bfsa, \
> connection-url=jdbc:postgresql://tpg0001:5432/xfgb01, \
> max-pool-size=20, \
> min-pool-size=10, \
> new-connection-sql="select 1", \
> check-valid-connection-sql="select 1", \
> user-name=uuuuu, \
> password=uuuuu, \
> background-validation=false, \
> validate-on-match=false, \
> enabled=false, \
> jta=true, \
> use-ccm=true, \
> share-prepared-statements=false, \
> )
> {noformat}
> This is reflected into standalone-full.xml as:
> {code:xml}
> <datasource jta="true" jndi-name="java:jboss/jdbc/fai-bfsa" pool-name="fai-bfsa" enabled="false" use-ccm="true">
> <connection-url>jdbc:postgresql://tpg0001:5432/xfgb01</connection-url>
> <driver-class>org.postgresql.Driver</driver-class>
> <driver>PostgresJDBCDriver</driver>
> <new-connection-sql>select 1</new-connection-sql>
> <pool>
> <min-pool-size>10</min-pool-size>
> <max-pool-size>20</max-pool-size>
> </pool>
> <security>
> <user-name>uuuuu</user-name>
> <password>uuuuu</password>
> </security>
> <validation>
> <check-valid-connection-sql>select 1</check-valid-connection-sql>
> <validate-on-match>false</validate-on-match>
> <background-validation>false</background-validation>
> </validation>
> <statement>
> <share-prepared-statements>false</share-prepared-statements>
> </statement>
> </datasource>
> {code}
> I can now enable and disable that datasource both via cli or console without problem.
> If i create the same datasource via console, with the very same attributes, producing the very same standalone-full.xml (i have diffed them), i cannot enable it nether via cli nor console because i get the following error:
> {noformat}
> 14:33:00,230 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-3) Error during the deployment of java:jboss/jdbc/fai-bfsa: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.getTransactionIntegration(AbstractDataSourceService.java:409)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.createMcf(AbstractDataSourceService.java:461)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:430)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:283)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:310)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:124)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> 14:33:00,236 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.data-source.java:jboss/jdbc/fai-bfsa: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/jdbc/fai-bfsa: JBAS010433: Error during the deployment of fai-bfsa
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:131)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010432: Unable to start the ds because it generated more than one cf
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:126)
> ... 5 more
> 14:33:00,242 INFO [org.jboss.as.controller] (XNIO-4 task-2) JBAS014774: Servicestatus report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.data-source.reference-factory.fai-bfsa (missing) dependents:[service jboss.naming.context.java.jboss.jdbc.fai-bfsa]
> service jboss.data-source-config.fai-bfsa (missing) dependents: [service jboss.data-source.java:jboss/jdbc/fai-bfsa]
> JBAS014777: Services which failed to start: service jboss.data-source.java:jboss/jdbc/fai-bfsa
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (WFLY-3274) connector values are not available like "requestCount , maxTime, bytesReceived etc " in wildfly (domain mode) 8.0.0.Final
by Rituraj Sinha (JIRA)
[ https://issues.jboss.org/browse/WFLY-3274?page=com.atlassian.jira.plugin.... ]
Rituraj Sinha commented on WFLY-3274:
-------------------------------------
Thanks Jaikiran for replying i am getting the below while running the include-runtime
http-listener=default] :read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"allow-encoded-slash" => false,
"always-set-keep-alive" => true,
"buffer-pipelined-data" => true,
"buffer-pool" => "default",
"certificate-forwarding" => false,
"decode-url" => true,
"enabled" => true,
"max-buffered-request-size" => 16384,
"max-cookies" => 200,
"max-header-size" => 51200,
"max-headers" => 200,
"max-parameters" => 1000,
"max-post-size" => 10485760L,
"proxy-address-forwarding" => false,
"record-request-start-time" => false,
"redirect-socket" => "https",
"socket-binding" => "http",
"url-charset" => "UTF-8",
"worker" => "default"
}
}
it doesn't contain the value we are looking for ...
> connector values are not available like "requestCount , maxTime, bytesReceived etc " in wildfly (domain mode) 8.0.0.Final
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3274
> URL: https://issues.jboss.org/browse/WFLY-3274
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Rituraj Sinha
> Assignee: Tomaz Cerar
>
> while using jboss 7.2.0 we were able to fetch above values from the cli command as
> {noformat}
> [domain@test.com:9999 subsystem=web] ls
> configuration valve default-virtual-server=default-host native=false
> connector virtual-server instance-id=${jboss.node.name}
> [domain@test.com:9999 connector] ls
> ajp http
> [domain@test.com:9999 connector] cd http
> [domain@test.com:9999 connector] pwd
> /profile=ha/subsystem=web/connector=http
> [domain@test.com:9999 connector=http] ls
> configuration max-connections=undefined proxy-port=undefined
> ssl max-post-size=2097152 redirect-port=443
> bytesReceived= max-save-post-size=4096 requestCount=
> bytesSent= maxTime= scheme=http
> enable-lookups=false name=http secure=false
> enabled=true processingTime= socket-binding=http
> errorCount= protocol=HTTP/1.1 virtual-server=undefined
> executor=undefined proxy-name=undefined
> {noformat}
>
> Now we have moved to wildfly8 and trying to look for the same values in underetow( as there is no "web" subsystem in wildfly8)
> as below
> {noformat}
> [domain@test2.com:9990 subsystem=undertow] ls
> buffer-cache server default-servlet-container=default statistics-enabled=false (Here there is no connector attribute available as this was in jboss 7.2.0 )
> configuration servlet-container default-virtual-host=default-host
> error-page default-server=default-server instance-id=${jboss.node.name}
> {noformat}
>
> but the listners(HTTP, AJP and HTTPS ) are defined in the server attribute...hence going into server attribute we get the below as
> {noformat}
> [domain@test2.com:9990 server=default-server] ls
> ajp-listener host http-listener https-listener default-host=default-host servlet-container=default
> {noformat}
> after getting into http-listener we get the below
> {noformat}
> [domain@test2.com:9990 http-listener=default] ls
> allow-encoded-slash=false certificate-forwarding=false max-cookies=200 max-post-size=10485760 socket-binding=http
> always-set-keep-alive=true decode-url=true max-header-size=51200 proxy-address-forwarding=false url-charset=UTF-8
> buffer-pipelined-data=true enabled=true max-headers=200 record-request-start-time=false worker=default
> buffer-pool=default max-buffered-request-size=16384 max-parameters=1000 redirect-socket=https
> {noformat}
>
> Can someone please look into it ..?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3288:
----------------------------------------
That could be very interested, won't go into too much detail in this Jira as it is not directly related shortly I am switching to the SSL related tasks we have outstanding including the out of the box enablement we talked about in Brno - managing an embedded instance could be useful there as well to get it all op based.
I can see this task may end up coming back my way combined with the other stuff ;-)
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3288:
----------------------------------------
Yes, that's possible. My main concern though is the CLI is a remote tool and one that can manage a domain, so if it does something that won't work remotely or with a domain it should not involve a random end user experience the way the current "module" commands do.
If the regular management API would support updating these properties files, then the CLI could just add high level wrappers over those low level ops. That would be great. But if we *also* drop the existing add-user.sh scripts and only support the CLI, then the user has to launch a server process (perhaps in --admin-only) in order to manipulate users. That's annoying.
One thing I've been thinking about for this kind of problem is being able to launch an embedded AS inside the CLI. This could handle any sort of initial configuration task. The user instead of doing -c on the command line or "connect" in the shell uses "embed" or something, with appropriate other params. The CLI launches an embedded AS and connects via a non-remoting based interface. Thereafter the commands are the same as if the server was remote.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-329:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1078146, https://bugzilla.redhat.com/show_bug.cgi?id=1091383 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1078146)
> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
> Key: DROOLS-329
> URL: https://issues.jboss.org/browse/DROOLS-329
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 6.0.0.CR5
> Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
> Reporter: Marek Posolda
> Assignee: Mark Proctor
> Fix For: 5.5.1.Final, 6.1.0.Final
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main... )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> 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:483)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> ... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> ... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3288:
----------------------------------------
Maybe the CLI could support plug-in modules of some sort so if add-user is available it can 'expose' it. But that is probably heading more into general plans for the CLI.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3288:
----------------------------------------
For anyone looking into this, re: using the CLI for this functionality, that's fine so long as it does not create a requirement for the CLI to have access to the server filesystem. We already made that mistake with the "module" commands in the CLI.
It's even possible we could relax my constraint above re: CLI access to the server filesystem, but that will need to be done as part of general change with a broader discussion so we can iron out how to make it clear to users what the semantics are.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-3288:
--------------------------------------
Summary: Update add-user to use AESH or move it into the CLI
Key: WFLY-3288
URL: https://issues.jboss.org/browse/WFLY-3288
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management, Scripts
Reporter: Darran Lofthouse
Assignee: Brian Stansberry
Fix For: Awaiting Volunteers
Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
Switching to AESH would allow us to use the implementation there to handle this.
Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
Overall this is going to require further discussion so the comments here are just a starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-3288:
--------------------------------------
Assignee: (was: Brian Stansberry)
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (WFLY-3268) Stabilize intermittently failing clustering tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3268?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3268:
--------------------------------------
Ok so, closing the contexts seems pretty effective in stabilizing these.
> Stabilize intermittently failing clustering tests
> -------------------------------------------------
>
> Key: WFLY-3268
> URL: https://issues.jboss.org/browse/WFLY-3268
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 8.1.0.Final
>
>
> Some of the clustering tests
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulTimeoutTestCase(SYNC-tcp).timeout
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).nestedBeanFailover
> org.jboss.as.test.clustering.cluster.singleton.SingletonTestCase(SYNC-tcp).testSingletonService
> are failing due to OOM
> ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread-4) ISPN000230: Failed to start rebalance for cache default-host/stateful-failover: java.lang.OutOfMemoryError: unable to create new native thread
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months