[JBoss JIRA] (DROOLS-5551) Cannot configure kie-maven-plugin to read the rules from a different folder
by Ciprian Chiru (Jira)
[ https://issues.redhat.com/browse/DROOLS-5551?page=com.atlassian.jira.plug... ]
Ciprian Chiru updated DROOLS-5551:
----------------------------------
Description:
_kie-maven-plugin_ ignores _sourceFolder_ configuration and there is no other option to set the rules directory. It always looks for rules in the project's folder.
In our case the DRL files are being generated, so the plugin needs to look for them in the _generated-resources_ folder in the _target_ directory.
We can workaround this using ._gitignore_ and configure _maven-clean_ to clean the folder inside the project structure, but it's quite messy.
was:
_kie-maven-plugin_ ignores _sourceFolder_ configuration and there is no other option to set the rules directory. It always looks for rules in the project's resources folder.
> Cannot configure kie-maven-plugin to read the rules from a different folder
> ---------------------------------------------------------------------------
>
> Key: DROOLS-5551
> URL: https://issues.redhat.com/browse/DROOLS-5551
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.31.0.Final, 7.32.0.Final, 7.33.0.Final, 7.34.0.Final, 7.35.0.Final, 7.36.0.Final, 7.37.0.Final, 7.38.0.Final, 7.39.0.Final, 7.40.0.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Minor
> Attachments: image.jpeg, image.png
>
>
> _kie-maven-plugin_ ignores _sourceFolder_ configuration and there is no other option to set the rules directory. It always looks for rules in the project's folder.
> In our case the DRL files are being generated, so the plugin needs to look for them in the _generated-resources_ folder in the _target_ directory.
> We can workaround this using ._gitignore_ and configure _maven-clean_ to clean the folder inside the project structure, but it's quite messy.
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2474:
--------------------------------
OK, I guess another issue is that the program *disconnects* the second channel and then creates a new one, but it needs to *close* the second channel first! I've attached the modified program
> Messages about dropped queued message when using IpAddressUUID
> --------------------------------------------------------------
>
> Key: JGRP-2474
> URL: https://issues.redhat.com/browse/JGRP-2474
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.3
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGR.java, JGR2.java, log-fail-1.txt, log2.txt
>
>
> We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like
> {code}
> Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages
> WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1)
> {code}
> when ever an application is restarted. Our setup is as follows (most due to network restrictions):
> * Fixed port numbers
> * JDBC_PING
> * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table
> I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above.
> I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine.
> I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this.
> While running this on higher debug levels, I observed the following: 4.1.2 will not require an
> ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used,
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13758) Avoid hard-coding groupId on wildfly-clustering-marshalling-jboss module dependencies
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFLY-13758:
-------------------------------------------
Summary: Avoid hard-coding groupId on wildfly-clustering-marshalling-jboss module dependencies
Key: WFLY-13758
URL: https://issues.redhat.com/browse/WFLY-13758
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
Currently, we have {{org.wildfly}} hardcoded in some {{wildfly-clustering-marshalling-jboss}} maven dependencies. The use of {{$\{project.groupId}}} facilitates the switching to different product branches.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2474:
--------------------------------
Apologies for the long delay!
OK, so I'm looking into this and found that IpAddressUUID can *not* use a FILE_PING based discovery protocol (e.g. JDBC_PING), as the parsing will fail since there's no UUID.
I'm going to replace JDBC_PING with MPING to further debug. I guess you cannot pass the same address to the restarted member in {{create2()}}, as this will lead to reincarnation issues.
> Messages about dropped queued message when using IpAddressUUID
> --------------------------------------------------------------
>
> Key: JGRP-2474
> URL: https://issues.redhat.com/browse/JGRP-2474
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.3
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGR.java, JGR2.java, log-fail-1.txt, log2.txt
>
>
> We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like
> {code}
> Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages
> WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1)
> {code}
> when ever an application is restarted. Our setup is as follows (most due to network restrictions):
> * Fixed port numbers
> * JDBC_PING
> * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table
> I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above.
> I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine.
> I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this.
> While running this on higher debug levels, I observed the following: 4.1.2 will not require an
> ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used,
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13756) User is able to specify credential-reference with only store name
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-13756?page=com.atlassian.jira.plugi... ]
Farah Juma commented on WFLY-13756:
-----------------------------------
[~dlofthouse] Sure, will take a look at this one.
> User is able to specify credential-reference with only store name
> -----------------------------------------------------------------
>
> Key: WFLY-13756
> URL: https://issues.redhat.com/browse/WFLY-13756
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 20.0.0.Final, 20.0.1.Final
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
>
> It is possible to create a {{credential-reference}} to the credential store just with the name of credential store in question - without specifying {{alias}} (or {{clear-text}} in case of automatic addition of new record into the credential store, see doc [16.4.2. Automatic Updates of Credential Stores|https://docs.wildfly.org/20/WildFly_Elytron_Security.html#referenc...]). Actual configuration error is revealed when server is reloaded with following error message in server log (note that I can see this error in case of 'key-store' example but not in case of 'imap' example - see Reproduction steps for this issue):
> {code}
> 22:03:26,791 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("key-store" => "exampleKS")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.exampleKS" => "WFLYELY00004: Unable to start the service.
> Caused by: java.io.IOException: WFLYELY00910: Password cannot be resolved for key-store '/tmp/cred/wildfly-20.0.1.Final/standalone/configuration/example.keystore'"}}
> {code}
> This misconfiguration is not possible to do in {{Wildfly 19.1.0.Final}} as you are requested to specify {{alias}} attribute too.
> I suspect that change in behavior has been introduced thanks to this new feature https://issues.redhat.com/browse/WFLY-12218 (see the doc referenced above).
> Correct behavior is to require credential store name and:
> # 'alias'
> # or 'alias' and 'clear-text'
> # or 'clear-text' (alias will be generated automatically in this case)
> as described in the referenced documentation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JGRP-2496) Incorrect schema
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2496?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2496:
--------------------------------
Note that the new schemas for master and the 4.x branch have been uploaded to jgroups.org. XML configs referencing any of these schemas will therefore work *without* upgrading.
> Incorrect schema
> ----------------
>
> Key: JGRP-2496
> URL: https://issues.redhat.com/browse/JGRP-2496
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.2.5, 5.0.1
>
>
> XmlSchemeGenerator generates incorrect XSD:
> {code:xml}
> <xs:attribute type="xs:string" version="${version}" /> needs to be changed to
> <xs:attribute type="xs:string" name="version" />
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFLY-13719?page=com.atlassian.jira.plugi... ]
Brad Maxwell commented on WFLY-13719:
-------------------------------------
Setting -Djboss.ee.ignore-unused-resource-binding=true enables the old behavior which ignores unused resource bindings
> Error deploying EJB in WildFly when using @EJB
> ----------------------------------------------
>
> Key: WFLY-13719
> URL: https://issues.redhat.com/browse/WFLY-13719
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 20.0.1.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Fix For: 21.0.0.Beta1
>
> Attachments: reproducer.zip
>
>
> The following example does *not* get deployed on Wildfly 20.0.1.Final (since WFLY 13.0.0.Final):
> ~~~
> public class PleaseIgnoreMeThanks
> { @EJB private NonExistentEjbExampleLocal nonExistentEjbExample; }
> ~~~
> The issue seems to be on the @EJB annotation.
>
> Generated error:
> {code:xml}
> 10:19:19,025 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."ejb-in-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-in-war.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejb-in-war.war"
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.ejbTimer.NonExistentEjbExampleLocal' for binding org.jboss.as.quickstarts.ejbTimer.PleaseIgnoreMeThanks/nonExistentEjbExample
> at org.jboss.as.ejb3@20.0.1.Final//org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:269)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:200)
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> ... 8 more
> ~~{code}
>
> !moz-extension://4f9dc55f-98eb-44f6-97f9-1c9d85f3a188/icons/logo.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months