[JBoss JIRA] (ELY-1890) Keep file permissions when modifying an existing credential store
by Ingo Weiss (Jira)
[ https://issues.jboss.org/browse/ELY-1890?page=com.atlassian.jira.plugin.s... ]
Ingo Weiss updated ELY-1890:
----------------------------
Issue Type: Bug (was: Feature Request)
> Keep file permissions when modifying an existing credential store
> -----------------------------------------------------------------
>
> Key: ELY-1890
> URL: https://issues.jboss.org/browse/ELY-1890
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Command-Line Tool
> Affects Versions: 1.11.0.CR1
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Priority: Major
>
> Using the offline elytron.sh tool, after creating the credential store I changed the mode to 600. Using the elytron.sh tool to add credentials changes the mode back to 644. Is that intentional for it to automatically do that? I would either expect it to not change and update or not change and error out.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
2 years, 6 months
[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-3948?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-3948 at 11/27/19 10:21 AM:
---------------------------------------------------------------------
All of my above discussion is wrong; all that's needed is for AttachmentList to be thread safe.
Why?
All writes occur in Phase STRUCTURE.
The DeploymentUnitPhaseService for the STRUCTURE Phase for the top level deployment installs all the SubDeploymentUnitService instances. It's a general rule that any service has a dep on the service that installed it, so that means any SubDeploymentUnitService will not start until the top level deployment has completed STRUCTURE phase and thus will see all its data.
Within the STRUCTURE phase, the subdeployments don't care about the data from other subdeployments.
SubDeploymentProcessor adds a dep on the STRUCTURE phase for each subdeployment to the top level deployment's PARSE phase. So all the subdeployments will have completed STRUCTURE before the top begins PARSE work. All the writes happen in STRUCTURE so they will be complete. All the reads after STRUCTURE are either by the top level deployment, which waits for the writes, or by subdeployments which are not concerned with any writes by other subdeployments.
was (Author: brian.stansberry):
All of my above discussion is wrong; all that's needed is for AttachmentList to be thread safe.
Why?
The DeploymentUnitPhaseService for the STRUCTURE Phase for the top level deployment installs all the SubDeploymentUnitService instances. It's a general rule that any service has a dep on the service that installed it, so that means any SubDeploymentUnitService will not start until the top level deployment has completed STRUCTURE phase and will see all its data.
Within the STRUCTURE phase, the subdeployments don't care about the data from other subdeployments.
SubDeploymentProcessor adds a dep on the STRUCTURE phase for each subdeployment to the top level deployment's PARSE phase. So all the subdeployments will have completed STRUCTURE before the top begins PARSE work. All the writes happen in STRUCTURE so they will be complete. All the reads after STRUCTURE are either by the top level deployment, which waits for the writes, or by subdeployments which are not concerned with any writes by other subdeployments.
> Potential race condition on deployment of EAR when Class-Path manifest entry is in use
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-3948
> URL: https://issues.jboss.org/browse/WFCORE-3948
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Stuart Douglas
> Assignee: Brian Stansberry
> Priority: Major
>
> Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
2 years, 6 months
[JBoss JIRA] (WFCORE-4763) interface "any" tag not working as expected
by Yann Le Tallec (Jira)
[ https://issues.jboss.org/browse/WFCORE-4763?page=com.atlassian.jira.plugi... ]
Yann Le Tallec edited comment on WFCORE-4763 at 11/27/19 10:11 AM:
-------------------------------------------------------------------
Thank you for your comment.
The doc says "Attribute indicating that part of the selection criteria for choosing an IP address for this interface should be that *the IP address meets at least one of a nested set of criteria, but not necessarily all of the nested criteria*." So it seems to me that connections from any of the addresses inside any should be accepted.
In the end my goal is simple: I want the management interface to be accessible from localhost and the local network. So I tried:
<any>
<inet-address value="127.0.0.1">
<subnet-match value="10.20.0.0/16">
</any>
but that doesn't work as explained in the issue.
If you have a workaround I'm happy to try it.
was (Author: assylias):
Thank you for your comment.
The doc says "Attribute indicating that part of the selection criteria for choosing an IP address for this interface should be that ***the IP address meets at least one of a nested set of criteria, but not necessarily all of the nested criteria***." So it seems to me that connections from any of the addresses inside any should be accepted.
In the end my goal is simple: I want the management interface to be accessible from localhost and the local network. So I tried:
<any>
<inet-address value="127.0.0.1">
<subnet-match value="10.20.0.0/16">
</any>
but that doesn't work as explained in the issue.
If you have a workaround I'm happy to try it.
> interface "any" tag not working as expected
> -------------------------------------------
>
> Key: WFCORE-4763
> URL: https://issues.jboss.org/browse/WFCORE-4763
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Environment: Ubuntu 18.02
> Reporter: Yann Le Tallec
> Priority: Major
>
> The {{<any>}} tag in the {{interface}} configuration of {{standalone.xml}} should accept any connection that matches ANY of the provided rules. This is not the case as demonstrated by the example below.
> This configuration allows to run {{jboss-cli.sh -c}} from the machine where wildfly is running as expected:
> {code:xml}
> <interfaces>
> <interface name="management">
> <any>
> <inet-address value="127.0.0.1"/>
> </any>
> </interface>
> </interfaces>
> {code}
> But if I add another (VALID) IP address inside the any tag, I can't connect any more:
> {code:xml}
> <interfaces>
> <interface name="management">
> <any>
> <inet-address value="127.0.0.1"/>
> <inet-address value="10.20.230.26"/>
> </any>
> </interface>
> </interfaces>
> {code}
> With the latter configuration, {{connect}} fails with the following error:
> {noformat}
> >The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: Connection refused
> {noformat}
> Note: to easily reproduce the problem from the cli, starting from a fresh standalone install:
> {code:bash}
> connect
> /interface=management:undefine-attribute(name=inet-address)
> /interface=management:undefine-attribute(name=any)
> /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1]})
> reload
> /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1,10.20.230.26]})
> reload
> {code}
> Notes:
> - 10.20.230.26 must be a reachable IP - if I use a random one I can connect normally.
> - if I use {{subnet-match}} I get the same issue
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
2 years, 6 months
[JBoss JIRA] (WFCORE-4763) interface "any" tag not working as expected
by Yann Le Tallec (Jira)
[ https://issues.jboss.org/browse/WFCORE-4763?page=com.atlassian.jira.plugi... ]
Yann Le Tallec commented on WFCORE-4763:
----------------------------------------
Thank you for your comment.
The doc says "Attribute indicating that part of the selection criteria for choosing an IP address for this interface should be that ***the IP address meets at least one of a nested set of criteria, but not necessarily all of the nested criteria***." So it seems to me that connections from any of the addresses inside any should be accepted.
In the end my goal is simple: I want the management interface to be accessible from localhost and the local network. So I tried:
<any>
<inet-address value="127.0.0.1">
<subnet-match value="10.20.0.0/16">
</any>
but that doesn't work as explained in the issue.
If you have a workaround I'm happy to try it.
> interface "any" tag not working as expected
> -------------------------------------------
>
> Key: WFCORE-4763
> URL: https://issues.jboss.org/browse/WFCORE-4763
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Environment: Ubuntu 18.02
> Reporter: Yann Le Tallec
> Priority: Major
>
> The {{<any>}} tag in the {{interface}} configuration of {{standalone.xml}} should accept any connection that matches ANY of the provided rules. This is not the case as demonstrated by the example below.
> This configuration allows to run {{jboss-cli.sh -c}} from the machine where wildfly is running as expected:
> {code:xml}
> <interfaces>
> <interface name="management">
> <any>
> <inet-address value="127.0.0.1"/>
> </any>
> </interface>
> </interfaces>
> {code}
> But if I add another (VALID) IP address inside the any tag, I can't connect any more:
> {code:xml}
> <interfaces>
> <interface name="management">
> <any>
> <inet-address value="127.0.0.1"/>
> <inet-address value="10.20.230.26"/>
> </any>
> </interface>
> </interfaces>
> {code}
> With the latter configuration, {{connect}} fails with the following error:
> {noformat}
> >The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: Connection refused
> {noformat}
> Note: to easily reproduce the problem from the cli, starting from a fresh standalone install:
> {code:bash}
> connect
> /interface=management:undefine-attribute(name=inet-address)
> /interface=management:undefine-attribute(name=any)
> /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1]})
> reload
> /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1,10.20.230.26]})
> reload
> {code}
> Notes:
> - 10.20.230.26 must be a reachable IP - if I use a random one I can connect normally.
> - if I use {{subnet-match}} I get the same issue
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
2 years, 6 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-12815?page=com.atlassian.jira.plugin... ]
Matěj Novotný edited comment on WFLY-12815 at 11/27/19 10:00 AM:
-----------------------------------------------------------------
Quickly reading this issue (going to read it some more for sure), I'd like to comment on your second point.
{quote}(2) Program in your WAR application a sessionDestroyed listener that will be broken.
In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break{quote}
CDI spec is not clear on the order in which these are destroyed, or more precisely on whether you can rely on certain scope being active during destruction of another scope. Weld (at least in WildFly) tries to destroy scopes with "shorter life span" first meaning request scope gets destroyed before session scope which in turn goes before application scope (if you are shutting down app). Hence the behavior you see; it's actually inteded. I am not sure if weblogic added some manual scope activation, but to me it seems logical the way I described it above so that req. context cannot "outlive" session context.
Since you already played with this quite a lot, do you happen to have a reproducer project to share?
I also find it weird that there are two session contexts active because the way {{HttpSessionDestructionContext}} gets activated is visible [here|https://github.com/weld/core/blob/master/modules/web/src/main/java/o...]. It should only happen in case there is no session context already. Also take a glance at the javadoc of this class which explains how and why its done.
The actual on/off toggling of http contexts is done via [WeldInitialListener|https://github.com/weld/core/blob/master/modules/web/...] which delegates most logic to [HttpContextLifecycle|https://github.com/weld/core/blob/master/modules/web/src/main/java/org/jboss/weld/module/web/servlet/HttpContextLifecycle.java].
Now, if I understood the problem, then the situation will only happen if you deliberately try and "corrupt" all the threads by using inactive scopes on them and them you try and start new session on one of those threads. That's pretty fishy code in the first place, but we should still look into why this happens.
If you have the reproducer, then [this is where {{HttpSessionDestructionContext}} gets destroyed|https://github.com/weld/core/blob/master/modules/web/src/main/j...]. The possible issue could be the ordering of {{WeldInitialListener}} and {{WeldTerminalListener}} - basically you need {{WeldTerminalListener}} to be the last registered and hence first invoked; this will get you the special context activated. Then, after some other optional listeners, comes {{WeldInitialListener}} (registered first, called last) that will attempt to terminate this special context.
At least that's how I understand it from a glance into the code, if you toss me a reproducer, I'll try and go deeper.
Meanwhile, I'll try to dig up where WFLY registers those listeners.
EDIT: In WFLY, those listeners are register in [{{WebIntegrationProcessor}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/WebIntegrationProcessor.java] and that seems to be done in correct way.
was (Author: manovotn):
Quickly reading this issue (going to read it some more for sure), I'd like to comment on your second point.
{quote}(2) Program in your WAR application a sessionDestroyed listener that will be broken.
In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break{quote}
CDI spec is not clear on the order in which these are destroyed, or more precisely on whether you can rely on certain scope being active during destruction of another scope. Weld (at least in WildFly) tries to destroy scopes with "shorter life span" first meaning request scope gets destroyed before session scope which in turn goes before application scope (if you are shutting down app). Hence the behavior you see; it's actually inteded. I am not sure if weblogic added some manual scope activation, but to me it seems logical the way I described it above so that req. context cannot "outlive" session context.
Since you already played with this quite a lot, do you happen to have a reproducer project to share?
I also find it weird that there are two session contexts active because the way {{HttpSessionDestructionContext}} gets activated is visible [here|https://github.com/weld/core/blob/master/modules/web/src/main/java/o...]. It should only happen in case there is no session context already. Also take a glance at the javadoc of this class which explains how and why its done.
The actual on/off toggling of http contexts is done via [WeldInitialListener|https://github.com/weld/core/blob/master/modules/web/...] which delegates most logic to [HttpContextLifecycle|https://github.com/weld/core/blob/master/modules/web/src/main/java/org/jboss/weld/module/web/servlet/HttpContextLifecycle.java].
Now, if I understood the problem, then the situation will only happen if you deliberately try and "corrupt" all the threads by using inactive scopes on them and them you try and start new session on one of those threads. That's pretty fishy code in the first place, but we should still look into why this happens.
If you have the reproducer, then [this is where {{HttpSessionDestructionContext}} gets destroyed|https://github.com/weld/core/blob/master/modules/web/src/main/j...]. The possible issue could be the ordering of {{WeldInitialListener}} and {{WeldTerminalListener}} - basically you need {{WeldTerminalListener}} to be the last registered and hence first invoked; this will get you the special context activated. Then, after some other optional listeners, comes {{WeldInitialListener}} (registered first, called last) that will attempt to terminate this special context.
At least that's how I understand it from a glance into the code, if you toss me a reproducer, I'll try and go deeper.
Meanwhile, I'll try to dig up where WFLY registers those listeners.
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.jboss.org/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
2 years, 6 months
[JBoss JIRA] (DROOLS-4816) CLONED Enable importing DMN object based on MS Excel source file
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-4816?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-4816:
----------------------------------
Reporter: Seth Ross (was: Matteo Mortari)
> CLONED Enable importing DMN object based on MS Excel source file
> ----------------------------------------------------------------
>
> Key: DROOLS-4816
> URL: https://issues.jboss.org/browse/DROOLS-4816
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Reporter: Seth Ross
> Assignee: Matteo Mortari
> Priority: Major
> Labels: drools-tools
> Attachments: 191001_XLS-to-DMN-01.xlsx
>
>
> UseCase:
> Business user creates a decision table in MS Excel and IMPORTS it to Business Central as a DMN object (not as DRL / Excel object).
> Why? The business people are used to work with MS Excel - and honestly: to create and maintain larger (> 10 columns && > 10 rows) decision tables is far more "smooth"/"efficient" in Excel than in Business Central DMN designer (even after the actual flaws (need to "click" on every cell to edit it; not possible to move across the table using keyboard (TAB)) will by repaired, the user-friendliness of the DMN designer can not surpass Excel).
> /*
> The as-is DMN module of Business Central can not be practically used: the business users / anaylsts will simply not click-by-click the real-life decision tables in the DMN designer.
> an experiment with https://github.com/camunda/camunda-dmn-xlsx din´t work: the import of the "camunda" produced DMN file to Business Central works OK (i.e. one can see and edit the decision table), yet the project CAN´T be BUILT.
> */
> Example MS Excel source file attached.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
2 years, 6 months