[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ]
Jan Kalina reopened WFLY-7322:
------------------------------
Reopen: DIRECT verification still not work with FOLLOW mode
> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
> Key: WFLY-7322
> URL: https://issues.jboss.org/browse/WFLY-7322
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-969) Add a KeyStore implementation that can use the key store password for retrieving entries.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-969:
--------------------------------------
At the key store level we could have the option of defining different filters and each of those being associated with a different credential reference - we could then aggregate the results together giving you one KeyStore able to return different entries using a different protection parameter for each.
> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
> Key: ELY-969
> URL: https://issues.jboss.org/browse/ELY-969
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: KeyStores
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta28
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-969) Add a KeyStore implementation that can use the key store password for retrieving entries.
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.sy... ]
Martin Choma commented on ELY-969:
----------------------------------
So in terms of subsystem; Key password of key-manager could become optional. And elytron keystore implementation will "default" key-password with keystore password - I am OK with such enhancement.
Regarding "password for different entries". I thought multiple keys will be handled by filter-alias on key-manager (https://issues.jboss.org/browse/WFLY-7158). It means effectivelly filter keys to one and provide key-password for that one.
So I am not sure how is this "password for different entries" meant on KeyStore level.
> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
> Key: ELY-969
> URL: https://issues.jboss.org/browse/ELY-969
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: KeyStores
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta28
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1444) KieSession to implement java.lang.AutoCloseable
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1444?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1444:
-------------------------------------
In that example you're showing how to use try-with-resource with the StringWriter. That makes perfectly sense to me but it is not what I was asking. I was asking for a practical example using the KieSession because in my opinion in that case it is not that useful and using a try-with-resource is more verbose and cumbersome than simply adding a dispose.
I cannot add this to drools 6.x because it has to stay Java 6 compatible, but I could do this on master (drools 7) that is Java 8 based. However I really don't see the usefulness in doing so. Moreover your scenario seems to fit far better a StatelessKieSession which doesn't require any dispose. Did you give it a try?
> KieSession to implement java.lang.AutoCloseable
> -----------------------------------------------
>
> Key: DROOLS-1444
> URL: https://issues.jboss.org/browse/DROOLS-1444
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: tech meshter
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: AutocloseableSample.java
>
>
> Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1444) KieSession to implement java.lang.AutoCloseable
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1444?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1444.
---------------------------------
Resolution: Rejected
> KieSession to implement java.lang.AutoCloseable
> -----------------------------------------------
>
> Key: DROOLS-1444
> URL: https://issues.jboss.org/browse/DROOLS-1444
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: tech meshter
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: AutocloseableSample.java
>
>
> Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-969) Add a KeyStore implementation that can use the key store password for retrieving entries.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-969:
--------------------------------------
No within the subsystem it will not require an additional resource - that would not solve the problem this change is intended to solve at all.
> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
> Key: ELY-969
> URL: https://issues.jboss.org/browse/ELY-969
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: KeyStores
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta28
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1529) New threads named ServerService Thread Pool -- xyz created with every deploy and undeploy and removed after ~20 seconds
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1529?page=com.atlassian.jira.plugi... ]
Rostislav Svoboda commented on WFCORE-1529:
-------------------------------------------
https://github.com/wildfly/wildfly-core/pull/2164/files
> New threads named ServerService Thread Pool -- xyz created with every deploy and undeploy and removed after ~20 seconds
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1529
> URL: https://issues.jboss.org/browse/WFCORE-1529
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: Rostislav Svoboda
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Beta3
>
>
> tl;dr version from Brian:
> The ServerService Threads and Host Controller Service Threads pools have no core size and a thread timeout of 20 secs, so if a management request comes in periodically but less often then every 20 secs (says twice a minute) the pool will continually churn threads. That kind of periodic polling is not an unusual scenario, so, we'll put in a core size of one or two.
> Original details from Rostislav:
> I did quite simple thing in the loop :
> * deploy attached application into jboss-eap-7.0/standalone/deployments/
> * wait 1 minute
> * remove anything from jboss-eap-7.0/standalone/deployments/
> * wait 1 minute
> I connected with jvisualvm and was watching monitor tab for cpu / classes / heap / threads overview statistics. After some time I spotted jumps (up and down) on threads.
> After some time I see threads named "ServerService Thread Pool -- 346", I ended with number bigger than 1400. In my case 15 threads are created for 20 seconds when deploying and another 15 threads are created for 20 seconds when undeploying. Nothing seems to be reused
> Setup for threads is done in https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... method addService
> Is it intentional to have threads alive only 20 seconds and then scratch them ? Keeping a lot of threads means usage of system resources, creating new threads has some overhead too. Maybe the question is what is the right balance ?
> Note: It would be nice to have "Possible Bug" Issue Type for issues like this ;)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-8160:
----------------------------------
Attachment: (was: BioMatcherWebserviceImpl.java)
> Webservice response File Descriptor leak
> ----------------------------------------
>
> Key: WFLY-8160
> URL: https://issues.jboss.org/browse/WFLY-8160
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final
> Environment: JDK: jdk1.8.0_121, jdk1.8.0_66
> WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final
> OS: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Hardware: 64 bit 4 core
> Reporter: Mahesh Reddy
> Assignee: Alessio Soldano
> Priority: Blocker
> Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt
>
>
> We are getting File descriptor leak when wildfly responds to webservice call.
> I think this happens if the webresvice response is huge complex structure,
> I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p <pid>, And again checking it after client receives the response,.
> I notice for each webservice call, 2 file descriptors are open and never closed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8064) Dependecy Injection not working
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-8064?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-8064:
---------------------------------------
indeed... [~gprade], please provide a reproducer, thanks
> Dependecy Injection not working
> -------------------------------
>
> Key: WFLY-8064
> URL: https://issues.jboss.org/browse/WFLY-8064
> Project: WildFly
> Issue Type: Release
> Components: CDI / Weld, REST
> Affects Versions: 10.0.0.Final
> Environment: Windows 2012 R2
> Reporter: Pradeep Ganapathy
> Assignee: Alessio Soldano
>
> All injected parameters after post construct are null. Jboss cant able to detect inject paramaters. Both dao and testDescription parameters are null. As a result null pointer exception
> RestEasy versions(All) ----> 3.0.14.Final.
> ApplicationScoped
> public class TestImpl implements ITest
> {
>
> @Inject
> private ITestDAO dao;
> public TestImpl setTestDAO(ITestDAO dao)
> {
> this.dao = dao;
> return this;
> }
> @Inject
> private TestDescription testDescription;
> public TestImpl setTestDescription(TestDescription testDescription)
> {
> this.testDescription = testDescription;
> return this;
> }
> }
> Error Logs:
> 2017-02-09 13:11:22,256 ERROR [io.undertow.request] (default task-128) UT005023: Exception handling request to( My EndPoint): org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> Caused by: java.lang.NullPointerException
> at ServiceRegistryImpl.lookup(ServiceRegistryImpl.java:142)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
> ... 35 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1445) Mask should reflect properties accessed in other nodes join constraints
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1445:
--------------------------------------
Summary: Mask should reflect properties accessed in other nodes join constraints
Key: DROOLS-1445
URL: https://issues.jboss.org/browse/DROOLS-1445
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Matteo Mortari
Assignee: Mario Fusco
The following test exhibit a failing and a working test:
{code:java}
@Test()
public void testAbis_NotWorking() {
// DROOLS-644
String drl =
"import " + Person.class.getCanonicalName() + ";\n" +
"global java.util.List list;\n" +
"rule R when\n" +
" $p1 : Person( name == \"Mario\" ) \n" +
" $p2 : Person( age > $p1.age ) \n" +
"then\n" +
" list.add(\"t0\");\n" +
"end\n" +
"rule Z when\n" +
" $p1 : Person( name == \"Mario\" ) \n" +
"then\n" +
" modify($p1) { setAge(35); } \n" +
"end\n"
;
// making the default explicit:
KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
.build()
.newKieSession();
ksession.addEventListener(new DebugAgendaEventListener());
System.out.println(drl);
ReteDumper.dumpRete(ksession);
List<String> list = new ArrayList<String>();
ksession.setGlobal("list", list);
Person mario = new Person("Mario", 40);
Person mark = new Person("Mark", 37);
FactHandle fh_mario = ksession.insert(mario);
ksession.insert(mark);
int x = ksession.fireAllRules();
assertEquals(1, list.size());
assertEquals("t0", list.get(0));
}
@Test()
public void testAbis_Working() {
// DROOLS-644
String drl =
"import " + Person.class.getCanonicalName() + ";\n" +
"global java.util.List list;\n" +
"rule R when\n" +
" $p1 : Person( name == \"Mario\", $a1: age) \n" +
" $p2 : Person( age > $a1 ) \n" +
"then\n" +
" list.add(\"t0\");\n" +
"end\n" +
"rule Z when\n" +
" $p1 : Person( name == \"Mario\" ) \n" +
"then\n" +
" modify($p1) { setAge(35); } \n" +
"end\n"
;
// making the default explicit:
KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
.build()
.newKieSession();
System.out.println(drl);
ReteDumper.dumpRete(ksession);
List<String> list = new ArrayList<String>();
ksession.setGlobal("list", list);
Person mario = new Person("Mario", 40);
Person mark = new Person("Mark", 37);
FactHandle fh_mario = ksession.insert(mario);
ksession.insert(mark);
int x = ksession.fireAllRules();
assertEquals(1, list.size());
assertEquals("t0", list.get(0));
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months