[JBoss JIRA] (DROOLS-3608) Wrong behavior with top level collection in DMN scenario
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3608?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-3608:
-------------------------------------
Issue Type: Enhancement (was: Bug)
> Wrong behavior with top level collection in DMN scenario
> --------------------------------------------------------
>
> Key: DROOLS-3608
> URL: https://issues.jboss.org/browse/DROOLS-3608
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: dmn-list.dmn
>
>
> If you have a DMN file with a top level collection like a list of string not as field of a complex object but as top level. The type is not correctly loaded and managed.
> Top-level collection should work also in Rule scenario.
> See dmn-list.dmn as example
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11858:
----------------------------------------
[~manovotn] I see. I was investigating a bit and I haven't found the place so far. I tried with weld logging but haven't got any catch. Would you have some clue for me how to get info on all the registered beans (which can be `@Inject`ed?)
To your point about `new IntialContext()` I think it's not an issue as it's practice used on many places in the container and second there should be possibly one `JNDIBean` in container(?, I can be easily missing how the CDI handles this).
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2299:
--------------------------------
Looks like it. Not just {{Owner.compareTo()}}, but possibly also {{ClientLock.compareTo()}}?
Do you want to submit a pull request?
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.20
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11880) Add a SASL mechanism reference to the documentation
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-11880:
---------------------------------------
Summary: Add a SASL mechanism reference to the documentation
Key: WFLY-11880
URL: https://issues.jboss.org/browse/WFLY-11880
Project: WildFly
Issue Type: Task
Components: Documentation, Security
Reporter: Darran Lofthouse
Fix For: 17.0.0.Beta1
A mechanism by mechanism listing, describing the mech, any features / requirements of the mech and any properties or other configuration affecting the mech.
This will need to cover both the client and server perspectives.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months