[JBoss JIRA] (WFLY-13692) Anything in jboss-all.xml after <weld/> element is ignored
by L K (Jira)
[ https://issues.redhat.com/browse/WFLY-13692?page=com.atlassian.jira.plugi... ]
L K commented on WFLY-13692:
----------------------------
Well, as somebody that uses jboss-all.xml I really do not care about javadoc...
But as somebody who wasted some time on this I can tell you that you need to parse the element *completely*. Somebody might put something like this in jboss-all.xml:
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1>
<some-stupid-element/>
</weld>
</jboss>
Yes, it is incorrect, but this is what WeldJBossAllXYParser must deal with.
Just look at for example JBossDeploymentStructureParserXY: it parses everything until it hits END_ELEMENT.
> Anything in jboss-all.xml after <weld/> element is ignored
> ----------------------------------------------------------
>
> Key: WFLY-13692
> URL: https://issues.redhat.com/browse/WFLY-13692
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.1.Final
> Reporter: L K
> Assignee: Matěj Novotný
> Priority: Major
>
> Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
> As a result, everything that comes after </weld> is ignored.
> This jboss-all.xml fails, as expected:
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <some-stupid-element/>
> <weld xmlns="urn:jboss:weld:1.1"/>
> </jboss>
> {code}
> This one is successfully parsed (but must also fail):
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <weld xmlns="urn:jboss:weld:1.1"/>
> <some-stupid-element/>
> </jboss>
> {code}
>
> Now imagine that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13692) Anything in jboss-all.xml after <weld/> element is ignored
by L K (Jira)
[ https://issues.redhat.com/browse/WFLY-13692?page=com.atlassian.jira.plugi... ]
L K edited comment on WFLY-13692 at 7/23/20 3:29 PM:
-----------------------------------------------------
Well, as somebody that uses jboss-all.xml I really do not care about javadoc...
But as somebody who wasted some time on this I can tell you that you need to parse the element *completely*. Somebody might put something like this in jboss-all.xml:
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1>
<some-stupid-element/>
</weld>
</jboss>
Yes, it is incorrect, but this is what WeldJBossAllXYParser must deal with.
Just look at for example JBossDeploymentStructureParserXY: it parses everything until it hits END_ELEMENT.
was (Author: l-k-test):
Well, as somebody that uses jboss-all.xml I really do not care about javadoc...
But as somebody who wasted some time on this I can tell you that you need to parse the element *completely*. Somebody might put something like this in jboss-all.xml:
<jboss xmlns="urn:jboss:1.0">
<weld xmlns="urn:jboss:weld:1.1>
<some-stupid-element/>
</weld>
</jboss>
Yes, it is incorrect, but this is what WeldJBossAllXYParser must deal with.
Just look at for example JBossDeploymentStructureParserXY: it parses everything until it hits END_ELEMENT.
> Anything in jboss-all.xml after <weld/> element is ignored
> ----------------------------------------------------------
>
> Key: WFLY-13692
> URL: https://issues.redhat.com/browse/WFLY-13692
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.1.Final
> Reporter: L K
> Assignee: Matěj Novotný
> Priority: Major
>
> Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes.
> As a result, everything that comes after </weld> is ignored.
> This jboss-all.xml fails, as expected:
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <some-stupid-element/>
> <weld xmlns="urn:jboss:weld:1.1"/>
> </jboss>
> {code}
> This one is successfully parsed (but must also fail):
> {code:java}
> <jboss xmlns="urn:jboss:1.0">
> <weld xmlns="urn:jboss:weld:1.1"/>
> <some-stupid-element/>
> </jboss>
> {code}
>
> Now imagine that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (JGRP-2494) DNS_PING and failed probes
by Dewayne McNair (Jira)
[ https://issues.redhat.com/browse/JGRP-2494?page=com.atlassian.jira.plugin... ]
Dewayne McNair commented on JGRP-2494:
--------------------------------------
Yes - this can be closed.
> DNS_PING and failed probes
> --------------------------
>
> Key: JGRP-2494
> URL: https://issues.redhat.com/browse/JGRP-2494
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dewayne McNair
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGRP-2494.txt
>
>
> Using DNS_PING in a DC/OS (marathon) deployment, there are two SRV records returned - one for the web port and one for the jgroups port. When the discovery request is sent, an exception is thrown and logged. The clustering is working, but logs are filling up due to the exception happening and being logged frequently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13693) Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
by Stephen Fikes (Jira)
[ https://issues.redhat.com/browse/WFLY-13693?page=com.atlassian.jira.plugi... ]
Stephen Fikes updated WFLY-13693:
---------------------------------
Affects Version/s: 18.0.0.Final
> Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-13693
> URL: https://issues.redhat.com/browse/WFLY-13693
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 14.0.0.Final, 18.0.0.Final
> Reporter: Stephen Fikes
> Assignee: Scott Marlow
> Priority: Major
>
> A custom cache template is defined in the "hibernate" cache container in the {{standalone.xml}}
> {code:java}
> <local-cache name="entities.custom-cache">
> <transaction mode="NONE"/>
> <object-memory size="10"/>
> </local-cache>
> {code}
> In the legacy {{hibernate.cfg.xml}} this is associated with a named cache region.
> {code:java}
> <property name="hibernate.cache.region_prefix">entities</property>
> <property name="hibernate.cache.infinispan.entities.custom-cache.cfg">entities.custom-cache</property>
> <property name="hibernate.cache.use_second_level_cache">true</property>
> {code}
> The cache region is then referenced in an entity annotation:
> {code:java}
> @Entity
> @Cache(usage=CacheConcurrencyStrategy.READ_WRITE, region="custom-cache")
> public class Employee {
> ...
> }
> {code}
> At deployment, an exception is logged:
> {noformat}
> ... HHH025007: Custom cache configuration 'entities.custom-cache' was requested for region entities.custom-cache but it was not found - using configuration by type (entity).
> {noformat}
> This same approach (but using transactional caching) worked in Wildfly 11.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13694) [GSS](7.3.z) Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
by Stephen Fikes (Jira)
Stephen Fikes created WFLY-13694:
------------------------------------
Summary: [GSS](7.3.z) Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
Key: WFLY-13694
URL: https://issues.redhat.com/browse/WFLY-13694
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 14.0.0.Final
Reporter: Stephen Fikes
Assignee: Scott Marlow
A custom cache template is defined in the "hibernate" cache container in the {{standalone.xml}}
{code:java}
<local-cache name="entities.custom-cache">
<transaction mode="NONE"/>
<object-memory size="10"/>
</local-cache>
{code}
In the legacy {{hibernate.cfg.xml}} this is associated with a named cache region.
{code:java}
<property name="hibernate.cache.region_prefix">entities</property>
<property name="hibernate.cache.infinispan.entities.custom-cache.cfg">entities.custom-cache</property>
<property name="hibernate.cache.use_second_level_cache">true</property>
{code}
The cache region is then referenced in an entity annotation:
{code:java}
@Entity
@Cache(usage=CacheConcurrencyStrategy.READ_WRITE, region="custom-cache")
public class Employee {
...
}
{code}
At deployment, an exception is logged:
{noformat}
... HHH025007: Custom cache configuration 'entities.custom-cache' was requested for region entities.custom-cache but it was not found - using configuration by type (entity).
{noformat}
This same approach (but using transactional caching) worked in Wildfly 11.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13693) Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
by Stephen Fikes (Jira)
Stephen Fikes created WFLY-13693:
------------------------------------
Summary: Custom Infinispan cache regions fail when using legacy (non-JPA) Hibernate configuration
Key: WFLY-13693
URL: https://issues.redhat.com/browse/WFLY-13693
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 14.0.0.Final
Reporter: Stephen Fikes
Assignee: Scott Marlow
A custom cache template is defined in the "hibernate" cache container in the {{standalone.xml}}
{code:java}
<local-cache name="entities.custom-cache">
<transaction mode="NONE"/>
<object-memory size="10"/>
</local-cache>
{code}
In the legacy {{hibernate.cfg.xml}} this is associated with a named cache region.
{code:java}
<property name="hibernate.cache.region_prefix">entities</property>
<property name="hibernate.cache.infinispan.entities.custom-cache.cfg">entities.custom-cache</property>
<property name="hibernate.cache.use_second_level_cache">true</property>
{code}
The cache region is then referenced in an entity annotation:
{code:java}
@Entity
@Cache(usage=CacheConcurrencyStrategy.READ_WRITE, region="custom-cache")
public class Employee {
...
}
{code}
At deployment, an exception is logged:
{noformat}
... HHH025007: Custom cache configuration 'entities.custom-cache' was requested for region entities.custom-cache but it was not found - using configuration by type (entity).
{noformat}
This same approach (but using transactional caching) worked in Wildfly 11.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (DROOLS-5528) Drools buisness central ldap authentication
by prabhat kumar (Jira)
[ https://issues.redhat.com/browse/DROOLS-5528?page=com.atlassian.jira.plug... ]
prabhat kumar commented on DROOLS-5528:
---------------------------------------
Hi Team,
I have configured the kie buisness central and kie server on the wildfly and its working fine. But we need to implement LDAP security authentication and have configured the same in wildfly standalone-full.xml . I am able to login to workbench and performed the rules related action.
But My issue is that Buisness central workbench is unable to registered with kieserver at time of startup,even I have created users on the LDAP server with below roles:-
User:- prabhatA
password:-password
role:- rest-all,admin
User:- prabhatServer
password:-password
role:- kie-server,admin
And mentioned the credentionl in system properties tag of standalone-full.xml:-
<property name="org.kie.server.controller.user" value="prabhatA"/>
<property name="org.kie.server.controller.password" value="password"/>
<property name="org.kie.server.user" value="prabhatServer"/>
<property name="org.kie.server.pwd" value="password"/>
<property name="org.kie.server.controller" value="[http://localhost:8080/business-central/rest/controller]"/>
<property name="org.kie.server.location" value="[http://localhost:8080/kie-server/services/rest/server]"/>
<property name="[org.kie.server.id|http://org.kie.server.id/]" value="wildfly-kieserver"/>
Also add ldap configuration for the login module as below:-
<security-domain name="ldap" cache-type="default">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">
<module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
<module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
<module-option name="java.naming.security.authentication" value="simple"/>
<module-option name="bindDN" value="uid=admin,ou=system"/>
<module-option name="bindCredential" value="secret"/>
<module-option name="baseCtxDN" value="ou=pepoleTest,dc=example,dc=com"/>
<module-option name="baseFilter" value="(uid=\{0})"/>
<module-option name="rolesCtxDN" value="ou=ruleTest,dc=example,dc=com"/>
<module-option name="roleFilter" value="(member=\{1})"/>
<module-option name="roleAttributeID" value="cn"/>
<module-option name="roleAttributeIsDN" value="true"/>
<module-option name="roleNameAttributeID" value="cn"/>
<module-option name="roleRecursion" value="2"/>
<module-option name="searchScope" value="SUBTREE_SCOPE"/>
</login-module>
</authentication>
</security-domain>
I have also updated the security doman value in jboss-web.xml of business central and kie server wars.
<security-domain>ldap</security-domain>
Note:----
If I create user on LDAP server with below details:-
username =kieserver
password = kieserver1!
role= kie-server
Then both business central and kie server are able to register themselves successfully.But this approcah forcing us to create user on LDAP server with above details(kieserver).
Could you please suggest the way so that I don't need to create user with details (userName=kieserver and password=kieserver1!).
> Drools buisness central ldap authentication
> -------------------------------------------
>
> Key: DROOLS-5528
> URL: https://issues.redhat.com/browse/DROOLS-5528
> Project: Drools
> Issue Type: Feature Request
> Reporter: prabhat kumar
> Assignee: Mario Fusco
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month