[JBoss JIRA] (WFCORE-2042) Improve query operation for nested child resources
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2042?page=com.atlassian.jira.plugi... ]
Lin Gao commented on WFCORE-2042:
---------------------------------
I still think that improving both +selector+ and +where+ to support nested resources/attributes will be a better way(but I probably be wrong), because for complex attributes with more than 2 levels, you can't specify it even using +from+ parameter without supporting nested attributes.
The +QueryOperationHandler.FilterReduceHandler+(QFH) will happen after +:read-resource+ operation, so I think it is actually a search inside of a ModelNode, we just need to find a proper way to get the desired result. :)
To make things clear, I [drafted a document|https://docs.google.com/a/redhat.com/document/d/18LVU8TxLQflppys...] to list the proposed requirements, [~michpetrov], would you please take a look and add your ideas there? :)
> Improve query operation for nested child resources
> --------------------------------------------------
>
> Key: WFCORE-2042
> URL: https://issues.jboss.org/browse/WFCORE-2042
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Lin Gao
>
> This is another similar RFE as WFCORE-2041.
> It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are +inside of nested child resources(not only by the first level of child resource)+, so that, for example, the following command can work well as expected:
> {code:}
> [standalone@localhost:9990 /] /subsystem=security:query(select=[security-domain], where={security-domain.authentication.login-modules.code=RealmDirect})
> {
> "outcome" => "success",
> "result" => undefined
> }
> // here the expected output are the security-domain resources which have the loging-module RealmDirect defined.
> {code}
> The {{security-domain.authentication.login-modules.code}} in 'where' parameter is proposed attribute name in enhanced syntax, other options maybe possible.
> The different requirements between this WFCORE-2042 and WFCORE-2041 are:
> * WFCORE-2041 focus on complex attributes in one management resource
> * WFCORE-2042 focus on nested management resources with or without complex attributes
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8906) Cache configuration services should start on-demand
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8906?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-8906:
-------------------------------
Description:
Most infinispan services are configured to start passively, for a couple reasons:
1. Infinispan requires its cache container to start when the associated JGroups channel is started.
2. Cache configurations should be installed when the cache container starts, so that calls to EmbeddedCacheManager.getCache(...) use the correct configuration.
There's not much we can do about #1, except maybe to allow non-clustered cache containers (i.e. those without a transport) to start on-demand, instead of passively. This is a little tricky currently, since the transport is a separate resource from the cache container, and is typically installed afterwards.
#2 isn't needed anymore, since applications can depend on a specific cache configuration via jndi resource references.
Therefore, cache configuration services (and the individual configuration components services) should start as on-demand. Additionally, many of these services reference a full ConfigurationBuilder object, which is pretty hefty, for the entire lifetime of the service (regardless of state). These can be optimized to create the requisite builders only when the corresponding service is started. This should help reduce WF's startup memory footprint, as cache configurations do not need to be installed on startup.
was:
Most infinispan services are configured to start passively, for a couple reasons:
1. Infinispan requires its cache container to start when the associated JGroups channel is started.
2. Cache configurations should be installed when the cache container starts, so that calls to EmbeddedCacheManager.getCache(...) use the correct configuration.
There's not much we can do about #1, except maybe to allow non-clustered cache containers (i.e. those without a transport) to start on-demand, instead of passively.
#2 isn't needed anymore, since applications can depend on a specific cache configuration via jndi resource references.
Therefore, cache configuration services (and the individual configuration components services) should start as on-demand. Additionally, many of these services reference a full ConfigurationBuilder object, which is pretty hefty, for the entire lifetime of the service (regardless of state). These can be optimized to create the requisite builders only when the corresponding service is started. This should help reduce WF's startup memory footprint, as cache configurations do not need to be installed on startup.
> Cache configuration services should start on-demand
> ---------------------------------------------------
>
> Key: WFLY-8906
> URL: https://issues.jboss.org/browse/WFLY-8906
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Most infinispan services are configured to start passively, for a couple reasons:
> 1. Infinispan requires its cache container to start when the associated JGroups channel is started.
> 2. Cache configurations should be installed when the cache container starts, so that calls to EmbeddedCacheManager.getCache(...) use the correct configuration.
> There's not much we can do about #1, except maybe to allow non-clustered cache containers (i.e. those without a transport) to start on-demand, instead of passively. This is a little tricky currently, since the transport is a separate resource from the cache container, and is typically installed afterwards.
> #2 isn't needed anymore, since applications can depend on a specific cache configuration via jndi resource references.
> Therefore, cache configuration services (and the individual configuration components services) should start as on-demand. Additionally, many of these services reference a full ConfigurationBuilder object, which is pretty hefty, for the entire lifetime of the service (regardless of state). These can be optimized to create the requisite builders only when the corresponding service is started. This should help reduce WF's startup memory footprint, as cache configurations do not need to be installed on startup.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8906) Cache configuration services should start on-demand
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8906?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-8906:
-------------------------------
Description:
Most infinispan services are configured to start passively, for a couple reasons:
1. Infinispan requires its cache container to start when the associated JGroups channel is started.
2. Cache configurations should be installed when the cache container starts, so that calls to EmbeddedCacheManager.getCache(...) use the correct configuration.
There's not much we can do about #1, except maybe to allow non-clustered cache containers (i.e. those without a transport) to start on-demand, instead of passively.
#2 isn't needed anymore, since applications can depend on a specific cache configuration via jndi resource references.
Therefore, cache configuration services (and the individual configuration components services) should start as on-demand. Additionally, many of these services reference a full ConfigurationBuilder object, which is pretty hefty, for the entire lifetime of the service (regardless of state). These can be optimized to create the requisite builders only when the corresponding service is started. This should help reduce WF's startup memory footprint, as cache configurations do not need to be installed on startup.
was:Most infinispan services are configured to start passively - since Infinispan requires its cache container to start when the associated JGroups channel is started. However, local cache containers (i.e. containing only local caches and no associated JGroups transport) do not have this limitation, and should thus start as on-demand. This should help reduce WF's startup memory footprint.
> Cache configuration services should start on-demand
> ---------------------------------------------------
>
> Key: WFLY-8906
> URL: https://issues.jboss.org/browse/WFLY-8906
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Most infinispan services are configured to start passively, for a couple reasons:
> 1. Infinispan requires its cache container to start when the associated JGroups channel is started.
> 2. Cache configurations should be installed when the cache container starts, so that calls to EmbeddedCacheManager.getCache(...) use the correct configuration.
> There's not much we can do about #1, except maybe to allow non-clustered cache containers (i.e. those without a transport) to start on-demand, instead of passively.
> #2 isn't needed anymore, since applications can depend on a specific cache configuration via jndi resource references.
> Therefore, cache configuration services (and the individual configuration components services) should start as on-demand. Additionally, many of these services reference a full ConfigurationBuilder object, which is pretty hefty, for the entire lifetime of the service (regardless of state). These can be optimized to create the requisite builders only when the corresponding service is started. This should help reduce WF's startup memory footprint, as cache configurations do not need to be installed on startup.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8906) Cache configuration services should start on-demand
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8906?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-8906:
-------------------------------
Summary: Cache configuration services should start on-demand (was: Cache containers w/out JGroups transport should start on-demand)
> Cache configuration services should start on-demand
> ---------------------------------------------------
>
> Key: WFLY-8906
> URL: https://issues.jboss.org/browse/WFLY-8906
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Most infinispan services are configured to start passively - since Infinispan requires its cache container to start when the associated JGroups channel is started. However, local cache containers (i.e. containing only local caches and no associated JGroups transport) do not have this limitation, and should thus start as on-demand. This should help reduce WF's startup memory footprint.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (LOGTOOL-101) Exception transformation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGTOOL-101:
---------------------------------------
If we add a parameter to the {{@Producer}} this might not be needed. Maybe something like {{@Producer(copyStackTrace=false}}, then the {{Function}} could just attempt to clone the exception.
{code:java}
@Message("Binding to %s failed")
<T extends IOException> T bindFailed(@Producer(copyStackTrace=false BiFunction<String, IOException, T> function, @Cause IOException cause, SocketAddress address);
throw ValidMessages.MESSAGES.bindFailed((msg, cause) -> {
final IOException copy;
if (cause instanceof BindException) {
copy = new BindException(msg + ": " + cause.getMessage());
} else {
copy = new IOException(msg + ": " + cause.getMessage());
}
copy.setStackTrace(cause.getStackTrace());
return copy;
}, new IOException("Failed IO exception"), address);
{code}
Note the {{copyStackTrace}} here refers to the reset of the stack trace removing the interface entry from the stack trace. A better name may be needed.
E.g the default implementation looks something like:
{code:java}
@Override
public final <T extends IOException> T bindFailed(final java.util.function.BiFunction<String, IOException, T> function, final IOException cause, final SocketAddress address) {
final T result = function.apply(String.format(getLoggingLocale(), bindFailed$str(), address), cause);
final StackTraceElement[] st = result.getStackTrace();
result.setStackTrace(Arrays.copyOfRange(st, 1, st.length));
return result;
}
{code}
So we'd just need property to indicate the resulting stack trace should not be set. Maybe {{setStackTrace=false}}?
> Exception transformation
> ------------------------
>
> Key: LOGTOOL-101
> URL: https://issues.jboss.org/browse/LOGTOOL-101
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 2.1.0.Alpha3
>
>
> I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine.
> Something like this:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause)
> {code}
> This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string.
> Note that I can almost do this now, except that there's no way to copy the exception stack:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause)
> {code}
> An alternative approach is to add an annotation for copying the stack trace:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause)
> {code}
> Note that in this case the original exception message is lost. The next variant would preserve the message:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2)
> {code}
> And now to eliminate the duplication:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause)
> {code}
> Note that I don't recall if @Pos is 1- or 0-based, so I guessed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8909) Disabled deployments in server group enabled after WAR is updated
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-8909?page=com.atlassian.jira.plugin.... ]
Matthew Casperson updated WFLY-8909:
------------------------------------
Steps to Reproduce:
Steps to reproduce:
1. Deploy WAR file to domain controller
2. Assign the WAR file to a server group, but disable it
3. Update the contents of the WAR file via the CLI tool without listing any server groups i.e. deploy --force myApp.war
4. Most of the time the deployment in the existing server group is enabled (it seems that very occasionally the deployment remains disabled)
I would not expect that updating the file in the content repository would enable a disabled deployment in a server group. Maybe this is the expected behaviour though?
was:
Steps to reproduce:
1. Deploy WAR file to domain controller
2. Assign the WAR file to a server group, but disable it
3. Update the contents of the WAR file via the CLI tool i.e. deploy --force myApp.war
4. Most of the time the deployment in the existing server group is enabled (it seems that very occasionally the deployment remains disabled)
I would not expect that updating the file in the content repository would enable a disabled deployment in a server group. Maybe this is the expected behaviour though?
> Disabled deployments in server group enabled after WAR is updated
> -----------------------------------------------------------------
>
> Key: WFLY-8909
> URL: https://issues.jboss.org/browse/WFLY-8909
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 11.0.0.Alpha1
> Environment: Centos 7
> OpenJDK
> Reporter: Matthew Casperson
> Assignee: Jason Greene
>
> Updating the contents of a WAR file in a domain controller content repository will usually lead to a disabled deployment in a server group being enabled.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8909) Disabled deployments in server group enabled after WAR is updated
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-8909?page=com.atlassian.jira.plugin.... ]
Matthew Casperson updated WFLY-8909:
------------------------------------
Steps to Reproduce:
Steps to reproduce:
1. Deploy WAR file to domain controller
2. Assign the WAR file to a server group, but disable it
3. Update the contents of the WAR file via the CLI tool i.e. deploy --force myApp.war
4. Most of the time the deployment in the existing server group is enabled (it seems that very occasionally the deployment remains disabled)
I would not expect that updating the file in the content repository would enable a disabled deployment in a server group. Maybe this is the expected behaviour though?
was:
Steps to reproduce:
1. Deploy WAR file to domain controller
2. Assign the WAR file to a server group, but disable it
3. Update the contents of the WAR file via the CLI tool i.e. deploy --force myApp.war
4. Most of the time the deployment in the existing server group is enabled (it seems that very occasionally the deployment remains disabled)
I would not expect that updating the file in the content repository would enable a disabled deployment in a server group.
> Disabled deployments in server group enabled after WAR is updated
> -----------------------------------------------------------------
>
> Key: WFLY-8909
> URL: https://issues.jboss.org/browse/WFLY-8909
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 11.0.0.Alpha1
> Environment: Centos 7
> OpenJDK
> Reporter: Matthew Casperson
> Assignee: Jason Greene
>
> Updating the contents of a WAR file in a domain controller content repository will usually lead to a disabled deployment in a server group being enabled.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8909) Disabled deployments in server group enabled after WAR is updated
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-8909?page=com.atlassian.jira.plugin.... ]
Matthew Casperson updated WFLY-8909:
------------------------------------
Description:
Updating the contents of a WAR file in a domain controller content repository will usually lead to a disabled deployment in a server group being enabled.
was:Updating the contents of a WAR file in a domain controller content repository will usually lead to a disabled deployment in a server group being enabled.
> Disabled deployments in server group enabled after WAR is updated
> -----------------------------------------------------------------
>
> Key: WFLY-8909
> URL: https://issues.jboss.org/browse/WFLY-8909
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 11.0.0.Alpha1
> Environment: Centos 7
> OpenJDK
> Reporter: Matthew Casperson
> Assignee: Jason Greene
>
> Updating the contents of a WAR file in a domain controller content repository will usually lead to a disabled deployment in a server group being enabled.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8909) Disabled deployments in server group enabled after WAR is updated
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-8909?page=com.atlassian.jira.plugin.... ]
Matthew Casperson updated WFLY-8909:
------------------------------------
Steps to Reproduce:
Steps to reproduce:
1. Deploy WAR file to domain controller
2. Assign the WAR file to a server group, but disable it
3. Update the contents of the WAR file via the CLI tool i.e. deploy --force myApp.war
4. Most of the time the deployment in the existing server group is enabled (it seems that very occasionally the deployment remains disabled)
I would not expect that updating the file in the content repository would enable a disabled deployment in a server group.
was:
Steps to reproduce:
1. Deploy WAR file to domain controller
2. Assign the WAR file to a server group, but disable it
3. Update the contents of the WAR file via the CLI tool i.e. deploy --force myApp.war
4. Most of the time the deployment in the existing server group is enabled (it seems that very occasionally the deployment remains disabled)
I would not expect that updating the file in the content repository would change the enable a disabled deployment in a server group.
> Disabled deployments in server group enabled after WAR is updated
> -----------------------------------------------------------------
>
> Key: WFLY-8909
> URL: https://issues.jboss.org/browse/WFLY-8909
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 11.0.0.Alpha1
> Environment: Centos 7
> OpenJDK
> Reporter: Matthew Casperson
> Assignee: Jason Greene
>
> Updating the contents of a WAR file in a domain controller content repository will usually lead to a disabled deployment in a server group being enabled.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month