[JBoss JIRA] (WFCORE-1022) AliasEntry needs more information than just the PathAddress
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-1022:
----------------------------------
Summary: AliasEntry needs more information than just the PathAddress
Key: WFCORE-1022
URL: https://issues.jboss.org/browse/WFCORE-1022
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Kabir Khan
Assignee: Kabir Khan
Priority: Critical
Fix For: 2.0.0.CR6
As mentioned on https://issues.jboss.org/browse/WFLY-5290
[17:58] Kabir Khan: @PaulFerraro For https://issues.jboss.org/browse/WFLY-5290, what should the transport=TRANSPORT alias become?
[17:59] Paul Ferraro: @KabirKhan it becomes transport=*
[18:00] Kabir Khan: @PaulFerraro That can't map properly, it needs to map onto one resource
[18:00] Paul Ferraro: e.g. transport=TRANSPORT,type=UDP becomes transport=UDP
[18:00] Kabir Khan: ok, I see
in that case I can try to take a look
[18:01] Paul Ferraro: so - it needs more context than just the address
[18:01] Kabir Khan: and let me guess, that is not available at the moment from AliasEntry
[18:01] Paul Ferraro: right
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-5180) InfinispanResourceRefTestCase causes NameNotFoundException with security manager
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5180?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5180:
------------------------------------
I see - internally, we should be using a privileged action during construction of the cache components that require reflection.
> InfinispanResourceRefTestCase causes NameNotFoundException with security manager
> --------------------------------------------------------------------------------
>
> Key: WFLY-5180
> URL: https://issues.jboss.org/browse/WFLY-5180
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Paul Ferraro
>
> *Description of problem:*
> InfinispanResourceRefTestCase causes NameNotFoundException with security manager.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./build.sh -DskipTests -DallTests -Dts.noSmoke
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=InfinispanResourceRefTestCase
> *Actual results:*
> {noformat}
> javax.naming.NameNotFoundException: infinispan
> at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase.test(InfinispanResourceRefTestCase.java:64)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to freeze the UI
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-5290:
----------------------------------
[17:58] Kabir Khan: @PaulFerraro For https://issues.jboss.org/browse/WFLY-5290, what should the transport=TRANSPORT alias become?
[17:59] Paul Ferraro: @KabirKhan it becomes transport=*
[18:00] Kabir Khan: @PaulFerraro That can't map properly, it needs to map onto one resource
[18:00] Paul Ferraro: e.g. transport=TRANSPORT,type=UDP becomes transport=UDP
[18:00] Kabir Khan: ok, I see
in that case I can try to take a look
[18:01] Paul Ferraro: so - it needs more context than just the address
[18:01] Kabir Khan: and let me guess, that is not available at the moment from AliasEntry
[18:01] Paul Ferraro: right
> Adding JGroups stack seems to freeze the UI
> -------------------------------------------
>
> Key: WFLY-5290
> URL: https://issues.jboss.org/browse/WFLY-5290
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Domain Management
> Reporter: Jan Kašík
> Assignee: Kabir Khan
> Priority: Critical
> Fix For: 10.0.0.Final
>
>
> Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-5433) CommandDispatcher can throw InvalidClassException if command class is not available
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-5433:
----------------------------------
Summary: CommandDispatcher can throw InvalidClassException if command class is not available
Key: WFLY-5433
URL: https://issues.jboss.org/browse/WFLY-5433
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.CR2
Reporter: Paul Ferraro
Assignee: Paul Ferraro
When CommandDispatcher is used by a deployment, the command class might not be available if the deployment is not deployed. Normally, this is prevented by returning a NoSuchService response if the service is unknown, however, this happens *after* the command is unmarshalled. This check should happen before we attempt to unmarshall the command, avoiding unnecessary InvalidClassException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-5340) Unable to specify module when specifying custom JACC policy class.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5340:
-----------------------------------------------
Bartek Spyrko-Smietanko <bspyrkos(a)redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from ASSIGNED to POST
> Unable to specify module when specifying custom JACC policy class.
> ------------------------------------------------------------------
>
> Key: WFLY-5340
> URL: https://issues.jboss.org/browse/WFLY-5340
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Beta2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.CR1
>
>
> It is currently possible to specify the 'javax.security.jacc.policy.provider' system property, however it is not possible to specify a module.
> From the JACC specification: -
> _For each JRE of a J2EE 1.4 or later version Java EE application server, if the
> system property
> “javax.security.jacc.policy.provider
> ” is defined,
> the application server must construct an
> instance of the class identified by the
> system property, confirm that the
> resulting object is an instance of
> java.security.Policy,
> and set, by calling the
> java.security.Policy.setPolicy
> method, the resulting object as the
> corresponding Policy object u
> sed by the JRE. _
> The specification only specifies that the system property identifies the class, it does not specify how.
> In it's simplest form we should assume this is just a class name, in a more complex form we should allow the module to be specified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (JGRP-1844) Remove shared transport
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ]
Rich DiCroce commented on JGRP-1844:
------------------------------------
The situation I am in is that two applications share some Infinispan caches, but also have some of their own independent caches. The short explanation is that I have to create three separate cache managers (one shared, one for each application), each of which requires its own JGroups channel. Infinispan assumes that every node in the view is participating in the cache manager, which isn't true for the app-specific cache managers when using a fork channel.
That is arguably more of an Infinispan problem, and I'm going to file some issues in the Infinispan JIRA for those, but I don't know if or when those issues will ever be resolved. Shared transport is a useful workaround in the meantime. I also have my own fork channel that is used by only one of the two applications, and I need to be able to determine a coordinator within that subset of members. JGroups currently doesn't do anything to help with that, so instead of forking the channel that is shared by both applications, I'm forking the app-specific channel.
It would be nice if JGroups did something for applications using fork channels, so the application can easily determine which cluster members are participating in the fork. Alternatively, is it possible to put the FORK protocol lower in the stack, below the GMS protocol? Then forks would have their own separate views. I haven't tried that but I doubt it would work based on what I've read.
> Remove shared transport
> -----------------------
>
> Key: JGRP-1844
> URL: https://issues.jboss.org/browse/JGRP-1844
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-5340) Unable to specify module when specifying custom JACC policy class.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5340:
-----------------------------------------------
Bartek Spyrko-Smietanko <bspyrkos(a)redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from NEW to ASSIGNED
> Unable to specify module when specifying custom JACC policy class.
> ------------------------------------------------------------------
>
> Key: WFLY-5340
> URL: https://issues.jboss.org/browse/WFLY-5340
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Beta2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.CR1
>
>
> It is currently possible to specify the 'javax.security.jacc.policy.provider' system property, however it is not possible to specify a module.
> From the JACC specification: -
> _For each JRE of a J2EE 1.4 or later version Java EE application server, if the
> system property
> “javax.security.jacc.policy.provider
> ” is defined,
> the application server must construct an
> instance of the class identified by the
> system property, confirm that the
> resulting object is an instance of
> java.security.Policy,
> and set, by calling the
> java.security.Policy.setPolicy
> method, the resulting object as the
> corresponding Policy object u
> sed by the JRE. _
> The specification only specifies that the system property identifies the class, it does not specify how.
> In it's simplest form we should assume this is just a class name, in a more complex form we should allow the module to be specified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months