September 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-167) Inaccurate comparison because of String to Double coercion

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-167?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-167: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> made a comment on [bug 974364|https://bugzilla.redhat.com/show_bug.cgi?id=974364] Verified on BRMS 6.0.0-ER2. > Inaccurate comparison because of String to Double coercion > ---------------------------------------------------------- > > Key: DROOLS-167 > URL: https://issues.jboss.org/browse/DROOLS-167 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Beta3 > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Fix For: 5.5.1.Final, 6.0.0.Beta4 > > > If you compare String fields which consist of many digits, it may be wrongly evaluated due to String to Double coercion and Double's inaccuracy. > The following test doesn't fire the rule. > {code:java} > import org.drools.compiler.Person; > rule R1 > when > $p : Person( name < "90201304122000000000000017" ) > then > end > {code} > {code:java} > ksession.insert( new Person( "90201304122000000000000015", 38 ) ); > {code} > In Drools 6.0.0.beta3, the coercion is done by org.mvel2.math.MathProcessor > {code:java} > public strictfp class MathProcessor { > ... > private static Object _doOperations(int type1, Object val1, int operation, int type2, Object val2) { > if (operation < 20) { > if (((type1 > 49 || operation == EQUAL || operation == NEQUAL) && type1 == type2) || > (isIntegerType(type1) && isIntegerType(type2) && operation >= BW_AND && operation <= BW_NOT)) { > return doOperationsSameType(type1, val1, operation, val2); > } > else if ((type1 > 99 && (type2 > 99)) > || (operation != 0 && isNumber(val1) && isNumber(val2))) { > return doPrimWrapperArithmetic(getNumber(val1, type1), > operation, > getNumber(val2, type2), true, box(type2) > box(type1) ? box(type2) : box(type1)); > } > ... > private static Double getNumber(Object in, int type) { > if (in == null) > return 0d; > switch (type) { > ... > case DataTypes.STRING: > return Double.parseDouble((String) in); > ... > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1419) Overrides REST Response Object on Status 404

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1419?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1419: ----------------------------------------------- Weinan Li <weli(a)redhat.com> made a comment on [bug 968572|https://bugzilla.redhat.com/show_bug.cgi?id=968572] Verified that this bug is not fixed in jboss-as-7.3.0-internal-SNAPSHOT (EAP 6.2.0) Verified that this bug is fixed in wildfly-8.0.0.Beta1-SNAPSHOT > Overrides REST Response Object on Status 404 > -------------------------------------------- > > Key: WFLY-1419 > URL: https://issues.jboss.org/browse/WFLY-1419 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Alpha1 > Environment: JBoss AS 7.1.1, JBoss EAP 6.1.0, WildFly 8.0.0.Alpha1 > Linux, Java 1.7 > Reporter: Aslak Knutsen > Assignee: Stuart Douglas > Fix For: 8.0.0.Alpha2 > > > *Given*: > {code:title=JAX-RS Resource Code} > @Path("/conference") > public class ConferenceResource implements Resource { > private static final String BASE_MEDIA_TYPE = "application/vnd.ced+xml"; > private static final String CONFERENCE_MEDIA_TYPE = BASE_MEDIA_TYPE + ";type=conference"; > private static final String SESSION_MEDIA_TYPE = BASE_MEDIA_TYPE + ";type=session"; > ... > @GET > @Path("/{id}") > @Produces("application/vnd.ced+xml") > public Response get(@PathParam("id") String id) { > Conference conference = repository.get(id); > if(conference == null) { > return Response.status(Status.NOT_FOUND).type(CONFERENCE_MEDIA_TYPE).build(); > } > return Response.ok( > new ConferenceRepresentation(conference, uriInfo.getAbsolutePathBuilder())) > .type(CONFERENCE_MEDIA_TYPE).build(); > } > ... > } > {code} > *Then*: > The Body and MediaType is overwritten by the WebContainer and standard text/html Error Page is returned. > {code:title=Wire Log} > DEBUG [org.apache.http.wire] >> "GET /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]" > DEBUG [org.apache.http.wire] >> "Accept: application/vnd.ced+xml;type=conference[\r][\n]" > DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]" > DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]" > DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]" > DEBUG [org.apache.http.wire] >> "[\r][\n]" > DEBUG [org.apache.http.wire] << "HTTP/1.1 200 OK[\r][\n]" > DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]" > DEBUG [org.apache.http.wire] << "Content-Type: application/vnd.ced+xml;type=conference[\r][\n]" > DEBUG [org.apache.http.wire] << "Content-Length: 422[\r][\n]" > DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:54:22 GMT[\r][\n]" > DEBUG [org.apache.http.wire] << "[\r][\n]" > DEBUG [org.apache.http.wire] << "<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns3:conference xmlns:ns2="urn:ced:link" xmlns:ns3="urn:ced:conference"><ns2:link href="http://127.0.0.1:8080/c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference..." rel="session"/><end>2013-05-29T04:54:22.213+02:00</end><name>Test</name><start>2013-05-29T04:54:22.213+02:00</start><tagLine>Tagline</tagLine></ns3:conference>" > DEBUG [org.apache.http.wire] >> "DELETE /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]" > DEBUG [org.apache.http.wire] >> "Accept: */*[\r][\n]" > DEBUG [org.apache.http.wire] >> "Content-Length: 0[\r][\n]" > DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]" > DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]" > DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]" > DEBUG [org.apache.http.wire] >> "[\r][\n]" > DEBUG [org.apache.http.wire] << "HTTP/1.1 204 No Content[\r][\n]" > DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]" > DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:55:44 GMT[\r][\n]" > DEBUG [org.apache.http.wire] << "[\r][\n]" > DEBUG [org.apache.http.wire] >> "GET /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]" > DEBUG [org.apache.http.wire] >> "Accept: application/vnd.ced+xml;type=conference[\r][\n]" > DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]" > DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]" > DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]" > DEBUG [org.apache.http.wire] >> "[\r][\n]" > DEBUG [org.apache.http.wire] << "HTTP/1.1 404 Not Found[\r][\n]" > DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]" > DEBUG [org.apache.http.wire] << "Content-Type: text/html;charset=utf-8[\r][\n]" > DEBUG [org.apache.http.wire] << "Content-Length: 956[\r][\n]" > DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:55:45 GMT[\r][\n]" > DEBUG [org.apache.http.wire] << "[\r][\n]" > DEBUG [org.apache.http.wire] << "<html><head><title>JBoss Web/7.0.13.Final - Error report</title><style></style> </head><body><h1>HTTP Status 404 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested resource () is not available.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></htm! l>" > HTTP/1.1 404 Not Found > Server=Apache-Coyote/1.1 > Content-Type=text/html;charset=utf-8 > Content-Length=956 > Date=Wed, 29 May 2013 02:55:45 GMT > <html xmlns="http://www.w3.org/1999/xhtml"> > <head> > <title> > JBoss Web/7.0.13.Final - Error report > </title> > <style> >  > </style> > </head> > <body> > <h1> > HTTP Status 404 - > </h1> > <hr noshade="noshade" size="1"/> > <p> > <b> > type > </b> > Status report > </p> > <p> > <b> > message > </b> > <u/> > </p> > <p> > <b> > description > </b> > <u> > The requested resource () is not available. > </u> > </p> > <hr noshade="noshade" size="1"/> > <h3> > JBoss Web/7.0.13.Final > </h3> > </body> > </html> > {code} > *Expected*: Return the JAX-RS Response Object as defined by the JAX-RS Service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-208) Build 5.6.0-SNAPSHOT on jenkins and prepare for 5.6.0.Final release

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-208?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer commented on DROOLS-208: ----------------------------------------------- Jenkins View Drools 5.6.x, jBPM 5.5.x created. > Build 5.6.0-SNAPSHOT on jenkins and prepare for 5.6.0.Final release > ------------------------------------------------------------------- > > Key: DROOLS-208 > URL: https://issues.jboss.org/browse/DROOLS-208 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Davide Sottara > Assignee: Michael Biarnes Kiefer > > Requirements: > 1) All repositories in the 5.6.x repository-list need to be branched from 5.5.x. > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/5.6.x/scrip... > Note: the repository list is far less than master (so you can safely ignore uberfire etc). > Warning 1: some repo's are already branched! Do not rebranch these: droolsjbpm-build-bootstrap, droolsjbpm-knowledge, drools > Warning 2: You need to branch from 5.5.x (NOT master!) to this new branch 5.6.x > Warning 3: jbpm uses different version numbering. You need to branch from jbpm 5.4.x to 5.5.x (NOT 5.6.x). All other repo's use the normal version. > 2) All the 5.6.x branches (and 5.5.x for jbpm)'s versions need to change from 5.5.1-SNAPSHOT to 5.6.0-SNAPSHOT (and from 5.4.0-SNAPSHOT to 5.5.0-SNAPSHOT for jbpm). > Note: droolsjbpm-tools's will need changes from 5.5.1.qualifier to 5.6.0.qualifier > 3) Create a new jenkins view for "drools 5.6.x and jbpm 5.5.x" > 4) Clone the 5.5.x jobs for all these repo's as 5.6.x jobs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1324) Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step

by licheng cheng (JIRA)

[ https://issues.jboss.org/browse/JBREM-1324?page=com.atlassian.jira.plugin... ] licheng cheng updated JBREM-1324: --------------------------------- Attachment: SerializableInputStream.java > Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step > ------------------------------------------------------------------------------------------------------------------- > > Key: JBREM-1324 > URL: https://issues.jboss.org/browse/JBREM-1324 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: marshall > Affects Versions: 2.2.2.SP10 > Environment: WindowsXP + jdk1.6 > Reporter: licheng cheng > Fix For: 2.2.2.SP10 > > Attachments: SerializableInputStream.java > > > In our stateless EJB, there is one API defined as below. > public void modelSave(SerializableInputStream model) throws java.rmi.RemoteException; > The SerializableInputStream is defined as below and its whole definition is attached. The intent of defining such class is that sometimes we need to pass through large object (its content may be more than 300M) as parameter to remote ejb, while the -Xmx of the JVM is only 512M by default. With such serializable inputstream, expect JBoss not to load the whole object into JVM before invoking ejb method to avoid the OutOfMemoryError issue. > public class SerializableInputStream extends InputStream implements Serializable { > private InputStream stream; > .... > //---------------------------< Serializable >------------------------------- > private void writeObject(ObjectOutputStream out) > throws IOException { > byte[] buffer = new byte[4096]; > int bytes; > while ((bytes = stream.read(buffer)) >= 0) { > // Write a segment of the input stream > if (bytes > 0) { > // just to ensure that no 0 is written > out.writeInt(bytes); > out.write(buffer, 0, bytes); > } > } > // Write the end of stream marker > out.writeInt(0); > // close stream > stream.close(); > } > private void readObject(ObjectInputStream in) > throws IOException { > final File file = File.createTempFile("serializable-stream", "bin"); > OutputStream out = new FileOutputStream(file); > byte[] buffer = new byte[4096]; > for (int bytes = in.readInt(); bytes > 0; bytes = in.readInt()) { > if (buffer.length < bytes) { > buffer = new byte[bytes]; > } > in.readFully(buffer, 0, bytes); > out.write(buffer, 0, bytes); > } > out.close(); > stream = new FileInputStream(file) { > private boolean closed = false; > public void close() throws IOException { > super.close(); > closed = true; > file.delete(); > } > ... > }; > } > } > But from the test result, I can that JBoss marshaller first read its content (the serializable inputstream) into a byte array, which means the big object is loaded into memory. With our default JVM setting, we always hit OOM issue as below > 2013-08-07 14:30:21,001 ERROR [STDERR] Caused by: java.lang.Exception: java.lang.OutOfMemoryError: Java heap space > 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:222) > 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) > 2013-08-07 14:30:21,016 ERROR [STDERR] ... 39 more > 2013-08-07 14:30:21,016 ERROR [STDERR] Caused by: java.lang.OutOfMemoryError: Java heap space > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.util.Arrays.copyOf(Arrays.java:2786) > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValue.<init>(MarshalledValue.java:72) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValueEX.<init>(MarshalledValueEX.java:47) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.JavaSerializationManager.createdMarshalledValue(JavaSerializationManager.java:105) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.createMarshalledValue(MarshalledInvocation.java:628) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:570) > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429) > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398) > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) > 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:119) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:94) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:969) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:606) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:1634) > 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:548) > Although passing big object with Remote ejb call is not a common use case, but I think it will be better if JBoss could consider such case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-140) KIE module injection through CDI does not work in container

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-140?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-140: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> made a comment on [bug 955193|https://bugzilla.redhat.com/show_bug.cgi?id=955193] Verified on BRMS 6.0.0 ER2. > KIE module injection through CDI does not work in container > ----------------------------------------------------------- > > Key: DROOLS-140 > URL: https://issues.jboss.org/browse/DROOLS-140 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.0.CR1 > > > Description of problem: > Injection of KIE module through CDI fails on JBoss EAP 6.0/6.1 due to wrong processing of resource URI when loading pom.properties in ClasspathKieProject. > Version-Release number of selected component (if applicable): > BRMS 6.0.0.Beta1 > EAP 6.0, 6.1.ER4 > How reproducible: > Deploy the attached reproducer WAR. Deployment fails, server.log contains the following error (see attachment for all errors in log): > 15:40:29,923 INFO [stdout] (MSC service thread 1-2) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml > 15:40:29,939 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-2) Unable to load pom.properties from/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar as jarPath cannot be found > /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar > The first log line shows that ClasspathKieProject located kmodule.xml at URL starting with protocol 'vfs:'. Later, in method fixURLFromKProjectPath, the protocol prefix is removed, leading to URL /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar which now references absolute path which is wrong. > Steps to Reproduce: > 1. Deploy attached reproducer WAR on EAP 6. > 2. Watch server.log for deployment errors. > > Actual results: > Deployment fails due to failed injection. > Expected results: > Application deploys successfully and writes INFO message into server.log. > Additional info: > This issue blocks further testing if KIE module injection through CDI. It also renders the CDI feature unusable in real environment (e.g. some web or EJB container with CDI). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-140) KIE module injection through CDI does not work in container

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-140?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-140: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 955193|https://bugzilla.redhat.com/show_bug.cgi?id=955193] from ON_QA to VERIFIED > KIE module injection through CDI does not work in container > ----------------------------------------------------------- > > Key: DROOLS-140 > URL: https://issues.jboss.org/browse/DROOLS-140 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.0.CR1 > > > Description of problem: > Injection of KIE module through CDI fails on JBoss EAP 6.0/6.1 due to wrong processing of resource URI when loading pom.properties in ClasspathKieProject. > Version-Release number of selected component (if applicable): > BRMS 6.0.0.Beta1 > EAP 6.0, 6.1.ER4 > How reproducible: > Deploy the attached reproducer WAR. Deployment fails, server.log contains the following error (see attachment for all errors in log): > 15:40:29,923 INFO [stdout] (MSC service thread 1-2) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml > 15:40:29,939 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-2) Unable to load pom.properties from/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar as jarPath cannot be found > /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar > The first log line shows that ClasspathKieProject located kmodule.xml at URL starting with protocol 'vfs:'. Later, in method fixURLFromKProjectPath, the protocol prefix is removed, leading to URL /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar which now references absolute path which is wrong. > Steps to Reproduce: > 1. Deploy attached reproducer WAR on EAP 6. > 2. Watch server.log for deployment errors. > > Actual results: > Deployment fails due to failed injection. > Expected results: > Application deploys successfully and writes INFO message into server.log. > Additional info: > This issue blocks further testing if KIE module injection through CDI. It also renders the CDI feature unusable in real environment (e.g. some web or EJB container with CDI). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1324) Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step

by licheng cheng (JIRA)

licheng cheng created JBREM-1324: ------------------------------------ Summary: Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step Key: JBREM-1324 URL: https://issues.jboss.org/browse/JBREM-1324 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: marshall Affects Versions: 2.2.2.SP10 Environment: WindowsXP + jdk1.6 Reporter: licheng cheng Fix For: 2.2.2.SP10 In our stateless EJB, there is one API defined as below. public void modelSave(SerializableInputStream model) throws java.rmi.RemoteException; The SerializableInputStream is defined as below and its whole definition is attached. The intent of defining such class is that sometimes we need to pass through large object (its content may be more than 300M) as parameter to remote ejb, while the -Xmx of the JVM is only 512M by default. With such serializable inputstream, expect JBoss not to load the whole object into JVM before invoking ejb method to avoid the OutOfMemoryError issue. public class SerializableInputStream extends InputStream implements Serializable { private InputStream stream; .... //---------------------------< Serializable >------------------------------- private void writeObject(ObjectOutputStream out) throws IOException { byte[] buffer = new byte[4096]; int bytes; while ((bytes = stream.read(buffer)) >= 0) { // Write a segment of the input stream if (bytes > 0) { // just to ensure that no 0 is written out.writeInt(bytes); out.write(buffer, 0, bytes); } } // Write the end of stream marker out.writeInt(0); // close stream stream.close(); } private void readObject(ObjectInputStream in) throws IOException { final File file = File.createTempFile("serializable-stream", "bin"); OutputStream out = new FileOutputStream(file); byte[] buffer = new byte[4096]; for (int bytes = in.readInt(); bytes > 0; bytes = in.readInt()) { if (buffer.length < bytes) { buffer = new byte[bytes]; } in.readFully(buffer, 0, bytes); out.write(buffer, 0, bytes); } out.close(); stream = new FileInputStream(file) { private boolean closed = false; public void close() throws IOException { super.close(); closed = true; file.delete(); } ... }; } } But from the test result, I can that JBoss marshaller first read its content (the serializable inputstream) into a byte array, which means the big object is loaded into memory. With our default JVM setting, we always hit OOM issue as below 2013-08-07 14:30:21,001 ERROR [STDERR] Caused by: java.lang.Exception: java.lang.OutOfMemoryError: Java heap space 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:222) 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) 2013-08-07 14:30:21,016 ERROR [STDERR] ... 39 more 2013-08-07 14:30:21,016 ERROR [STDERR] Caused by: java.lang.OutOfMemoryError: Java heap space 2013-08-07 14:30:21,016 ERROR [STDERR] at java.util.Arrays.copyOf(Arrays.java:2786) 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValue.<init>(MarshalledValue.java:72) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValueEX.<init>(MarshalledValueEX.java:47) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.JavaSerializationManager.createdMarshalledValue(JavaSerializationManager.java:105) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.createMarshalledValue(MarshalledInvocation.java:628) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:570) 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429) 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398) 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:119) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:94) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:969) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:606) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:1634) 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:548) Although passing big object with Remote ejb call is not a common use case, but I think it will be better if JBoss could consider such case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-49?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-49: --------------------------------------------- baranowb <bbaranow(a)redhat.com> made a comment on [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297] Adding SET as CC + flags > EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured > ----------------------------------------------------------------------------------- > > Key: WFLY-49 > URL: https://issues.jboss.org/browse/WFLY-49 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Labels: ejb, entitybean > Fix For: 8.0.0.Alpha1 > > > If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity. > The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool. > Caused by: java.lang.NullPointerException > at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:] > at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea] > at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea] > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > ... 82 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1684) NPE in UNICAST2.up()

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1684?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1684. ---------------------------- Resolution: Won't Fix Hi Rado, as I mentioned on the PR, I don't want to fix this, because then I'd not be able to find out why msg.getSrc() ever returns null. I'd rather find out in which scenarios this can happen. Can you reproduce this ? Also, this is an ACK, so no harm in discarding it, as the ACK will get resent. > NPE in UNICAST2.up() > -------------------- > > Key: JGRP-1684 > URL: https://issues.jboss.org/browse/JGRP-1684 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.10 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > {noformat} > 11:53:25,993 ERROR [org.jgroups.protocols.UDP] (OOB-13,shared=udp) failed handling incoming message: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) [rt.jar:1.6.0_45] > at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432) > at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:645) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147) > at org.jgroups.protocols.FD.up(FD.java:253) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:290) > at org.jgroups.protocols.Discovery.up(Discovery.java:359) > at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2610) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1263) > at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825) > at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45] > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does not work on MacOS

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1928?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-1928: ------------------------------------ Assignee: (was: Thomas Diesler) It should be possible to provide a script that provides start/stop/restart functionality for wildfly which generally runs on bash and does not make (possibly false) assumptions about the execution environment. > jboss-as-standalone.sh does not work on MacOS > --------------------------------------------- > > Key: WFLY-1928 > URL: https://issues.jboss.org/browse/WFLY-1928 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Alpha4 > Reporter: Thomas Diesler > Fix For: 8.0.0.Beta1 > > > {code} > FuseFabric:karaf@root> process-start root 3 > bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory > Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1 > bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2013