January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-139) ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-139: --------------------------- Description: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 **UPDATE:** ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and `(char)` operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: new ByteStringBuilder(new byte[]{}); was: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates > ----------------------------------------------------------------- > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. > (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > **UPDATE:** > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and `(char)` operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > new ByteStringBuilder(new byte[]{}); -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-583) Drools WB jcr2vfs: make the migration tool work again

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-583?page=com.atlassian.jira.plugin... ] Petr Široký reassigned DROOLS-583: ---------------------------------- Assignee: Jan Schatteman (was: Petr Široký) > Drools WB jcr2vfs: make the migration tool work again > ----------------------------------------------------- > > Key: DROOLS-583 > URL: https://issues.jboss.org/browse/DROOLS-583 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta1 > Reporter: Petr Široký > Assignee: Jan Schatteman > > The current 6.2.0 SNAPSHOTS of the jcr2vfs tool are broken. There seems to some issue with incompatibility with between Drools 5.x and 6.x. > {code} > Asset [Bankruptcy history] with format [brl] is being migrated... > java.lang.ClassCastException: org.drools.core.base.accumulators.BigDecimalSumAccumulateFunction cannot be cast to org.drools.runtime.rule.AccumulateFunction > at org.drools.compiler.PackageBuilderConfiguration.loadAccumulateFunction(PackageBuilderConfiguration.java:530) > at org.drools.compiler.PackageBuilderConfiguration.buildAccumulateFunctionsMap(PackageBuilderConfiguration.java:479) > at org.drools.compiler.PackageBuilderConfiguration.init(PackageBuilderConfiguration.java:194) > at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:165) > {code} > Another very serious issue is that even when the jcr2vfs tests fail, the Jenkins drools-wb CI build succeeds. This needs to be fixed, so that when the tests fail, the build fails too. > I will try to fix the tool in time for 6.2.0.Final. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-242) VerifyError: Inconsistent args count operand in invokeinterface when boolean parameter function with inheritance

by Gurutharshan Nadarajah (JIRA)

Gurutharshan Nadarajah created JASSIST-242: ---------------------------------------------- Summary: VerifyError: Inconsistent args count operand in invokeinterface when boolean parameter function with inheritance Key: JASSIST-242 URL: https://issues.jboss.org/browse/JASSIST-242 Project: Javassist Issue Type: Bug Affects Versions: 3.19.0-GA Environment: Java 1.7, windows Reporter: Gurutharshan Nadarajah Assignee: Shigeru Chiba java.lang.VerifyError: Inconsistent args count operand in invokeinterface comes when there is a function in inheritance with boolean parameters. And if we call that function with some expression to evaluate as a boolean value. This error occurred. Error message Exception in thread "main" java.lang.VerifyError: Inconsistent args count operand in invokeinterface Exception Details: Location: Hello.say()V @22: invokeinterface Reason: Error exists in the bytecode Bytecode: 0000000: 2a2a b600 2bb5 0029 2ab4 0029 0606 a200 0000010: 0703 a700 0404 b900 3103 002a b400 29c0 0000020: 0005 0606 a200 0703 a700 0404 b600 3206 0000030: 06a2 0007 03a7 0004 043c 2ab4 0029 1bb9 0000040: 0031 0200 b200 0212 27b6 0004 b200 0212 0000050: 03b6 0004 b1 Stackmap Table: same_locals_1_stack_item_frame(@21,Object[#45]) full_frame(@22,{Object[#7]},{Object[#45],Integer}) same_locals_1_stack_item_frame(@43,Object[#5]) full_frame(@44,{Object[#7]},{Object[#5],Integer}) same_frame(@56) same_locals_1_stack_item_frame(@57,Integer) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493) at java.lang.Class.getConstructor0(Class.java:2803) at java.lang.Class.newInstance(Class.java:345) at BoolSeriesTest.main(BoolSeriesTest.java:59) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ] Rafael Benevides commented on WFLY-4171: ---------------------------------------- New repository: https://repository.jboss.org/nexus/content/repositories/jboss_releases_st... > Provide an html5 archetype for wildfly > -------------------------------------- > > Key: WFLY-4171 > URL: https://issues.jboss.org/browse/WFLY-4171 > Project: WildFly > Issue Type: Feature Request > Reporter: Fred Bricon > Assignee: Rafael Benevides > > We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are : > * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final > * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-380) Example 4.20 file logger newFileLogger

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-380?page=com.atlassian.jira.plugin... ] Petr Široký resolved DROOLS-380. -------------------------------- Assignee: Petr Široký (was: Mark Proctor) Fix Version/s: 6.2.0.Final Resolution: Done Fixed by https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/ffcb0e6f13195c7... > Example 4.20 file logger newFileLogger > -------------------------------------- > > Key: DROOLS-380 > URL: https://issues.jboss.org/browse/DROOLS-380 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Matteo Mortari > Assignee: Petr Široký > Fix For: 6.2.0.Final > > > In the documentation [1] example 4.20 mention the following code snippet. > {{KieRuntimeLogger logger = KieServices.Factory.get().newFileLogger(ksession, "logdir/mylogfile");}} > However that doesn't compile. I believe is missing a {{.getLoggers()}} so the proper snippet, I believe, was intended as > {{KieRuntimeLogger logger = KieServices.Factory.get().getLoggers().newFileLogger(ksession, "logdir/mylogfile");}} > Ciao > MM > References: > [1] http://docs.jboss.org/drools/release/6.0.0.Final/drools-docs/html_single/... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4296) remove _ds.xml deployment support

by Frank Langelage (JIRA)

[ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.... ] Frank Langelage commented on WFLY-4296: --------------------------------------- Why is this to be removed? > remove _ds.xml deployment support > --------------------------------- > > Key: WFLY-4296 > URL: https://issues.jboss.org/browse/WFLY-4296 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Fix For: No Release > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ] Rafael Benevides commented on WFLY-4171: ---------------------------------------- Ok. I'll handle it > Provide an html5 archetype for wildfly > -------------------------------------- > > Key: WFLY-4171 > URL: https://issues.jboss.org/browse/WFLY-4171 > Project: WildFly > Issue Type: Feature Request > Reporter: Fred Bricon > Assignee: Rafael Benevides > > We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are : > * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final > * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-73) NPE in RootResourceIterator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-73?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-73: --------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1185118|https://bugzilla.redhat.com/show_bug.cgi?id=1185118] from NEW to POST > NPE in RootResourceIterator > --------------------------- > > Key: WFLY-73 > URL: https://issues.jboss.org/browse/WFLY-73 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JMX > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > Intermittent testsuite failures, e.g. > http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-param-pull/684... > Log shows this repeatedly: > [0m[33m18:38:11,612 WARN [org.jboss.remotingjmx.protocol.v2.ServerCommon] (pool-2-thread-12) Unexpected internal error: java.lang.NullPointerException > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:49) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:55) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:55) > at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:39) > at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:103) > at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:116) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:220) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:618) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13] > RootResourceIterator.doIterate is reading the resource twice: > {code} > for (ResourceEntry entry : current.getChildren(type)) { > final PathElement pathElement = entry.getPathElement(); > final Resource child = current.getChild(pathElement); // why this call since "entry" and "child" should be the same object > final PathAddress childAddress = address.append(pathElement); > doIterate(child, childAddress); > } > {code} > The problem is "child" is null, which is possible with a dynamic resource. So, either "entry" should be used, or, if there is some reason for the 2nd read, a check for null is needed before the recursive doIterate call. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-48) EOFException when address of a mgmt operation is of a bad data type

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-48?page=com.atlassian.jira.plugin.... ] Emmanuel Hugonnet commented on WFCORE-48: ----------------------------------------- Wondering in a ModelOperation must have an OP attribute defined. [~brian.stansberry] may you take a look at https://github.com/ehsavoie/wildfly-core/tree/WFCORE-48 that 'validates' the operation checking the OP_ADDRESS and OP. > EOFException when address of a mgmt operation is of a bad data type > ------------------------------------------------------------------- > > Key: WFCORE-48 > URL: https://issues.jboss.org/browse/WFCORE-48 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Assignee: Emmanuel Hugonnet > > (Hopefully this belongs to WildFly Core. If not, please move to WildFly.) > I'm doing a programmatic invocation of a simple mgmt operation on the root mgmt resource, say e.g. {{:whoami}}. I'm doing this against a freshly built WildFly from master branch (commit {{e2b9ecfb}}) and on the client side, I'm depending on {{org.wildfly.core:wildfly-controller-client:1.0.0.Alpha4}}. > The code looks like this: > {code:java} > ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990); > try { > ModelNode op = new ModelNode(); > op.get(ClientConstants.OP).set("whoami"); > op.get(ClientConstants.OP_ADDR).set(""); > ModelNode result = client.execute(op); > System.out.println(result); > } finally { > client.close(); > } > {code} > This fails with an exception like this: > {code} > Exception in thread "main" java.io.IOException: java.util.concurrent.ExecutionException: Operation failed > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at cz.ladicek.wildfly.ErrorReproducer.main(ErrorReproducer.java:17) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > Caused by: java.util.concurrent.ExecutionException: Operation failed > at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74) > at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268) > at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > ... 7 more > Caused by: java.io.EOFException > at java.io.DataInputStream.readByte(DataInputStream.java:267) > at org.jboss.as.protocol.mgmt.ProtocolUtils.expectHeader(ProtocolUtils.java:83) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient$1.handleRequest(AbstractModelControllerClient.java:167) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:270) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:235) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:113) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:56) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:84) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:452) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} > However, when I remove the line that sets {{address}} ({{op.get(ClientConstants.OP_ADDR).set("");}}), it works just fine. > Fine, I made a mistake, but getting an {{EOFException}}? That's hardly an appropriate response. I should get a proper failure ({{"outcome" => "failed"}} etc.). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3711) Topology updates of EJBClient ClusterContexts not being processed correctly after failover

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-3711?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz resolved WFLY-3711. --------------------------------------- Fix Version/s: 9.0.0.Alpha1 Resolution: Done Change was merged. > Topology updates of EJBClient ClusterContexts not being processed correctly after failover > ------------------------------------------------------------------------------------------ > > Key: WFLY-3711 > URL: https://issues.jboss.org/browse/WFLY-3711 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Fix For: 9.0.0.Alpha1 > > > ClusterContexts are used by EJBClient to keep track of the current set of nodes in a cluster, so that if an EJBClient invocation fails on one node, it may failover to another node in the same cluster. The ClusterContext is made up of ClusterNodeManagers which are responsible for setting up the connections between the EJBClient and the nodes in the cluster. > Cluster topology updates are sent to registered EJBClients whenever the cluster topology changes (nodes join, nodes leave a cluster). Thse topology updates are processed on the client side by ClusterTopologyUpdateHandler and are used to update the current contents of the associated ClusterContext held on the client. > The current implementation of the handling of topology updates does not correctly handle the addition/removal of ClusterNodeManagers from the cluster context - namely, rather than check whether or not a new ClusterNodeManager really needs to be added, ClusterNodeManagers are added for every node in the received topology update, leading to many unnecessary EJBReceivers and their channels being created. > The logs show that up to 18 cluster node manager instances may be created, have their EJBReceivers registered and channels to the remote node created, when only one node has been added to the cluster. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015