[JBoss JIRA] (WFCORE-2088) Enhance CLI to support Aesh Commands
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2088?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-2088:
-----------------------------------------
Description:
In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
The patch command should be a candidate to validate this integration of aesh commands.
was:
In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
> Enhance CLI to support Aesh Commands
> ------------------------------------
>
> Key: WFCORE-2088
> URL: https://issues.jboss.org/browse/WFCORE-2088
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
> The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
> The patch command should be a candidate to validate this integration of aesh commands.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (WFCORE-2088) Enhance CLI to support Aesh Commands
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2088?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-2088:
-----------------------------------------
Description:
In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
was:
This is the CLI.next project.
Aesh 1.0 will come with a Command API based on annotations. It makes full sense to redesign part of the existing commands, still offering backward compatibility using this API.
> Enhance CLI to support Aesh Commands
> ------------------------------------
>
> Key: WFCORE-2088
> URL: https://issues.jboss.org/browse/WFCORE-2088
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
> The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 10:48 AM:
-----------------------------------------------------------------------
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
Let us see how the fishing goes.
Many thanks.
was (Author: nuno.godinhomatos):
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
Many thanks.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
Many thanks.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ELY-1349) Incorrect doPrivileged usage causes AccessControlException (FilePermission) in Elytron's ServiceLoaderSupplier
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1349?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reassigned ELY-1349:
-------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Incorrect doPrivileged usage causes AccessControlException (FilePermission) in Elytron's ServiceLoaderSupplier
> --------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1349
> URL: https://issues.jboss.org/browse/ELY-1349
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.1.Final
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
>
> When application server is running with Security Manager then using Elytron API (ElytronXmlParser.parseAuthenticationClientConfiguration()) from deployment leads to AccessControlException. The ServiceLoaderSupplier incorrectly uses doPrivileged, so the FilePermission check during accessing Elytron JAR fails.
> Workaround could be adding this FilePermission to each such deployment, but this is neither safe nor practical as the JAR name and location can change (e.g. version upgrade with patches applied).
> It seems the problem is caused by passing AccessControlContext as second parameter of {{doPrivileged}} method [1]. {{ServiceLoaderSupplier}} does not require this permission when second paramater is removed from {{doPrivileged}} method. This privileged block has been added as fix of JBEAP-12111 - {{doPrivileged}} call has been added into {{org.wildfly.security.util.ServiceLoaderSupplier}}.
> For example this is stacktrace for calling {{ElytronXmlParser.parseAuthenticationClientConfiguration}} method from Servlet in war application:
> {code}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/user/jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-1.1.1.Final-redhat-1.jar" "read")" in code source "(vfs:/content/wildfly-config-xml-dep.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.wildfly-config-xml-dep.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350)
> at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1038)
> at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at org.wildfly.security.util.ServiceLoaderSupplier.loadServices(ServiceLoaderSupplier.java:73)
> at org.wildfly.security.util.ServiceLoaderSupplier.lambda$get$0(ServiceLoaderSupplier.java:58)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:58)
> at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:39)
> at org.wildfly.security.auth.client.ElytronXmlParser$DeferredSupplier.get(ElytronXmlParser.java:2433)
> at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:115)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseClearPassword$40(ElytronXmlParser.java:2001)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$27(ElytronXmlParser.java:918)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$23(ElytronXmlParser.java:895)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$33(ElytronXmlParser.java:953)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$18(ElytronXmlParser.java:691)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$23(ElytronXmlParser.java:895)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$23(ElytronXmlParser.java:895)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$22(ElytronXmlParser.java:739)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$7(ElytronXmlParser.java:575)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:599)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:299)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:176)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:137)
> ...
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/8c033958d78fcb1c...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-815?page=com.atlassian.jira.plugin.s... ]
Bela Ban edited comment on JGRP-815 at 8/31/17 7:41 AM:
--------------------------------------------------------
bla10: sender
bla9: receiver
was (Author: belaban):
bla10: receiver
bla9: sender
> Scatter/Gather to avoid copying
> -------------------------------
>
> Key: JGRP-815
> URL: https://issues.jboss.org/browse/JGRP-815
> Project: JGroups
> Issue Type: Sub-task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
> Attachments: bla10.java, bla9.java
>
>
> When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
> We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
> We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
> 1: Src and dest address plus flags, plus possibly size
> 2: The marshalled headers
> 3: The buffer passed to JGroups by the user
> We can obtain a gathering-write channel as follows:
> ByteBuffer[] buffers; // contains the 3 byte buffers above
> DatagramSocket sock;
> DatagramChannel ch=sock.getChannel();
> ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
> This is supported by a GatheringByteChannel.
> I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months