[JBoss JIRA] (ELY-88) Command line utilities
by David Lloyd (JIRA)
David Lloyd created ELY-88:
------------------------------
Summary: Command line utilities
Key: ELY-88
URL: https://issues.jboss.org/browse/ELY-88
Project: WildFly Elytron
Issue Type: Feature Request
Reporter: David Lloyd
Assignee: Darran Lofthouse
We should provide easy-to-use command line tools from the Elytron JAR as a main class that provide useful functions to users like:
* Creating password hashes
* Creating certificates and certificate requests
* Creating key pairs of various types
* Managing key stores (everything keytool does)
* Get the library version
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (ELY-88) Command line utilities
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-88?page=com.atlassian.jira.plugin.sys... ]
David Lloyd updated ELY-88:
---------------------------
Assignee: (was: Darran Lofthouse)
> Command line utilities
> ----------------------
>
> Key: ELY-88
> URL: https://issues.jboss.org/browse/ELY-88
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: David Lloyd
>
> We should provide easy-to-use command line tools from the Elytron JAR as a main class that provide useful functions to users like:
> * Creating password hashes
> * Creating certificates and certificate requests
> * Creating key pairs of various types
> * Managing key stores (everything keytool does)
> * Get the library version
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-3938) Allow server to be named and display in admin console's title
by Paul Benedict (JIRA)
[ https://issues.jboss.org/browse/WFLY-3938?page=com.atlassian.jira.plugin.... ]
Paul Benedict commented on WFLY-3938:
-------------------------------------
Using "name" from <server> would be fine by me.
> Allow server to be named and display in admin console's title
> -------------------------------------------------------------
>
> Key: WFLY-3938
> URL: https://issues.jboss.org/browse/WFLY-3938
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Affects Versions: 8.1.0.Final
> Reporter: Paul Benedict
> Assignee: Heiko Braun
> Priority: Minor
>
> I frequently have several JBoss Management web consoles open for different environments. It's really not possible to look at my open browser windows and figure out which belongs to which environment.
> I would like to propose a new attribute in <server> that allows me to specify the title of the server. This title would display as part of the console's <title> tag in HTML. Then I can easily manage multiple consoles at once.
> Example:
> {code}
> <server name="daclient" xmlns="urn:jboss:domain:2.1" title="Localhost Development">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-3938) Allow server to be named and display in admin console's title
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-3938?page=com.atlassian.jira.plugin.... ]
Heiko Braun edited comment on WFLY-3938 at 10/6/14 1:43 PM:
------------------------------------------------------------
I can understand the use case and it make complete sense. But wouldn't the actual server name be sufficient? Why do you think do we need an extra title attribute?
was (Author: heiko.braun):
I can understand the use case and make complete sense. But wouldn't the actual server name be sufficient? Why do you think do we need an extra title attribute?
> Allow server to be named and display in admin console's title
> -------------------------------------------------------------
>
> Key: WFLY-3938
> URL: https://issues.jboss.org/browse/WFLY-3938
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Affects Versions: 8.1.0.Final
> Reporter: Paul Benedict
> Assignee: Heiko Braun
> Priority: Minor
>
> I frequently have several JBoss Management web consoles open for different environments. It's really not possible to look at my open browser windows and figure out which belongs to which environment.
> I would like to propose a new attribute in <server> that allows me to specify the title of the server. This title would display as part of the console's <title> tag in HTML. Then I can easily manage multiple consoles at once.
> Example:
> {code}
> <server name="daclient" xmlns="urn:jboss:domain:2.1" title="Localhost Development">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-3938) Allow server to be named and display in admin console's title
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-3938?page=com.atlassian.jira.plugin.... ]
Heiko Braun commented on WFLY-3938:
-----------------------------------
I can understand the use case and make complete sense. But wouldn't the actual server name be sufficient? Why do you think do we need an extra title attribute?
> Allow server to be named and display in admin console's title
> -------------------------------------------------------------
>
> Key: WFLY-3938
> URL: https://issues.jboss.org/browse/WFLY-3938
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Affects Versions: 8.1.0.Final
> Reporter: Paul Benedict
> Assignee: Heiko Braun
> Priority: Minor
>
> I frequently have several JBoss Management web consoles open for different environments. It's really not possible to look at my open browser windows and figure out which belongs to which environment.
> I would like to propose a new attribute in <server> that allows me to specify the title of the server. This title would display as part of the console's <title> tag in HTML. Then I can easily manage multiple consoles at once.
> Example:
> {code}
> <server name="daclient" xmlns="urn:jboss:domain:2.1" title="Localhost Development">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-3938) Allow server to be named and display in admin console's title
by Paul Benedict (JIRA)
Paul Benedict created WFLY-3938:
-----------------------------------
Summary: Allow server to be named and display in admin console's title
Key: WFLY-3938
URL: https://issues.jboss.org/browse/WFLY-3938
Project: WildFly
Issue Type: Feature Request
Components: Web Console
Affects Versions: 8.1.0.Final
Reporter: Paul Benedict
Assignee: Heiko Braun
Priority: Minor
I frequently have several JBoss Management web consoles open for different environments. It's really not possible to look at my open browser windows and figure out which belongs to which environment.
I would like to propose a new attribute in <server> that allows me to specify the title of the server. This title would display as part of the console's <title> tag in HTML. Then I can easily manage multiple consoles at once.
Example:
{code}
<server name="daclient" xmlns="urn:jboss:domain:2.1" title="Localhost Development">
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (DROOLS-626) collectList on objects of type java.lang.Class get returned as null
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-626?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-626.
--------------------------------
Labels: backport-to-6.0.x (was: )
Fix Version/s: 6.2.0.CR1
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/4458fd09f
> collectList on objects of type java.lang.Class get returned as null
> -------------------------------------------------------------------
>
> Key: DROOLS-626
> URL: https://issues.jboss.org/browse/DROOLS-626
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.Beta1
> Environment: Snapshot Drools 6.2.0.201410031437 runtime
> Reporter: David Fell
> Assignee: Mario Fusco
> Labels: backport-to-6.0.x
> Fix For: 6.2.0.CR1
>
>
> If collectList in an accumulate is supplied objects of type java.lang.Class, then subsequent examination of the supplied list yields null values rather than the expect Class values.
> Test case below. Swapping the comments to make InitClass have a String field instead of a Class field changes the behaviour of the list from collectList to what one would expect.
> package com.sample
> declare MyClass end
> declare InitClass
> clazz: Class @key
> // clazz: String @key
> end
> rule "init"
> when
> then
> insert( new InitClass( MyClass.class ) );
> // insert( new InitClass( "some string" ) );
> end
> rule "make init classes"
> when
> accumulate( InitClass( $clazz; ), $list: collectList( $clazz ) )
> then
> System.out.printf("%d items in list\n", $list.size());
> for(Object obj : $list)
> System.out.printf("item is %s\n", obj);
> end
> rule "show init classes"
> when
> InitClass( $v; )
> then
> System.out.printf("match %s\n", $v);
> end
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (DROOLS-626) collectList on objects of type java.lang.Class get returned as null
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-626?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-626:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> collectList on objects of type java.lang.Class get returned as null
> -------------------------------------------------------------------
>
> Key: DROOLS-626
> URL: https://issues.jboss.org/browse/DROOLS-626
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.Beta1
> Environment: Snapshot Drools 6.2.0.201410031437 runtime
> Reporter: David Fell
> Assignee: Mario Fusco
>
> If collectList in an accumulate is supplied objects of type java.lang.Class, then subsequent examination of the supplied list yields null values rather than the expect Class values.
> Test case below. Swapping the comments to make InitClass have a String field instead of a Class field changes the behaviour of the list from collectList to what one would expect.
> package com.sample
> declare MyClass end
> declare InitClass
> clazz: Class @key
> // clazz: String @key
> end
> rule "init"
> when
> then
> insert( new InitClass( MyClass.class ) );
> // insert( new InitClass( "some string" ) );
> end
> rule "make init classes"
> when
> accumulate( InitClass( $clazz; ), $list: collectList( $clazz ) )
> then
> System.out.printf("%d items in list\n", $list.size());
> for(Object obj : $list)
> System.out.printf("item is %s\n", obj);
> end
> rule "show init classes"
> when
> InitClass( $v; )
> then
> System.out.printf("match %s\n", $v);
> end
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFCORE-149) Failues in 'resolve-expression" op appear in server log
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-149?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-149:
-----------------------------------------
My theory about the logging happening because a cause was attached is incorrect. It's logged because it happens at Stage.RUNTIME. RUNTIME OFEs are logged as there is the potential they have disrupted the server.
Solution is to not throw the OFE but rather to use context.getFailureDescription() to report the failure to the client.
> Failues in 'resolve-expression" op appear in server log
> -------------------------------------------------------
>
> Key: WFCORE-149
> URL: https://issues.jboss.org/browse/WFCORE-149
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
>
> I happened to notice this in a server log:
> 11:53:48,854 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve-expression") failed - address: ([]) - failure description: "WFLYCTL0211: Cannot resolve expression 'expression \"${unresolvable}\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${unresolvable}"
> That failure shouldn't end up in the server log; it's just a client mistake unrelated to server operation.
> A guess is that it's logged because the OFE has the ISE attached as a cause, in which case a simple fix is to not attach the ISE, which adds no value.
> Note the handler has a catch block above the one that throws this OFE that handles a SecurityException case. In that case it *may* be appropriate for something to appear in the logs, assuming tracing how the SE can happen indicates it could be triggered by a user fishing for an exploit. In that case a direct WARN in the log from the ResolveExpressionHandler instead of attaching the SE to the OFE and letting the OperationContext log an ERROR may be more appropriate.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFCORE-149) Failues in 'resolve-expression" op appear in server log
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-149:
---------------------------------------
Summary: Failues in 'resolve-expression" op appear in server log
Key: WFCORE-149
URL: https://issues.jboss.org/browse/WFCORE-149
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Priority: Minor
I happened to notice this in a server log:
11:53:48,854 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve-expression") failed - address: ([]) - failure description: "WFLYCTL0211: Cannot resolve expression 'expression \"${unresolvable}\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${unresolvable}"
That failure shouldn't end up in the server log; it's just a client mistake unrelated to server operation.
A guess is that it's logged because the OFE has the ISE attached as a cause, in which case a simple fix is to not attach the ISE, which adds no value.
Note the handler has a catch block above the one that throws this OFE that handles a SecurityException case. In that case it *may* be appropriate for something to appear in the logs, assuming tracing how the SE can happen indicates it could be triggered by a user fishing for an exploit. In that case a direct WARN in the log from the ResolveExpressionHandler instead of attaching the SE to the OFE and letting the OperationContext log an ERROR may be more appropriate.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months