[JBoss JIRA] (JBVFS-197) VFSUtils#getVirtualURL requires permissions
by David Lloyd (JIRA)
David Lloyd created JBVFS-197:
---------------------------------
Summary: VFSUtils#getVirtualURL requires permissions
Key: JBVFS-197
URL: https://issues.jboss.org/browse/JBVFS-197
Project: JBoss VFS
Issue Type: Bug
Affects Versions: 3.2.6.Final
Reporter: David Lloyd
Assignee: Tomaz Cerar
The {{org.jboss.vfs.VFSUtils#getVirtualURL(VirtualFile)}} method requires the permission {{java.net.NetPermission" specifyStreamHandler"}}. Therefore the URL construction should be in a privileged block.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (DROOLS-604) Problems in code generation and parsing when a method is called from Guided Rules Editor
by Abel Marrero Santos (JIRA)
[ https://issues.jboss.org/browse/DROOLS-604?page=com.atlassian.jira.plugin... ]
Abel Marrero Santos updated DROOLS-604:
---------------------------------------
Description:
I have found a problem in code generation when we use the feature "call a method on <variable>" from the Guided Rule Editor. An InvocationTargetException caused by a ClassCastException is thrown in RuleModelDRLPersistenceImpl.generateSetMethodCallsMethod method.
I have found other issues that I think are related and that I will try to mention in the comments. I can also provide you with the maven artifact that I'm using.
was:
Hello guys,
I have found a problem in code generation when we use the feature "call a method on <variable>" from the Guided Rule Editor. An InvocationTargetException caused by a ClassCastException is thrown in RuleModelDRLPersistenceImpl.generateSetMethodCallsMethod method.
I have found other issues that I think are related and that I will try to mention in the comments. I can also provide you with the maven artifact that I'm using.
> Problems in code generation and parsing when a method is called from Guided Rules Editor
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-604
> URL: https://issues.jboss.org/browse/DROOLS-604
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1, 6.2.0.Beta2
> Reporter: Abel Marrero Santos
> Assignee: Mark Proctor
> Priority: Critical
> Attachments: model-base-0.0.1-SNAPSHOT.jar
>
>
> I have found a problem in code generation when we use the feature "call a method on <variable>" from the Guided Rule Editor. An InvocationTargetException caused by a ClassCastException is thrown in RuleModelDRLPersistenceImpl.generateSetMethodCallsMethod method.
> I have found other issues that I think are related and that I will try to mention in the comments. I can also provide you with the maven artifact that I'm using.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on WFLY-1067:
--------------------------------
Also note that we have customers which use multiple AUTH protocols in the same stack, e.g. X.509 and IP based authentication. In such a case, JGroups requires different IDs in the AUTH protocols, e.g.
{code:xml}
<AUTH ..../>
<AUTH id="3560" .../>
{code}
Wildfly therefore possibly needs to generate a unique ID to be used by JGroups.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-1951) ha-singleton ElectionPolicy breaks ha-singleton access on deferred startup of second node
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-1951?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-1951:
-------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
> ha-singleton ElectionPolicy breaks ha-singleton access on deferred startup of second node
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-1951
> URL: https://issues.jboss.org/browse/WFLY-1951
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Remoting
> Affects Versions: 8.0.0.Alpha4
> Reporter: Thomas Frühbeck
> Assignee: Richard Achmatowicz
>
> We want to use an election policy for ha-singleton service (SortedElectionPolicy with NamePreference).
> To assure, that only the singleton on the preferred node is accessed we also use a DeploymentNodeSelector implementing same preference.
> If the second node is started _after_ the first node is in full operation, the ClientContext is not notified of the existence of another node, and does not get the possibility to select the desired node according to cluster policy:
> Node "storage" in full operation:
> 07:32:30,006 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 3) SELECTOR [storage]
> 07:32:30,027 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 3) SELECTOR [storage]
> Node "NodeB" startup:
> 07:32:35,045 INFO [at.tfr.test.ClusterClient] (EJB default - 2) Service: Proxy for remote EJB StatelessEJBLocator{appName='', moduleName='wildfly-cluster', distinctName='', beanName='ClusterBean', view='interface at.tfr.test.ClusterRemote'}
> 07:32:35,048 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 2) SELECTOR [NodeB, storage]
> Node "storage": NodeSelector still sees only "storage"
> 07:32:35,009 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 4) SELECTOR [storage]
> 07:32:35,011 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 4) SELECTOR [storage]
> If the ElectionPolicy now selected a node other than the currently active one ("NodeB" in this case), the access to the ha-singleton will fail, because "NodeB" is not selectable.
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-2330) Test set org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails with NPE
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-2330?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-2330.
------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Out of Date
> Test set org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails with NPE
> --------------------------------------------------------------------------------------
>
> Key: WFLY-2330
> URL: https://issues.jboss.org/browse/WFLY-2330
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Environment: Oracle JDK 1.7.0_45 on Solaris SPARC on SunBlade 2000.
> Reporter: Frank Langelage
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
> Attachments: org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp-output.txt, org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp.txt, TEST-org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp.xml
>
>
> Test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails for me because of a NPE.
> See attached log files of this test.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1067 at 9/29/14 11:44 AM:
---------------------------------------------------------------------
At the clustering meeting last week, given that there are now three possible security protocol layers (AUTH, ENCRYPT, SASL), we proposed introducing a new child-type:
{noformat}
<stack name="udp">
<transport type="UDP" socket-binding="jgroups-udp"/>
<protocol type="PING"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<security-protocol type="AUTH" mech="DIGEST" realm="JGroupsRealm"/>
<security-protocol type="ENCRYPT" mech="Client-CERT" realm="JGroupsRealm"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
{noformat}
If there were further configuration required for any security protocol which was not made available via the realm, this could be provided as properties as usual.
In the case of providing a secret key to TP for probe, a realm attribute could be added to the transport child to handle that case.
was (Author: rachmato):
At the clustering meeting last week, given that there are now three possible security protocol layers, we proposed introducing a new child-type:
{noformat}
<stack name="udp">
<transport type="UDP" socket-binding="jgroups-udp"/>
<protocol type="PING"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<security-protocol type="AUTH" mech="DIGEST" realm="JGroupsRealm"/>
<security-protocol type="ENCRYPT" mech="Client-CERT" realm="JGroupsRealm"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
{noformat}
In the case of providing a secret key to TP for probe, a realm attribute could be added to the transport child to handle that case.
If there were further configuration required for any security protocol which was not made available via the realm, this could be provided as properties as usual.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1067:
-------------------------------------------
It's also worth mentioning that there are certain authentication mechanisms which appear in JGroups and have no counterpart in the idea of realms. For example, authentication based on IP membership lists (you have to be in the list to be able to join) or regular expression constraints on IP addresses (your IP address has to match the regexp to be able to join). Not sure what the approach would be here: forgo the realm and just specify properties, or extend the realm to cater to the new configuration data.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1067:
-------------------------------------------
At the clustering meeting last week, given that there are now three possible security protocol layers, we proposed introducing a new child-type:
{noformat}
<stack name="udp">
<transport type="UDP" socket-binding="jgroups-udp"/>
<protocol type="PING"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<security-protocol type="AUTH" mech="DIGEST" realm="JGroupsRealm"/>
<security-protocol type="ENCRYPT" mech="Client-CERT" realm="JGroupsRealm"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
{noformat}
In the case of providing a secret key to TP for probe, a realm attribute could be added to the transport child to handle that case.
If there were further configuration required for any security protocol which was not made available via the realm, this could be provided as properties as usual.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months