[JBoss JIRA] (DROOLS-1392) Boolean cells in decision tables are not correctly formatted with Apache POI 3.15
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1392:
-----------------------------------
Summary: Boolean cells in decision tables are not correctly formatted with Apache POI 3.15
Key: DROOLS-1392
URL: https://issues.jboss.org/browse/DROOLS-1392
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mario Fusco
Using Apache POI 3.15 cells of type Boolean are formatted as "TRUE" or "FALSE" instead of "true" or "false" and this leads to generate an invalid drl that will raise compilation errors like the following
{code}
Rule Compilation error : [Rule name='Spreadsheet Example_11']
rule_table/Rule_Spreadsheet_Example_11413427566.java (7:503) : FALSE cannot be resolved to a variable
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (DROOLS-599) kjar archertype
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-599?page=com.atlassian.jira.plugin... ]
Matteo Mortari commented on DROOLS-599:
---------------------------------------
Hi [~mbiarnes] , in reference to my previous comment above, and now discussing with [~mfusco] , we would like to highlight the availability of the Kie Archetype to end users.
However, [since this archetype was first proposed|https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/74/files...], now [License file-headers are attached to all files|https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/7172a50c4...]; with the actual consequence that once you use the archetype, as a user, your files are containing the Red Hat file-header license; and I believe this could be very confusing for the end-users, and also I believe is wrong.
My proposal is to remove License file-headers, at least from all files which are serving as a template-generation.
I have two question, please?
# Do you agree with me reverting your change?
# Did you notice the License file-headers are missing thanks to some automatic tool? Is there a way to manage exclusion, either in the tool or by adding a special header to the file itself?
Thank you in advance for your feedback.
> kjar archertype
> ---------------
>
> Key: DROOLS-599
> URL: https://issues.jboss.org/browse/DROOLS-599
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.1.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Fix For: 6.2.0.CR1
>
>
> I'm opening this JIRA as I will later open PR related to https://groups.google.com/d/msg/drools-development/uO17-kC4mvc/aBRunEcZ_b4J
> The version of the archetype defaults for non-CEP, non-Eclipse plugin in pom. There are property which user can change default value to have CEP, and Eclipse plug-in.
> For reference,
> * Set-up the new project's pom:
> ** Change Java version to 1.6 or greater, by including the maven-compiler-plugin
> ** Add Drools dependencies
> ** Change JUnit dependencies to version 4
> ** Add kie-maven-plugin
> ** [option] Add plug-in org.eclipse.m2e/lifecycle-mapping settings, to avoid Eclipse ERROR at the pom.xml line defining the kie-maven-plugin
> ** Set packaging to 'kjar'
> * ( ALT + F5 in betweens )
> * Creation of an initial .drl file in src/main/resources
> * Creation of minimal kmodule.xml in src/main/resources/META-INF directory
> * Create a simple JUnit test for:
> ** Creation of KieBase [option ->] with STREAM option for CEP features
> ** Creation of KieSession [option ->] with pseudo-clock
> ** [option: Advance] / Insert / Fire template
> ** ... and other verification/output patterns
> * Include SLF4J and LOG4J binding for logging, including a log4j.properties file in src/test/resources
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-7841) ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
by Tibor Digana (JIRA)
[ https://issues.jboss.org/browse/WFLY-7841?page=com.atlassian.jira.plugin.... ]
Tibor Digana commented on WFLY-7841:
------------------------------------
I have created a project in my public repository.
https://github.com/Tibor17/issue-7841
> ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7841
> URL: https://issues.jboss.org/browse/WFLY-7841
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Tibor Digana
> Assignee: Stuart Douglas
>
> The problem is that _EntityManager_ does not have managed delegate within a job executed by _ManagedScheduledExecutorService#scheduleAtFixedRate()_.
> The _EntityManager_ is produced by CDI producer and entire web application is able to work with injected _EntityManager_ except for the jobs.
> I tried to schedule executing the job in two ways and both finished with same issue (No managed context in _EntityManager_) :
> * _@ApplicationScoped_ job instance was passed to executor from caller.
> * The job was changed to _RequestScoped_ and _ContextProxy#createContextualProxy()_ created the Job bean instance and then I called _scheduleAtFixedRate(job, 5, 60, SECONDS)_
> It looks to me that _javax.enterprise.concurrent_ has a different _BeanManager_ and therefore has no notion about my CDI Producer of _EntityManager_. The producer is regular producer of _EntityManager_ in JavaEE.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-7841) ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
by Tibor Digana (JIRA)
[ https://issues.jboss.org/browse/WFLY-7841?page=com.atlassian.jira.plugin.... ]
Tibor Digana updated WFLY-7841:
-------------------------------
Affects Version/s: 10.1.0.Final
> ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7841
> URL: https://issues.jboss.org/browse/WFLY-7841
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Tibor Digana
> Assignee: Stuart Douglas
>
> The problem is that _EntityManager_ does not have managed delegate within a job executed by _ManagedScheduledExecutorService#scheduleAtFixedRate()_.
> The _EntityManager_ is produced by CDI producer and entire web application is able to work with injected _EntityManager_ except for the jobs.
> I tried to schedule executing the job in two ways and both finished with same issue (No managed context in _EntityManager_) :
> * _@ApplicationScoped_ job instance was passed to executor from caller.
> * The job was changed to _RequestScoped_ and _ContextProxy#createContextualProxy()_ created the Job bean instance and then I called _scheduleAtFixedRate(job, 5, 60, SECONDS)_
> It looks to me that _javax.enterprise.concurrent_ has a different _BeanManager_ and therefore has no notion about my CDI Producer of _EntityManager_. The producer is regular producer of _EntityManager_ in JavaEE.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (DROOLS-1391) Investigate why jcr2vfs migration tool needs gwt-user dependency
by Petr Široký (JIRA)
Petr Široký created DROOLS-1391:
-----------------------------------
Summary: Investigate why jcr2vfs migration tool needs gwt-user dependency
Key: DROOLS-1391
URL: https://issues.jboss.org/browse/DROOLS-1391
Project: Drools
Issue Type: Task
Reporter: Petr Široký
Assignee: Petr Široký
After the upgrade of JPA (2.0 -> 2.1) and Hibernate (4.x -> 5.x), the jcr2vfs-importer tests started to fail with {{WELD-ENV-000015: Unable to load annotation: jsinterop.annotations.JsType}}. This class is in {{gwt-user}} jar, so adding that "fixes" the issue. However, gwt-user is a huge library (~16MiB) and ideally should not be needed. We need to investigate if there is a way to get rid of it.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ELY-856) Elytron ldap-realm does not support principal to group mapping (memberOf)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-856?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-856 at 1/2/17 10:42 AM:
---------------------------------------------------------
-This issue is similar to ELY-794 - it would be solved, if we could use any LDAP attribute as wildcard in filter of attribute mapping.-
*Edit:* Ok, we doesn't - as we cannot address entry by DN using filter, special attribute sounds more appropriate - for example:
{code:xml}
<attribute reference="memberOf" from="cn" to="rolesDn" role-recursion="2"/>
{code}
(will take entries given by memberOf of user attribute, puts its cn to rolesDn, repeat for entries given by memberOf of group attribute)
was (Author: honza889):
This issue is similar to ELY-794 - it would be solved, if we could use any LDAP attribute (or identity attribute) as wildcard in filter of attribute mapping.
(But we would need to be able to address entity of attribute by DN!)
> Elytron ldap-realm does not support principal to group mapping (memberOf)
> -------------------------------------------------------------------------
>
> Key: ELY-856
> URL: https://issues.jboss.org/browse/ELY-856
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
> Simplified example:
> {code}
> dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
> dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> objectClass: group
> memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
> {code}
> Example for reproducing: (by olukas)
> Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=someUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: someUser
> cn: some User
> sn: User
> userPassword: Password
> description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: thisUserIsNotUsed
> cn: this User Is Not Used
> sn: this User Is Not Used
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: SomeRole
> member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> {code}
> Mentioned ldif works with legacy security solution.
> This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ELY-856) Elytron ldap-realm does not support principal to group mapping (memberOf)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-856?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-856:
---------------------------
Description:
Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
Simplified example:
{code}
dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
objectClass: groupMember
memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
objectClass: groupMember
objectClass: group
memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
{code}
Example for reproducing: (by olukas)
Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
{code}
dn: ou=People,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
dn: uid=someUser,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: someUser
cn: some User
sn: User
userPassword: Password
description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: thisUserIsNotUsed
cn: this User Is Not Used
sn: this User Is Not Used
userPassword: Password
dn: ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Roles
dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: SomeRole
member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
{code}
Mentioned ldif works with legacy security solution.
This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
was:
Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
Example:
Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
{code}
dn: ou=People,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
dn: uid=someUser,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: someUser
cn: some User
sn: User
userPassword: Password
description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: thisUserIsNotUsed
cn: this User Is Not Used
sn: this User Is Not Used
userPassword: Password
dn: ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Roles
dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: SomeRole
member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
{code}
Mentioned ldif works with legacy security solution.
This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
> Elytron ldap-realm does not support principal to group mapping (memberOf)
> -------------------------------------------------------------------------
>
> Key: ELY-856
> URL: https://issues.jboss.org/browse/ELY-856
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
> Simplified example:
> {code}
> dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
> dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> objectClass: group
> memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
> {code}
> Example for reproducing: (by olukas)
> Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=someUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: someUser
> cn: some User
> sn: User
> userPassword: Password
> description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: thisUserIsNotUsed
> cn: this User Is Not Used
> sn: this User Is Not Used
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: SomeRole
> member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> {code}
> Mentioned ldif works with legacy security solution.
> This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months