[JBoss JIRA] (WFLY-5259) truststore path is ignored if provider is not JKS
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5259?page=com.atlassian.jira.plugin.... ]
Thomas Diesler updated WFLY-5259:
---------------------------------
Component/s: (was: ConfigAdmin)
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFLY-5259
> URL: https://issues.jboss.org/browse/WFLY-5259
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 9.0.1.Final
> Reporter: Arto Huusko
> Assignee: Thomas Diesler
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5259) truststore path is ignored if provider is not JKS
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5259?page=com.atlassian.jira.plugin.... ]
Thomas Diesler reassigned WFLY-5259:
------------------------------------
Assignee: Darran Lofthouse (was: Thomas Diesler)
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFLY-5259
> URL: https://issues.jboss.org/browse/WFLY-5259
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 9.0.1.Final
> Reporter: Arto Huusko
> Assignee: Darran Lofthouse
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (DROOLS-897) Binding variable or condition
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-897?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-897:
------------------------------------
I thought that we agreed that none of the solutions you suggested was doable and I tried to explain why.
The only solution that I see in your case is refactoring your domain model as I suggested above.
> Binding variable or condition
> -----------------------------
>
> Key: DROOLS-897
> URL: https://issues.jboss.org/browse/DROOLS-897
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: Windows 8
> Reporter: Sante Stanisci
> Assignee: Mario Fusco
> Labels: dynamic, instanciation, variable
> Fix For: 6.3.0.Final
>
> Attachments: rule.drl, workaround.drl
>
>
> In this example I have more classes that extends EntityBase (my class). In my intention, i would assign to variable $entity one of this class that is inserted in Ksession fact.
> I insert fact of CtbMovrCoan class
> In when statement of the rule at row 16, variable $entity is correctely,
> but in then statement variable $entity becomes JtbRLavt class (first declared in then cond) and this behavior throw a ClassCastException, obviously.
> Can Help me?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JGRP-1959) TCPPING: initial_hosts are not read in the order in which they're listed
by Bela Ban (JIRA)
Bela Ban created JGRP-1959:
------------------------------
Summary: TCPPING: initial_hosts are not read in the order in which they're listed
Key: JGRP-1959
URL: https://issues.jboss.org/browse/JGRP-1959
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.6.5
{{TCPPING}} doesn't contact the members listed in {{initial_hosts}} in the order in which they are defined. A user might list them in decreasing order of availability, so this is not optimal.
The reason is that we add {{initial_hosts}} and {{dynamic_hosts}} into a *hashset*, which causes reordering.
SOLUTION: use an ArrayList and add a presence check.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5260) Cannot inject TransactionSynchronizationRegistry into CDI bean
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-5260?page=com.atlassian.jira.plugin.... ]
Martin Kouba reassigned WFLY-5260:
----------------------------------
Assignee: Martin Kouba (was: Stuart Douglas)
> Cannot inject TransactionSynchronizationRegistry into CDI bean
> --------------------------------------------------------------
>
> Key: WFLY-5260
> URL: https://issues.jboss.org/browse/WFLY-5260
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Beta2
> Reporter: Tomas Remes
> Assignee: Martin Kouba
>
> It's not possible to inject TransactionSynchronizationRegistry to CDI bean as follows:
> {code}
> @ApplicationScoped
> public class CdiBean {
> @Resource
> TransactionSynchronizationRegistry transactionSynchronizationRegistry;
> }
> {code}
> This results to:
> {noformat}
> java.lang.IllegalArgumentException: WFLYWELD0049: Error injecting resource into CDI managed bean. Can't find a resource named java:comp/env/org.jboss.as.test.integration.weld.jta.CdiBean/transactionSynchronizationRegistry defined on javax.transaction.TransactionSynchronizationRegistry org.jboss.as.test.integration.weld.jta.CdiBean.transactionSynchronizationRegistry
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
> 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.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:210)
> at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices$1.createResource(WeldResourceInjectionServices.java:158)
> at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
> at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:351)
> at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
> at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141)
> at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> at org.jboss.as.test.integration.weld.jta.CdiBean$Proxy$_$$_WeldClientProxy.isTransactionSynchronizationRegistryInjected(Unknown Source)
> at org.jboss.as.test.integration.weld.jta.TransactionSynchronizationRegistryInjectionTestCase.testTransactionSynchronizationRegistryIsInjected(TransactionSynchronizationRegistryInjectionTestCase.java:30)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5260) Cannot inject TransactionSynchronizationRegistry into CDI bean
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-5260?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on WFLY-5260:
-----------------------------------
Test is available at https://github.com/tremes/wildfly/tree/WFLY-5260-test.
> Cannot inject TransactionSynchronizationRegistry into CDI bean
> --------------------------------------------------------------
>
> Key: WFLY-5260
> URL: https://issues.jboss.org/browse/WFLY-5260
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Beta2
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
>
> It's not possible to inject TransactionSynchronizationRegistry to CDI bean as follows:
> {code}
> @ApplicationScoped
> public class CdiBean {
> @Resource
> TransactionSynchronizationRegistry transactionSynchronizationRegistry;
> }
> {code}
> This results to:
> {noformat}
> java.lang.IllegalArgumentException: WFLYWELD0049: Error injecting resource into CDI managed bean. Can't find a resource named java:comp/env/org.jboss.as.test.integration.weld.jta.CdiBean/transactionSynchronizationRegistry defined on javax.transaction.TransactionSynchronizationRegistry org.jboss.as.test.integration.weld.jta.CdiBean.transactionSynchronizationRegistry
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
> 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.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:210)
> at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices$1.createResource(WeldResourceInjectionServices.java:158)
> at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
> at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:351)
> at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
> at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141)
> at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> at org.jboss.as.test.integration.weld.jta.CdiBean$Proxy$_$$_WeldClientProxy.isTransactionSynchronizationRegistryInjected(Unknown Source)
> at org.jboss.as.test.integration.weld.jta.TransactionSynchronizationRegistryInjectionTestCase.testTransactionSynchronizationRegistryIsInjected(TransactionSynchronizationRegistryInjectionTestCase.java:30)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5260) Cannot inject TransactionSynchronizationRegistry into CDI bean
by Tomas Remes (JIRA)
Tomas Remes created WFLY-5260:
---------------------------------
Summary: Cannot inject TransactionSynchronizationRegistry into CDI bean
Key: WFLY-5260
URL: https://issues.jboss.org/browse/WFLY-5260
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 10.0.0.Beta2
Reporter: Tomas Remes
Assignee: Stuart Douglas
It's not possible to inject TransactionSynchronizationRegistry to CDI bean as follows:
{code}
@ApplicationScoped
public class CdiBean {
@Resource
TransactionSynchronizationRegistry transactionSynchronizationRegistry;
}
{code}
This results to:
{noformat}
java.lang.IllegalArgumentException: WFLYWELD0049: Error injecting resource into CDI managed bean. Can't find a resource named java:comp/env/org.jboss.as.test.integration.weld.jta.CdiBean/transactionSynchronizationRegistry defined on javax.transaction.TransactionSynchronizationRegistry org.jboss.as.test.integration.weld.jta.CdiBean.transactionSynchronizationRegistry
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
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.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:210)
at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices$1.createResource(WeldResourceInjectionServices.java:158)
at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
at org.jboss.weld.util.Beans.injectEEFields(Beans.java:351)
at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
at org.jboss.as.test.integration.weld.jta.CdiBean$Proxy$_$$_WeldClientProxy.isTransactionSynchronizationRegistryInjected(Unknown Source)
at org.jboss.as.test.integration.weld.jta.TransactionSynchronizationRegistryInjectionTestCase.testTransactionSynchronizationRegistryIsInjected(TransactionSynchronizationRegistryInjectionTestCase.java:30)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (DROOLS-897) Binding variable or condition
by Sante Stanisci (JIRA)
[ https://issues.jboss.org/browse/DROOLS-897?page=com.atlassian.jira.plugin... ]
Sante Stanisci commented on DROOLS-897:
---------------------------------------
Ok, give me an example to use in correctely mode this fix, since I have proposed several solutions during the discussion.
Best Regards
> Binding variable or condition
> -----------------------------
>
> Key: DROOLS-897
> URL: https://issues.jboss.org/browse/DROOLS-897
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: Windows 8
> Reporter: Sante Stanisci
> Assignee: Mario Fusco
> Labels: dynamic, instanciation, variable
> Fix For: 6.3.0.Final
>
> Attachments: rule.drl, workaround.drl
>
>
> In this example I have more classes that extends EntityBase (my class). In my intention, i would assign to variable $entity one of this class that is inserted in Ksession fact.
> I insert fact of CtbMovrCoan class
> In when statement of the rule at row 16, variable $entity is correctely,
> but in then statement variable $entity becomes JtbRLavt class (first declared in then cond) and this behavior throw a ClassCastException, obviously.
> Can Help me?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months