[JBoss JIRA] (WFCORE-4582) Cannot create user with underscores in the name
by Thorsten Heit (Jira)
[ https://issues.jboss.org/browse/WFCORE-4582?page=com.atlassian.jira.plugi... ]
Thorsten Heit commented on WFCORE-4582:
---------------------------------------
I'm normally testing my application via SoapUI, and according to the logs username and password are sent via HTTP basic authentication:
{noformat}
POST https://localhost:8443/myapp/myservice HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: "calculate"
Content-Length: 5438
Host: localhost:8443
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Authorization: Basic ....
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header>...
{noformat}
> Cannot create user with underscores in the name
> -----------------------------------------------
>
> Key: WFCORE-4582
> URL: https://issues.jboss.org/browse/WFCORE-4582
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 10.0.0.Beta2
> Reporter: Thorsten Heit
> Assignee: Jeff Mesnil
> Priority: Minor
>
> On a fresh a Wildfly install (tested on 11.0.0.Final and 17.0.0.Final) I cannot create application users with underscores in the user name:
> {noformat}
> C:\Users\thorsten\bin\wildfly-11.0.0.Final\bin>add-user
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by __redirected.__SAXParserFactory (file:/C:/Users/thorsten/bin/wildfly-11.0.0.Final/jboss-modules.jar) to c
> onstructor com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl()
> WARNING: Please consider reporting this to the maintainers of __redirected.__SAXParserFactory
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): b
> Enter the details of the new user to add.
> Using realm 'ApplicationRealm' as discovered from the existing property files.
> Username : user_name
> * Error *
> WFLYDM0028: Username must be alphanumeric with the exception of the following accepted symbols (",", "-", ".", "/", "=", "@", "\")
> Username (user_name) :
> {noformat}
> We use basic authentification to restrict access to our applications, and expect usernames in the format {{<prefix>\_<suffix>}} with {{<prefix>}} being a sequence of plain letters (a-z), followed by an underscore ("\_") and a number as {{<suffix>}}.
> This is possible with WebSphere and even Tomcat, but actually not in Wildfly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2327?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2327:
---------------------------
Fix Version/s: 4.1.3
(was: 4.1.2)
> UNICAST3: create receiver table when non-first message is received first
> ------------------------------------------------------------------------
>
> Key: JGRP-2327
> URL: https://issues.jboss.org/browse/JGRP-2327
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.3
>
>
> * A and B
> * B sends 2 messages to A: B1 and B2
> * A receives B2 _before_ B1 (both B1 and B2 are OOB)
> * The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
> * B resends B1, but _not_ B2
> * Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
> h4. Scenario (JGRP-2293):
> * A installs a new view
> * B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
> * The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
> * This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
> h4. Workaround
> * Set GMS.leave_timeout to a higher value (say 8000ms)
> h4. Solution
> * When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
> * However, this requires the first seqno from B *to always be 0*
> --> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (JGRP-2365) Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2365?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2365:
--------------------------------
I assumed that the bottom-most protocol (used for finding out the IP version of the running stack) is always a _transport_. This may not be true for fork stacks.
I changed this to be optional, based on the type of the bottom-most protocol.
> Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
> -----------------------------------------------------------------
>
> Key: JGRP-2365
> URL: https://issues.jboss.org/browse/JGRP-2365
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0, 4.1.1
> Reporter: Bernd Laengerich
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.2
>
> Attachments: fork-stacks.xml, tcp_fork.xml
>
>
> Updating from 4.0.20 to 4.1.1 I get
> "java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP"
> when creating a JChannel using the same config as before. My config is [^tcp_fork.xml] attached to this issue. The stack trace:
> {noformat}
> java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP
> at org.jgroups.stack.Configurator.createProtocolsAndInitializeAttrs(Configurator.java:110) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:273) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:265) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.init(FORK.java:100) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:857) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:480) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.init(JChannel.java:952) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:125) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:107) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at com.acceptis.accept.jgroups.config.JGroupsConfigurator.setConfiguration(JGroupsConfigurator.java:86) [main/:?]
> at com.acceptis.framework.locking.impl.test.JGroupsLockManagerTest.setUp(JGroupsLockManagerTest.java:40) [test/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (JGRP-2365) Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2365?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2365.
----------------------------
Resolution: Done
> Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
> -----------------------------------------------------------------
>
> Key: JGRP-2365
> URL: https://issues.jboss.org/browse/JGRP-2365
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0, 4.1.1
> Reporter: Bernd Laengerich
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.2
>
> Attachments: fork-stacks.xml, tcp_fork.xml
>
>
> Updating from 4.0.20 to 4.1.1 I get
> "java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP"
> when creating a JChannel using the same config as before. My config is [^tcp_fork.xml] attached to this issue. The stack trace:
> {noformat}
> java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP
> at org.jgroups.stack.Configurator.createProtocolsAndInitializeAttrs(Configurator.java:110) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:273) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:265) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.init(FORK.java:100) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:857) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:480) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.init(JChannel.java:952) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:125) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:107) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at com.acceptis.accept.jgroups.config.JGroupsConfigurator.setConfiguration(JGroupsConfigurator.java:86) [main/:?]
> at com.acceptis.framework.locking.impl.test.JGroupsLockManagerTest.setUp(JGroupsLockManagerTest.java:40) [test/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (JGRP-2365) Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2365?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2365:
---------------------------
Fix Version/s: 4.1.2
> Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
> -----------------------------------------------------------------
>
> Key: JGRP-2365
> URL: https://issues.jboss.org/browse/JGRP-2365
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0, 4.1.1
> Reporter: Bernd Laengerich
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.2
>
> Attachments: fork-stacks.xml, tcp_fork.xml
>
>
> Updating from 4.0.20 to 4.1.1 I get
> "java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP"
> when creating a JChannel using the same config as before. My config is [^tcp_fork.xml] attached to this issue. The stack trace:
> {noformat}
> java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP
> at org.jgroups.stack.Configurator.createProtocolsAndInitializeAttrs(Configurator.java:110) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:273) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:265) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.init(FORK.java:100) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:857) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:480) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.init(JChannel.java:952) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:125) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:107) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at com.acceptis.accept.jgroups.config.JGroupsConfigurator.setConfiguration(JGroupsConfigurator.java:86) [main/:?]
> at com.acceptis.framework.locking.impl.test.JGroupsLockManagerTest.setUp(JGroupsLockManagerTest.java:40) [test/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (DROOLS-4381) BigDecimal and primitive comparison error in executable-model build
by Toshiya Kobayashi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4381?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-4381:
--------------------------------------
Git Pull Request: https://github.com/kiegroup/drools/pull/2482
> BigDecimal and primitive comparison error in executable-model build
> -------------------------------------------------------------------
>
> Key: DROOLS-4381
> URL: https://issues.jboss.org/browse/DROOLS-4381
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.24.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> When you compare BigDecimal (but the field type is Object) with primitive int,
> {noformat}
> import org.drools.modelcompiler.domain.Result;
> rule "rule1"
> when
> $r : Result( value <= 20 )
> then
> end
> {noformat}
> executable-model build fails.
> {noformat}
> [ERROR] Failures:
> [ERROR] CompilerTest.testBigDecimalIntCoercion:1901->BaseModelTest.getKieSession:99->BaseModelTest.getKieSession:103->BaseModelTest.getKieContainer:107->BaseModelTest.getKieContainer:114->BaseModelTest.createKieBuilder:125->BaseModelTest.createKieBuilder:152 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=24, column=122
> text=no suitable method found for lessOrEqualNumbers(java.lang.Object,int)
> method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Number,java.lang.Number) is not applicable
> (argument mismatch; java.lang.Object cannot be converted to java.lang.Number)
> method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Long,java.lang.Long) is not applicable
> (argument mismatch; java.lang.Object cannot be converted to java.lang.Long)], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=0, column=0
> text=Java source of src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java in error:
> {noformat}
> Non executable-model works with the rule.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (DROOLS-4381) BigDecimal and primitive comparison error in executable-model build
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-4381:
-----------------------------------------
Summary: BigDecimal and primitive comparison error in executable-model build
Key: DROOLS-4381
URL: https://issues.jboss.org/browse/DROOLS-4381
Project: Drools
Issue Type: Bug
Components: executable model
Affects Versions: 7.24.0.Final
Reporter: Toshiya Kobayashi
Assignee: Luca Molteni
When you compare BigDecimal (but the field type is Object) with primitive int,
{noformat}
import org.drools.modelcompiler.domain.Result;
rule "rule1"
when
$r : Result( value <= 20 )
then
end
{noformat}
executable-model build fails.
{noformat}
[ERROR] Failures:
[ERROR] CompilerTest.testBigDecimalIntCoercion:1901->BaseModelTest.getKieSession:99->BaseModelTest.getKieSession:103->BaseModelTest.getKieContainer:107->BaseModelTest.getKieContainer:114->BaseModelTest.createKieBuilder:125->BaseModelTest.createKieBuilder:152 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=24, column=122
text=no suitable method found for lessOrEqualNumbers(java.lang.Object,int)
method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Number,java.lang.Number) is not applicable
(argument mismatch; java.lang.Object cannot be converted to java.lang.Number)
method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Long,java.lang.Long) is not applicable
(argument mismatch; java.lang.Object cannot be converted to java.lang.Long)], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=0, column=0
text=Java source of src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java in error:
{noformat}
Non executable-model works with the rule.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFLY-11328) EE Concurency Utilities "hung-task-threshold" / "long-running-tasks" do not work and are not implemented as explained
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11328?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-11328:
--------------------------------------
I did a quick search in the spec and it says:
{quote}
*3.2.5 System Administrator’s Responsibilities*
The System Administrator (EE.2.110.5) is responsible for monitoring and overseeing the runtime environment.
In the scope of this specification, these duties may include:
* Monitoring for hung tasks.
* Monitoring resource usage (for example, threads and memory).
{quote}
It doesn't indicate how an administrator would do that or the fact that it's required to monitor for a hung thread. Deprecation is the simplest approach IMO.
Another option would be to extend or expose the {{ManagedThread.isTaskHun()}} in a custom {{Future}} and leave the checking up to the user.
> EE Concurency Utilities "hung-task-threshold" / "long-running-tasks" do not work and are not implemented as explained
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11328
> URL: https://issues.jboss.org/browse/WFLY-11328
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Priority: Major
>
> ee subsystem parameters "hung-task-threshold" and "long-running-tasks" for managed-executor-service / managed-scheduled-executor-service do not work and are not implemented as described in [EAP 7 Development Guide|https://access.redhat.com/documentation/en-us/red_hat_jboss_enterpr...]:
> - hung-task-threshold: Defines the time, in milliseconds, after which tasks are considered hung by the managed executor service and forcefully aborted. If the value is 0 (which is the default), tasks are never considered hung.
> - long-running-tasks: Suggests optimizing the execution of long running tasks, and defaults to false.
> I tested with [EAP 7 QuickStarts managed-executor-service example|https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.0...] but these paremeters doe not take any effect:
> - tasks exceeding hung-task-threshold are never forcefully aborted. And there's no way to detect hung tasks exceeding hung-task-threshold.
> - setting long-running-tasks to true does not change the behavior.
> As far as I checked the source code, I noticed the following:
> - EAP 7.x uses the EE Concurency Utilities RI [org.glassfish.enterprise.concurrent|https://github.com/javaee/cu-ri] internally and just passes the paramters to the RI.
> - In the EE Concurency Utilities RI, these parameters are used in the methods [ManagedThreadFactoryImpl#isTaskHung(long now)|https://github.com/javaee/cu-ri/blob/master/src/main/java/org/glassf...], [AbstractManagedExecutorService#getHungThreads()|https://github.com/javaee...] and [AbstractManagedExecutorService#isLongRunningTasks()|https://github.com/ja...] (AbstractManagedExecutorService is the parent class of ManagedExecutorServiceImpl / ManagedScheduledExecutorServiceImpl).
> - However, these methods are never invoked from EAP 7.x. So, these parameters do not take any effect in EAP 7.x.
> - In addition, even if these methods are used, it looks the implementation is totally different from the description in the documentation. The parameter "long-running-tasks" is just used as a flag to skip from checking hung thread detection. And the parameter "hung-task-threshold" never forcefully abort the hung thread exceeding the threshold.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months