[JBoss JIRA] (DROOLS-1303) OOPath reactive Collection coverage
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1303:
--------------------------------------
Summary: OOPath reactive Collection coverage
Key: DROOLS-1303
URL: https://issues.jboss.org/browse/DROOLS-1303
Project: Drools
Issue Type: Enhancement
Components: core engine
Affects Versions: 6.5.0.CR2
Reporter: Matteo Mortari
Assignee: Matteo Mortari
* proper coverage for all methods of java.util.Collection e.g.: addAll()
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1332) Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1332?page=com.atlassian.jira.plugi... ]
Ivo Studensky reassigned WFCORE-1332:
-------------------------------------
Assignee: Ivo Studensky (was: Darran Lofthouse)
> Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1332
> URL: https://issues.jboss.org/browse/WFCORE-1332
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.7.Final
> Reporter: Ondrej Lukas
> Assignee: Ivo Studensky
>
> In case when crossRef object to different domain is configured on MS Active Directory for handling referrals and JBoss EAP 7 uses ldap authentication to mgmt console with configured referrals 'throw' then authentication fails for referral users. It is inconsistent with behavior of EAP with another LDAP providers (e.g. Red Hat Directory Server). In correct behavior authentication should pass.
> It seems it is caused by thrown LdapReferralException search method of org.jboss.as.domain.management.security.LdapUserSearcherFactory.LdapUserSearcherImpl before it is handled by try-catch block. Stack trace of thrown LdapReferralException:
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2975)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1846)
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786)
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:378)
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125)
> org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66)
> org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
> org.jboss.as.domain.management.security.UserLdapCallbackHandler$LdapCallbackHandler.handle(UserLdapCallbackHandler.java:205)
> org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:178)
> org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
> org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
> io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118)
> org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Steve Ebersole commented on JASSIST-261:
----------------------------------------
[~smarlow] - Do I understand that proposal properly that for a persistence unit (module) it would the application's responsibility to define its module as "privately" exporting these classes?
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2098:
--------------------------------
The downside of only coordinators responding to discovery requests is that initial startup of multiple members will inevitable lead to a merge: when A, B and C are started as first members of a cluster, none of them will respond to the others' discovery requests and thus we end up with 3 singleton clusters, which need to be merged into one.
If everybody replied, then everyone would see A, B and C as clients, and they would enact a quick-and-dirty coord election scheme; essentially sorting the list and picking the first to be coordinator.
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2098 at 9/22/16 7:56 AM:
---------------------------------------------------------
To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. *When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}*.
(Perhaps the discovery protocol could query attribute {{TP.use_ip_addrs}} and use it instead, so we don't have to introduce another attribute).
In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to.
was (Author: belaban):
To reduce discovery traffic, an attribute {{only_coord_replies}} (or similar) would be added to {{Discovery}}. When set, only coordinators (not everyone) reply to a {{GET_MBRS_REQ}} with a {{GET_MBRS_RSP}}.
(Perhaps the discovery protocol could query attribute {{TP.use_ip_addrs}} and use it instead, so we don't have to introduce another attribute).
In addition, logical name and UUID-address mappings are not sent back with the reply (making it smaller). At the end of the day, the coord(s) could simply send empty {{GET_MBR_RSP}} messages, as the sender of those replies will all be coordinators, and their addresses ({{IpAddressUUIDs}}) can be used to send the JOIN-REQs to.
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7153) Inconsistency of resources *-ssl-context in model vs. XSD
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7153?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7153:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Inconsistency of resources *-ssl-context in model vs. XSD
> ---------------------------------------------------------
>
> Key: WFLY-7153
> URL: https://issues.jboss.org/browse/WFLY-7153
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> * in client-ssl-context there is attribute {{security-domain}} in XSD, which is not in model. In case of client-ssl-context this probably does not make sense and reaaly should't be in XSD, neither.
> * in both *-ssl-context there is provider in XSD and provider-loader in model. Sync it please. Probably possibility to specify both could be useful.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1257) support query filter implementation in MBeanServerConnection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1257?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1257:
-------------------------------------------------
Vlado Pakan <vpakan(a)redhat.com> changed the Status of [bug 1294010|https://bugzilla.redhat.com/show_bug.cgi?id=1294010] from POST to MODIFIED
> support query filter implementation in MBeanServerConnection
> ------------------------------------------------------------
>
> Key: WFCORE-1257
> URL: https://issues.jboss.org/browse/WFCORE-1257
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Brian Stansberry
> Fix For: 2.0.8.Final
>
>
> There is no implementation for query filter in MBeanServerConnection, marked as TODO
> {code:title=ModelControllerMBeanHelper.java|borderStyle=solid}
> Set<ObjectName> queryNames(final ObjectName name, final QueryExp query) {
> return new RootResourceIterator<Set<ObjectName>>(accessControlUtil, getRootResourceAndRegistration().getResource(),
> new ObjectNameMatchResourceAction<Set<ObjectName>>(name) {
> Set<ObjectName> set = new HashSet<ObjectName>();
> @Override
> public boolean onResource(ObjectName resourceName) {
> if (name == null || name.apply(resourceName)) {
> //TODO check query
> set.add(resourceName);
> }
> return true;
> }
> @Override
> public Set<ObjectName> getResult() {
> if (set.size() == 1 && set.contains(ModelControllerMBeanHelper.createRootObjectName(domain))) {
> return Collections.emptySet();
> }
> return set;
> }
> }).iterate();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-638) Add support for hashed usernames.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-638:
------------------------------------
Summary: Add support for hashed usernames.
Key: ELY-638
URL: https://issues.jboss.org/browse/ELY-638
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI
Reporter: Darran Lofthouse
Fix For: 2.0.0.Alpha1
The latest HTTP Digest RFC https://datatracker.ietf.org/doc/rfc7616/ adds support for hashed usernames.
https://tools.ietf.org/html/rfc7616#page-12
Passing in this hash within the name field of IdentityLocator may be suitable for a realm to map - alternatively NameRewriters and RealmMappers may be needed to handle some of this, or IdentityLocator could be extended to add fields for hashed username and algorithm. Or other options.
Have scheduled for Elytron 2 as this is a new optional part of the RFC. It may turn out to be a feature of a mech never used but general support for an alternative form of a username like this sounds reasonable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months