[JBoss JIRA] (DROOLS-2588) Kie maven plugin does not build kiebase on windows
by Viacheslav Krot (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2588?page=com.atlassian.jira.plugi... ]
Viacheslav Krot updated DROOLS-2588:
------------------------------------
Description:
Hi,
In drools 7.7.0.Final maven plugin suddenly stopped building kie base and thus verifying DRL files during packaging. It does not find the resources at all, during build I see warning:
{noformat}
[WARNING] No files found for KieBase defaultKieBase
{noformat}
I attach a simple project with error in DRL, it should not be built, but with 7.7.0.Final on Windows the build is successful. Though same project fails on macos or linux (as expected). And even 7.6.0 on Windows produces error
{noformat}
[ERROR] Unable to build KieBaseModel:defaultKieBase
Unable to resolve ObjectType 'List2' : [Rule name='all_import']
{noformat}
Only windows is affected, builds on linux and macos work as expected - they fail (because there is an error in DRL file), only windows with 7.7.0 plugin pass because it does not see the resources.
was:
Hi,
In drools 7.7.0.Final maven plugin suddenly stopped building kie base and thus verifying DRL files during packaging. It does not find the resources at all, during build I see warning:
{noformat}
[WARNING] No files found for KieBase defaultKieBase
{noformat}
I attach a simple project with error in DRL, it should not be built, but with 7.7.0.Final on Windows the build is successful. Though same project fails on macos or linux (as expected). And even 7.6.0 on Windows produces error
{noformat}
[ERROR] Unable to build KieBaseModel:defaultKieBase
Unable to resolve ObjectType 'List2' : [Rule name='all_import']
{noformat}
> Kie maven plugin does not build kiebase on windows
> --------------------------------------------------
>
> Key: DROOLS-2588
> URL: https://issues.jboss.org/browse/DROOLS-2588
> Project: Drools
> Issue Type: Bug
> Components: tools
> Affects Versions: 7.7.0.Final
> Environment: Windows 10
> Reporter: Viacheslav Krot
> Assignee: Mario Fusco
> Attachments: net_tst.zip
>
>
> Hi,
> In drools 7.7.0.Final maven plugin suddenly stopped building kie base and thus verifying DRL files during packaging. It does not find the resources at all, during build I see warning:
> {noformat}
> [WARNING] No files found for KieBase defaultKieBase
> {noformat}
> I attach a simple project with error in DRL, it should not be built, but with 7.7.0.Final on Windows the build is successful. Though same project fails on macos or linux (as expected). And even 7.6.0 on Windows produces error
> {noformat}
> [ERROR] Unable to build KieBaseModel:defaultKieBase
> Unable to resolve ObjectType 'List2' : [Rule name='all_import']
> {noformat}
> Only windows is affected, builds on linux and macos work as expected - they fail (because there is an error in DRL file), only windows with 7.7.0 plugin pass because it does not see the resources.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2588) Kie maven plugin does not build kiebase on windows
by Viacheslav Krot (JIRA)
Viacheslav Krot created DROOLS-2588:
---------------------------------------
Summary: Kie maven plugin does not build kiebase on windows
Key: DROOLS-2588
URL: https://issues.jboss.org/browse/DROOLS-2588
Project: Drools
Issue Type: Bug
Components: tools
Affects Versions: 7.7.0.Final
Environment: Windows 10
Reporter: Viacheslav Krot
Assignee: Mario Fusco
Attachments: net_tst.zip
Hi,
In drools 7.7.0.Final maven plugin suddenly stopped building kie base and thus verifying DRL files during packaging. It does not find the resources at all, during build I see warning:
{noformat}
[WARNING] No files found for KieBase defaultKieBase
{noformat}
I attach a simple project with error in DRL, it should not be built, but with 7.7.0.Final on Windows the build is successful. Though same project fails on macos or linux (as expected). And even 7.6.0 on Windows produces error
{noformat}
[ERROR] Unable to build KieBaseModel:defaultKieBase
Unable to resolve ObjectType 'List2' : [Rule name='all_import']
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1587) X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3]
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1587?page=com.atlassian.jira.plugin.s... ]
Farah Juma commented on ELY-1587:
---------------------------------
[~mchoma] A reproducer of some sort would be great. You should just be able to use an {{X500PrincipalBuilder}}, as David mentioned.
> X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3]
> -----------------------------------------------------------------------------
>
> Key: ELY-1587
> URL: https://issues.jboss.org/browse/ELY-1587
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Certificate Authority, X.500
> Affects Versions: 1.3.2.Final
> Reporter: Martin Choma
> Priority: Critical
> Fix For: 1.4.0.CR1
>
>
> Debugging revealed certificate use {{utf8String}} representation whereas Elytron is expecting {{printableString}}
> In rfc 5280 [1] chapter 4.1.2.4. Issuer there is specified value of subject/issuer can be of 5 types
> {code}
> DirectoryString ::= CHOICE {
> teletexString TeletexString (SIZE (1..MAX)),
> printableString PrintableString (SIZE (1..MAX)),
> universalString UniversalString (SIZE (1..MAX)),
> utf8String UTF8String (SIZE (1..MAX)),
> bmpString BMPString (SIZE (1..MAX)) }
> {code}
> However Elytron X500 principal decoder [2] can handle only 2 of them PRINTABLE_STRING_TYPE and IA5_STRING_TYPE (not sure which type of rfc does that match) [2]
> Definitely missing {{utf8String}} (my case). Also revise for backward compatibility {{teletexString}}, {{bmpString}} and {{universalString}}
> [1] https://www.ietf.org/rfc/rfc5280.txt
> [2] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10454) NPE on EJB txn recover request
by David Lloyd (JIRA)
David Lloyd created WFLY-10454:
----------------------------------
Summary: NPE on EJB txn recover request
Key: WFLY-10454
URL: https://issues.jboss.org/browse/WFLY-10454
Project: WildFly
Issue Type: Bug
Components: EJB, Transactions
Reporter: David Lloyd
Assignee: David Lloyd
Priority: Blocker
An NPE can occur during transaction recovery requests from the EJB protocol (and possibly other places as well).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10453) NPE on EJB txn recover request
by David Lloyd (JIRA)
David Lloyd created WFLY-10453:
----------------------------------
Summary: NPE on EJB txn recover request
Key: WFLY-10453
URL: https://issues.jboss.org/browse/WFLY-10453
Project: WildFly
Issue Type: Bug
Components: EJB, Transactions
Reporter: David Lloyd
Assignee: David Lloyd
Priority: Blocker
An NPE can occur during transaction recovery requests from the EJB protocol (and possibly other places as well).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10076) Add a more verbose description on the IllegalStateException fix on WFLY-9821
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-10076?page=com.atlassian.jira.plugin... ]
Ilia Vassilev reassigned WFLY-10076:
------------------------------------
Assignee: Ilia Vassilev
> Add a more verbose description on the IllegalStateException fix on WFLY-9821
> ----------------------------------------------------------------------------
>
> Key: WFLY-10076
> URL: https://issues.jboss.org/browse/WFLY-10076
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Viral Gohel
> Assignee: Ilia Vassilev
>
> Parent issue: https://issues.jboss.org/browse/WFLY-9821
> We throw an IlegalStateException, when an attempt is made to call the CDI container before the container is actually started with the use of CDI.current().
> Although the fix clearly states its not the correct way to set the state, we throw an Exception. The deployments succeed, but a non-expert CDI user might not expect an exception, and probably it would leave them confused on what is wrong, unless they understand what they have done in their own application code.
> My thought and wish was, if we can add some log.WARN message in the condition describing why this happens, would be nice! It provides you with hints on what is NOT to be done in your application code.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10452) Don't overwrite deployment-scanner config in servlet's standalone-profile
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-10452:
----------------------------------------
Summary: Don't overwrite deployment-scanner config in servlet's standalone-profile
Key: WFLY-10452
URL: https://issues.jboss.org/browse/WFLY-10452
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
servlet-galleon-pack/src/main/resources/feature_groups/standalone-profile.xml configures the scanner with the default values, which is redundant, as it is inherited from wildfly core.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3891) Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
by Nikoleta Žiaková (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3891?page=com.atlassian.jira.plugi... ]
Nikoleta Žiaková updated WFCORE-3891:
-------------------------------------
Description:
When trying to create an {{xml-formatter}} or {{json-formatter}} with the same name as another resource (e.g. a {{file-handler}}), the operation fails:
{code}
[standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=aaa.log})
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=logging/xml-formatter=test:add
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"dateFormat\" setter found for formatter \"test\"",
"rolled-back" => true
}
{code}
Similarly vice-versa, when trying to create another resource in logging subsystem with the same name as an {{xml-formatter}} or a {{json-formatter}}, the operation fails:
{code}
[standalone@localhost:9990 /] /subsystem=logging/json-formatter=test:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"pattern\" setter found for formatter \"test\"",
"rolled-back" => true
}
{code}
The same scenario works for e.g. {{pattern-formatter}}:
{code}
[standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=logging/pattern-formatter=test:add
{"outcome" => "success"}
{code}
was:
When trying to create an {{xml-formatter}} or {{json-formatter}} with the same name as another resource (e.g. a {{file-handler}}), the operation fails:
{code}
/[standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=aaa.log})
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=logging/xml-formatter=test:add
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"dateFormat\" setter found for formatter \"test\"",
"rolled-back" => true
}
{code}
Similarly vice-versa, when trying to create another resource in logging subsystem with the same name as an {{xml-formatter}} or a {{json-formatter}}, the operation fails:
{code}
[standalone@localhost:9990 /] /subsystem=logging/json-formatter=test:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"pattern\" setter found for formatter \"test\"",
"rolled-back" => true
}
{code}
The same scenario works for e.g. {{pattern-formatter}}:
{code}
/[standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=logging/pattern-formatter=test:add
{"outcome" => "success"}
{code}
> Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3891
> URL: https://issues.jboss.org/browse/WFCORE-3891
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Nikoleta Žiaková
> Assignee: James Perkins
>
> When trying to create an {{xml-formatter}} or {{json-formatter}} with the same name as another resource (e.g. a {{file-handler}}), the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=aaa.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/xml-formatter=test:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"dateFormat\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> Similarly vice-versa, when trying to create another resource in logging subsystem with the same name as an {{xml-formatter}} or a {{json-formatter}}, the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/json-formatter=test:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"pattern\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> The same scenario works for e.g. {{pattern-formatter}}:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/pattern-formatter=test:add
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months