[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1982:
--------------------------------
Turns out that compaction 'in the middle' doesn't work with the current design. If we have
||0||1||2||3||4||5||6||7||
|-|-|-|-|-|21|22|23|
where low=21 and high=24.
Compacting this yield:
||0||1||2||3||
|-|21|22|23|
(low=21, high=24)
However, growing the array again yields:
||0||1||2||3||4||5||6||7||
|-|21|22|23|-|-|-|-|
(low=21, high=24)
The problem here is that we hash a _seqno_ to an _index_, but once we've done this, we don't know what the actual seqno is, and hash on the indices only. E.g. indices for 21,22,23 and 5,6,7, then 1,2,3. The root issue is that a mod operation (hash) is not bijective, ie. {{21 % 8 = 5}}, but we cannot compute the original seqno 21 from 5.
We'd have to store the original seqno with the value, but that's too much overhead...
> RequestCorrelator: use IntHashMap / LongHashmap for request correlation
> -----------------------------------------------------------------------
>
> Key: JGRP-1982
> URL: https://issues.jboss.org/browse/JGRP-1982
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2001) RequestCorrelator: request-ID is sent in request and header
by Bela Ban (JIRA)
Bela Ban created JGRP-2001:
------------------------------
Summary: RequestCorrelator: request-ID is sent in request and header
Key: JGRP-2001
URL: https://issues.jboss.org/browse/JGRP-2001
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.6.7
When invoking a sync RPC, a request is identified by a _request ID_ (req_id, a long). This is sent in both the header and the request itself, so we can remove one of them.
Also, in {{Header}}, we can drop field {{rsp_expected}}: this can be replaced by setting {{req_id}} to {{-1}}.
Summary: we can drop a long ({{req_id}}) field in {{Request}} and a boolean ({{rsp_expected}} in {{Header}}) from each RPC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1015:
-------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1294048|https://bugzilla.redhat.com/show_bug.cgi?id=1294048] from NEW to ASSIGNED
> Wrong MvelConstraint compilation with Unicode class name and the same name property
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1015
> URL: https://issues.jboss.org/browse/DROOLS-1015
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Fix For: 7.0.0.Final
>
>
> If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal.
> {code:java}
> public class I18nPerson implements Serializable {
> private 住所 住所; // "address" in Japanese
> public 住所 get住所() {
> return 住所;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( 住所 != null )
> {noformat}
> This constraint is always evaluated to "true".
> Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name.
> {code:java}
> public class Person implements Serializable {
> private Address address;
> public Address getAddress() {
> return address;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( Address != null )
> {noformat}
> Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1015:
--------------------------------
Fix Version/s: 7.0.0.Final
> Wrong MvelConstraint compilation with Unicode class name and the same name property
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1015
> URL: https://issues.jboss.org/browse/DROOLS-1015
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Fix For: 7.0.0.Final
>
>
> If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal.
> {code:java}
> public class I18nPerson implements Serializable {
> private 住所 住所; // "address" in Japanese
> public 住所 get住所() {
> return 住所;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( 住所 != null )
> {noformat}
> This constraint is always evaluated to "true".
> Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name.
> {code:java}
> public class Person implements Serializable {
> private Address address;
> public Address getAddress() {
> return address;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( Address != null )
> {noformat}
> Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1015:
-------------------------------------
I reproduced this issue in a very easy way as it follows:
{code}
public static class person {
private address address;
public Misc2Test.address getAddress() {
return address;
}
public void setAddress( Misc2Test.address address ) {
this.address = address;
}
}
public static class address { }
@Test
public void testLowerCaseClass() {
// DROOLS-1015
String drl =
"import " + person.class.getCanonicalName() + "\n" +
"import " + address.class.getCanonicalName() + "\n" +
"global java.util.List list;\n" +
"rule R when\n" +
" person( address == null )\n" +
"then\n" +
" list.add(\"ok\");\n" +
"end\n";
KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
.build()
.newKieSession();
List<String> list = new ArrayList<String>();
ksession.setGlobal( "list", list );
ksession.insert( new person() );
ksession.fireAllRules();
assertEquals( 1, list.size() );
}
{code}
The problem here is caused by mvel class literals. In practice since 'address' is also the name of an imported class mvel interprets the constraint:
person( address == null )
as it was
person( address.class == null )
That of course always evaluates to false regardless if the person has a value in its address field or not. I'm trying to fix this problem without breaking this mvel feature by changing the precedence in which mvel disambiguate the 'address' word during parsing giving a lower priority to class literals. The problem is that at the moment all literals (like constants and even class literals) are the very first thing that are resolved by mvel during the parsing of an expression. I spent a couple of hours try to change this only for class literals, but the more I try the more I realize that achieving this result could take me many days of work.
I believe that going further with this attempt doesn't worth the effort for at least 2 good reason:
1. as you know one of the goal for drools 7 is getting rid of mvel.
2. there's an easy way to disambiguate the 'address' token. In fact replacing
person( address == null )
with
person( this.address == null )
will have the expected behavior.
My expectation is that the workaround I'm suggesting in 2. will also work for your use case.
This issue will be fixed in Drools 7.
> Wrong MvelConstraint compilation with Unicode class name and the same name property
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1015
> URL: https://issues.jboss.org/browse/DROOLS-1015
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
>
> If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal.
> {code:java}
> public class I18nPerson implements Serializable {
> private 住所 住所; // "address" in Japanese
> public 住所 get住所() {
> return 住所;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( 住所 != null )
> {noformat}
> This constraint is always evaluated to "true".
> Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name.
> {code:java}
> public class Person implements Serializable {
> private Address address;
> public Address getAddress() {
> return address;
> }
> ....
> {code}
> {noformat}
> when
> p : I18nPerson( Address != null )
> {noformat}
> Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Ladislav Thon commented on WFLY-5850:
-------------------------------------
I can confirm that adding the {{bean-validation}} extension and subsystem manually solves the problem.
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Jason Greene
> Priority: Critical
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ELY-403) Add permissive mode to WildflySecurityManager to log policy exceptions but not enforce them.
by Jason Shepherd (JIRA)
[ https://issues.jboss.org/browse/ELY-403?page=com.atlassian.jira.plugin.sy... ]
Jason Shepherd edited comment on ELY-403 at 1/8/16 2:08 AM:
------------------------------------------------------------
There are these options for the JDK, but they don't help you to generate policy files because the Security Manager still forces a halt of execution at the first exception.
[http://docs.oracle.com/javase/8/docs/technotes/guides/security/troublesho...]
was (Author: jshepher):
There are these options for the JDK, but they don't help you to generate policy files because the Security Manager still forces a halt of execution at the first exception.
[#http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html]
> Add permissive mode to WildflySecurityManager to log policy exceptions but not enforce them.
> --------------------------------------------------------------------------------------------
>
> Key: ELY-403
> URL: https://issues.jboss.org/browse/ELY-403
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Security Manager
> Affects Versions: 1.1.0.Beta3
> Reporter: Jason Shepherd
> Assignee: David Lloyd
>
> If you enable the security manager the any policies in force will halt the execution of your application at the first policy violation, making creating a policy tedious. With this feature enabled a developer can enable the security manager, but also set it to permissive mode. This will result in the required policy rules being logged, making policy generation possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ELY-403) Add permissive mode to WildflySecurityManager to log policy exceptions but not enforce them.
by Jason Shepherd (JIRA)
[ https://issues.jboss.org/browse/ELY-403?page=com.atlassian.jira.plugin.sy... ]
Jason Shepherd commented on ELY-403:
------------------------------------
There are these options for the JDK, but they don't help you to generate policy files because the Security Manager still forces a halt of execution at the first exception.
[#http://docs.oracle.com/javase/8/docs/technotes/guides/security/troubleshooting-security.html]
> Add permissive mode to WildflySecurityManager to log policy exceptions but not enforce them.
> --------------------------------------------------------------------------------------------
>
> Key: ELY-403
> URL: https://issues.jboss.org/browse/ELY-403
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Security Manager
> Affects Versions: 1.1.0.Beta3
> Reporter: Jason Shepherd
> Assignee: David Lloyd
>
> If you enable the security manager the any policies in force will halt the execution of your application at the first policy violation, making creating a policy tedious. With this feature enabled a developer can enable the security manager, but also set it to permissive mode. This will result in the required policy rules being logged, making policy generation possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-5957) Unable to disable CN Check in "wildfly-8.2.0.Final"
by Karthikeyan Ramasamy (JIRA)
Karthikeyan Ramasamy created WFLY-5957:
------------------------------------------
Summary: Unable to disable CN Check in "wildfly-8.2.0.Final"
Key: WFLY-5957
URL: https://issues.jboss.org/browse/WFLY-5957
Project: WildFly
Issue Type: Bug
Affects Versions: 8.2.0.Final
Reporter: Karthikeyan Ramasamy
Assignee: Jason Greene
Priority: Critical
My application is working in wildfly-8.2.0.Final.
This application needs to access a web service that allows only SSL connections.
On posting request to webservice got "Marshalling Error: The https URL hostname does not match the Common Name (CN) on the server certificate in the client's truststore. Make sure server certificate is correct, or to disable this check (NOT recommended for production) set the CXF client TLS configuration property "disableCNCheck" to true." exception.
So i want to disable CN Check
Tried with system properties.
<system-properties>
<property name="cxf.tls-client.disableCNCheck" value="true"/>
</system-properties>.
But the same is not working.
Please help us to to disable this common name check on wildfly 8.2?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months