[JBoss JIRA] (AS7-6605) Replicating JNDI tree to another server
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-6605?page=com.atlassian.jira.plugin.s... ]
David Lloyd updated AS7-6605:
-----------------------------
Priority: Major (was: Critical)
> Replicating JNDI tree to another server
> ----------------------------------------
>
> Key: AS7-6605
> URL: https://issues.jboss.org/browse/AS7-6605
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Naming
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Miroslav Novak
> Assignee: Eduardo Martins
>
> Description of problem:
> This use case is taken from one of our user which we were able to handle using HA-JNDI in EAP 5:
> 1. JMS Client will create Context with two URL (node1, node2) (java.naming.provider.url property)
> 2. For some reason client is connected to node2 first which will have no JMS admin objects registered in JNDI (this happens when this node is configured as HornetQ backup)
> 3. Node2 has replicated JNDI tree from node1. So connection factory will connect client to node1 and queue/topics are deployed on node1.
> Can be this functionality provided in EAP 6, please?
--
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
11 years, 2 months
[JBoss JIRA] (AS7-6808) Auto ignore domain resources on a slave HC which do not affect its servers
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/AS7-6808?page=com.atlassian.jira.plugin.s... ]
Kabir Khan updated AS7-6808:
----------------------------
Assignee: Kabir Khan
Fix Version/s: 8.0.0.Alpha1
Component/s: Domain Management
> Auto ignore domain resources on a slave HC which do not affect its servers
> --------------------------------------------------------------------------
>
> Key: AS7-6808
> URL: https://issues.jboss.org/browse/AS7-6808
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.0.0.Alpha1
>
>
> Currently to avoid receiving resources and ops for parts of the domain model which do not work on an older slave we use <ignored-resources> in the slave host.xml to ignore them.
> Instead we should only pull in parts of the domain model that is actually required on the slave for its servers to start. Once started we need to be able to update the slave with domain information as the config changes
> The main things which can change affecting the data required are:
> 1) A domain's server-group, where the profile (and thus extensions) and the socket-binding group can be changed.
> 2) A host's server-config, where the server-group and the socket-binding-group override might be changed.
> For 1) we can piggy-back missing data to the slave.
> For 2) the slave needs to connect back to the DC, attempt to get the DC lock and pull down the required data. If the lock cannot be obtained, the operation should fail fast.
--
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
11 years, 2 months
[JBoss JIRA] (AS7-6779) AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/AS7-6779?page=com.atlassian.jira.plugin.s... ]
Rob Stryker updated AS7-6779:
-----------------------------
Attachment: AS7-6779.out2.txt
When run with eap6.1 jars against as7.0.1, I do not get a 'freeze', but I do get a lot of stack traces in the output and a failure of the tests. I also get a connection reset.
Attaching sysout + syserr.
> AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
> ---------------------------------------------------------------------
>
> Key: AS7-6779
> URL: https://issues.jboss.org/browse/AS7-6779
> Project: Application Server 7
> Issue Type: Bug
> Components: Remoting
> Reporter: Rob Stryker
> Assignee: Emanuel Muckenhuber
> Priority: Blocker
> Attachments: AS7-6779.out2.txt, AS7-6779.stack.txt, out.zip
>
>
> Somewhere along the line recently, EAP6.1 / AS 7.2 has a regression in remoting or xnio somehow, and this is causing blocking problems for tools.
> Recall:
> 1) JBossTools bundles a set of jars capable of communicating with a running application server
> 2) This single set of jars must be capable of communicating with all servers in the 7.x stream
> 3) Bundling a second set of jars is not easily accomplished, but could be possible
> And:
> 4) Using the as7.1.0 jars against eap6.1 in a specific unit test causes eclipse to hang
> The basic code of our test case (once we get rid of the jbt stuff wrapped around it) is basically as follows:
> {code}
> this.client = ModelControllerClient.Factory.create(details.getHost(), details.getManagementPort(),
> getCallbackHandler());
> this.manager = ServerDeploymentManager.Factory.create(client);
> DeploymentPlanBuilder builder = manager.newDeploymentPlan().replace(name, file);
> try {
> DeploymentAction action = builder.getLastAction();
> Future<ServerDeploymentPlanResult> planResult = manager.execute(builder.build());
> // FREEZE HERE
> // This is "DeploymentOperationResult.getStatus() in the stack trace
> ServerDeploymentActionResult actionResult = planResult.get().getDeploymentActionResult(action.getId());
> IStatus status = createStatus(action.getDeploymentUnitUniqueName(), action.getType().name(), actionResult);
> } catch (Exception e) {
> throw new JBoss7ManangerException(e);
> }
> {code}
> The actual stack trace is:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=461)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=462)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 363
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 317
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerIntegrationTest.canReplaceWar() line: 129
> {code}
> The list of jars we are using to communicate with the server are:
> {code}
> jboss-as-controller-client-7.1.0.Final.jar
> jboss-as-protocol-7.1.0.Final.jar
> jboss-dmr-1.1.1.Final.jar
> jboss-logging-3.1.0.GA.jar
> jboss-marshalling-1.3.9.GA.jar
> jboss-remoting-3.2.7.GA.jar
> jboss-sasl-1.0.0.Final.jar
> jboss-threads-2.0.0.GA.jar
> xnio-api-3.0.3.GA.jar
> xnio-nio-3.0.3.GA.jar
> {code}
> It was suggested in irc by ctomc that we simply replace the following jars with new jars from jboss-as 7.2 / eap6.1:
> {code}
> jboss-remoting-3.2.7.GA.jar -> 3.2.15.GA
> xnio-api-3.0.3.GA.jar -> 3.0.7
> xnio-nio-3.0.3.GA.jar -> 3.0.7
> {code}
> This approach also failed, with the following stack trace:
> {code}
> java.lang.NoClassDefFoundError: org/xnio/Cancellable
> (sic)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:59)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:211)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:173)
> {code}
> So it is obvious that jboss-as-controller jar from as-7.1 requires classes that are no longer present in xnio. If this is the case, it would indicate that xnio has REMOVED classes from its jar during an incremental version from 3.0.3 to 3.0.7, which would constitute an API breakage.
> So clearly for us, updating only remoting and xnio does not work. The next possible solution would be to update ALL jars, however, this led to a similar situation when using AS7.2 / Eap 6.1 jars to communicate with an AS 7.0.0 server. Again, similar to what was mentioned above, all tests passed EXCEPT the test above. The test above failed with an almost identical stack trace:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=160)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=161)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture(AbstractDelegatingAsyncFuture<T>).get() line: 100
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerTestUtils.quietlyUndeploy(String, AS71Manager) line: 76
> AS7ManagerIntegrationTest.canReplaceWar() line: 135
> {code}
> No matter how you look at it, the contract has been broken. JBossTools now is looking for a specific set of jars which care capable of communicating with AS7.0, 7.1, 7.2, eap6.0, 6.1, jpp6.0, etc. Without a set of jars that can communicate with all of these servers, our tools will need to implement drastic workarounds or bundle several versions of the app server's jars within it.
> It's interesting to me that the as7.1 jars work against everything except eap6.1, and yet, the eap6.1 jars work against everything except as7.0.0.
--
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
11 years, 2 months
[JBoss JIRA] (AS7-6808) Auto ignore domain resources on a slave HC which do not affect its servers
by Kabir Khan (JIRA)
Kabir Khan created AS7-6808:
-------------------------------
Summary: Auto ignore domain resources on a slave HC which do not affect its servers
Key: AS7-6808
URL: https://issues.jboss.org/browse/AS7-6808
Project: Application Server 7
Issue Type: Feature Request
Reporter: Kabir Khan
Currently to avoid receiving resources and ops for parts of the domain model which do not work on an older slave we use <ignored-resources> in the slave host.xml to ignore them.
Instead we should only pull in parts of the domain model that is actually required on the slave for its servers to start. Once started we need to be able to update the slave with domain information as the config changes
The main things which can change affecting the data required are:
1) A domain's server-group, where the profile (and thus extensions) and the socket-binding group can be changed.
2) A host's server-config, where the server-group and the socket-binding-group override might be changed.
For 1) we can piggy-back missing data to the slave.
For 2) the slave needs to connect back to the DC, attempt to get the DC lock and pull down the required data. If the lock cannot be obtained, the operation should fail fast.
--
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
11 years, 2 months
[JBoss JIRA] (AS7-6779) AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/AS7-6779?page=com.atlassian.jira.plugin.s... ]
Rob Stryker updated AS7-6779:
-----------------------------
Attachment: AS7-6779.stack.txt
Attaching a jstack of the process. I am not seeing what you are expecting.
This stack is what I see when using 7.1 jars against eap6.1.
> AS7.1 jars run against as7.2/eap6.1 cause test case (eclipse) to hang
> ---------------------------------------------------------------------
>
> Key: AS7-6779
> URL: https://issues.jboss.org/browse/AS7-6779
> Project: Application Server 7
> Issue Type: Bug
> Components: Remoting
> Reporter: Rob Stryker
> Assignee: Emanuel Muckenhuber
> Priority: Blocker
> Attachments: AS7-6779.stack.txt, out.zip
>
>
> Somewhere along the line recently, EAP6.1 / AS 7.2 has a regression in remoting or xnio somehow, and this is causing blocking problems for tools.
> Recall:
> 1) JBossTools bundles a set of jars capable of communicating with a running application server
> 2) This single set of jars must be capable of communicating with all servers in the 7.x stream
> 3) Bundling a second set of jars is not easily accomplished, but could be possible
> And:
> 4) Using the as7.1.0 jars against eap6.1 in a specific unit test causes eclipse to hang
> The basic code of our test case (once we get rid of the jbt stuff wrapped around it) is basically as follows:
> {code}
> this.client = ModelControllerClient.Factory.create(details.getHost(), details.getManagementPort(),
> getCallbackHandler());
> this.manager = ServerDeploymentManager.Factory.create(client);
> DeploymentPlanBuilder builder = manager.newDeploymentPlan().replace(name, file);
> try {
> DeploymentAction action = builder.getLastAction();
> Future<ServerDeploymentPlanResult> planResult = manager.execute(builder.build());
> // FREEZE HERE
> // This is "DeploymentOperationResult.getStatus() in the stack trace
> ServerDeploymentActionResult actionResult = planResult.get().getDeploymentActionResult(action.getId());
> IStatus status = createStatus(action.getDeploymentUnitUniqueName(), action.getType().name(), actionResult);
> } catch (Exception e) {
> throw new JBoss7ManangerException(e);
> }
> {code}
> The actual stack trace is:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=461)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=462)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 363
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get() line: 317
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerIntegrationTest.canReplaceWar() line: 129
> {code}
> The list of jars we are using to communicate with the server are:
> {code}
> jboss-as-controller-client-7.1.0.Final.jar
> jboss-as-protocol-7.1.0.Final.jar
> jboss-dmr-1.1.1.Final.jar
> jboss-logging-3.1.0.GA.jar
> jboss-marshalling-1.3.9.GA.jar
> jboss-remoting-3.2.7.GA.jar
> jboss-sasl-1.0.0.Final.jar
> jboss-threads-2.0.0.GA.jar
> xnio-api-3.0.3.GA.jar
> xnio-nio-3.0.3.GA.jar
> {code}
> It was suggested in irc by ctomc that we simply replace the following jars with new jars from jboss-as 7.2 / eap6.1:
> {code}
> jboss-remoting-3.2.7.GA.jar -> 3.2.15.GA
> xnio-api-3.0.3.GA.jar -> 3.0.7
> xnio-nio-3.0.3.GA.jar -> 3.0.7
> {code}
> This approach also failed, with the following stack trace:
> {code}
> java.lang.NoClassDefFoundError: org/xnio/Cancellable
> (sic)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:59)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:211)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:173)
> {code}
> So it is obvious that jboss-as-controller jar from as-7.1 requires classes that are no longer present in xnio. If this is the case, it would indicate that xnio has REMOVED classes from its jar during an incremental version from 3.0.3 to 3.0.7, which would constitute an API breakage.
> So clearly for us, updating only remoting and xnio does not work. The next possible solution would be to update ALL jars, however, this led to a similar situation when using AS7.2 / Eap 6.1 jars to communicate with an AS 7.0.0 server. Again, similar to what was mentioned above, all tests passed EXCEPT the test above. The test above failed with an almost identical stack trace:
> {code}
> Thread [main] (Suspended)
> owns: RunnableLock (id=160)
> waiting for: ActiveOperationSupport$ActiveOperationImpl<T,A> (id=161)
> Object.wait(long) line: not available [native method]
> ActiveOperationSupport$ActiveOperationImpl<T,A>(Object).wait() line: 503
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).await() line: 192
> ActiveOperationSupport$ActiveOperationImpl<T,A>(AsyncFutureTask<T>).get() line: 266
> AbstractModelControllerClient$DelegatingCancellableAsyncFuture(AbstractDelegatingAsyncFuture<T>).get() line: 100
> ServerDeploymentPlanResultFuture.get() line: 76
> ServerDeploymentPlanResultFuture.get() line: 42
> DeploymentOperationResult.getStatus() line: 52
> AS7ManagerTestUtils.waitUntilFinished(IJBoss7DeploymentResult) line: 93
> AS7ManagerTestUtils.quietlyUndeploy(String, AS71Manager) line: 76
> AS7ManagerIntegrationTest.canReplaceWar() line: 135
> {code}
> No matter how you look at it, the contract has been broken. JBossTools now is looking for a specific set of jars which care capable of communicating with AS7.0, 7.1, 7.2, eap6.0, 6.1, jpp6.0, etc. Without a set of jars that can communicate with all of these servers, our tools will need to implement drastic workarounds or bundle several versions of the app server's jars within it.
> It's interesting to me that the as7.1 jars work against everything except eap6.1, and yet, the eap6.1 jars work against everything except as7.0.0.
--
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
11 years, 2 months
[JBoss JIRA] (AS7-6426) Jboss-cli crashes on Windows on backslash in history
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6426?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6426:
----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> changed the Status of [bug 920344|https://bugzilla.redhat.com/show_bug.cgi?id=920344] from ON_QA to VERIFIED
> Jboss-cli crashes on Windows on backslash in history
> ----------------------------------------------------
>
> Key: AS7-6426
> URL: https://issues.jboss.org/browse/AS7-6426
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: Windows 7, 64-bit
> Reporter: Jarkko Rantavuori
> Assignee: Ståle Pedersen
> Fix For: 8.0.0.Alpha1
>
>
> Note: seems to apply to latest snapshot only, not to 7.1.1.
> If you use a backslash in commands (like you need to use on absolute path deployments on windows) and then press up button to go back to that command, jboss-cli crashes with
> java.lang.NumberFormatException: For input string: "1B"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:492)
> at java.lang.Integer.<init>(Integer.java:677)
> at org.fusesource.jansi.AnsiOutputStream.write(AnsiOutputStream.java:120)
> at java.io.FilterOutputStream.write(FilterOutputStream.java:125)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.PrintWriter.flush(PrintWriter.java:320)
> at org.jboss.aesh.terminal.WindowsTerminal.writeToStdOut(WindowsTerminal.java:89)
> at org.jboss.aesh.console.Console.drawLine(Console.java:923)
> at org.jboss.aesh.console.Console.redrawLine(Console.java:902)
> at org.jboss.aesh.console.Console.getHistoryElement(Console.java:673)
> at org.jboss.aesh.console.Console.parseOperation(Console.java:476)
> at org.jboss.aesh.console.Console.read(Console.java:377)
> at org.jboss.aesh.console.Console.read(Console.java:331)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:171)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1181)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:259)
> 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:601)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
> Press any key to continue . . .
--
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
11 years, 2 months
[JBoss JIRA] (AS7-6426) Jboss-cli crashes on Windows on backslash in history
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6426?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6426:
----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> made a comment on [bug 920344|https://bugzilla.redhat.com/show_bug.cgi?id=920344]
Verified with EAP 6.1.0 ER3
> Jboss-cli crashes on Windows on backslash in history
> ----------------------------------------------------
>
> Key: AS7-6426
> URL: https://issues.jboss.org/browse/AS7-6426
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: Windows 7, 64-bit
> Reporter: Jarkko Rantavuori
> Assignee: Ståle Pedersen
> Fix For: 8.0.0.Alpha1
>
>
> Note: seems to apply to latest snapshot only, not to 7.1.1.
> If you use a backslash in commands (like you need to use on absolute path deployments on windows) and then press up button to go back to that command, jboss-cli crashes with
> java.lang.NumberFormatException: For input string: "1B"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:492)
> at java.lang.Integer.<init>(Integer.java:677)
> at org.fusesource.jansi.AnsiOutputStream.write(AnsiOutputStream.java:120)
> at java.io.FilterOutputStream.write(FilterOutputStream.java:125)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.PrintWriter.flush(PrintWriter.java:320)
> at org.jboss.aesh.terminal.WindowsTerminal.writeToStdOut(WindowsTerminal.java:89)
> at org.jboss.aesh.console.Console.drawLine(Console.java:923)
> at org.jboss.aesh.console.Console.redrawLine(Console.java:902)
> at org.jboss.aesh.console.Console.getHistoryElement(Console.java:673)
> at org.jboss.aesh.console.Console.parseOperation(Console.java:476)
> at org.jboss.aesh.console.Console.read(Console.java:377)
> at org.jboss.aesh.console.Console.read(Console.java:331)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:171)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1181)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:259)
> 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:601)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
> Press any key to continue . . .
--
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
11 years, 2 months
[JBoss JIRA] (SECURITY-662) Support Keystore type for PicketLinkVault implementation
by Anil Saldhana (JIRA)
[ https://issues.jboss.org/browse/SECURITY-662?page=com.atlassian.jira.plug... ]
Anil Saldhana updated SECURITY-662:
-----------------------------------
Summary: Support Keystore type for PicketLinkVault implementation (was: Support PKCS11/NSS within Security Vault)
Issue Type: Bug (was: Feature Request)
Assignee: Peter Skopek (was: Anil Saldhana)
Fix Version/s: PicketBox_4_0_16.Final
Component/s: JBossSX
We need to take an option for keystore type. Add a method to keystoreutil to get the right keystore with the keystore type as argument.
> Support Keystore type for PicketLinkVault implementation
> --------------------------------------------------------
>
> Key: SECURITY-662
> URL: https://issues.jboss.org/browse/SECURITY-662
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Reporter: Jess Sightler
> Assignee: Peter Skopek
> Fix For: PicketBox_4_0_16.Final
>
>
> The PicketBox Vault implementation assumes that it will always use the default keystore type (KeyStore.getDefaultType()). It would be nice if this were configurable/overridable. For example, via the system property:
> javax.net.ssl.keyStoreType
--
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
11 years, 2 months