[JBoss JIRA] (JGRP-1771) Replace Exposed{Input, Output}Stream with ByteArray{Input, Output}Stream
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1771?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1771 at 2/10/14 10:56 AM:
----------------------------------------------------------
All relevant methods to read from and write to byte buffers will be defined in org.jgroups.util.Bits, similar to java.nio.Bits. This is only needed for *byte arrays* as *ByteBuffers* already contains methods to do that.
h5. Re endian-ness
Java uses the big-endian format all the time, and since JGroups does not have to communicate with non-Java processes, we'll ignore endian-ness for the time being. (Note that ByteBuffer does *not* ignore endian-ness).
Shift operators ({{<<}} {{>>}}) defined by Java and used in Bits don't simply shift left or right, but they shift towards the MSB ({{<<}}) and LSB ({{>>}}) respectively, so the result is the same in little or big endian systems, and that's why communication between processes on different architectures works in Java.
h5. Example
The integer 322649 is stored as {{0 4 -20 89}} on big endian systems and {{89 -20 4 0}} on little endian systems. However, {{(byte)(322649 >> 8)}} always returns {{-20}} ({{236}}), regardless of whether it is run on a little- or big endian system.
was (Author: belaban):
All relevant methods to read from and write to byte buffers will be defined in org.jgroups.util.Bits, similar to java.nio.Bits. This is only needed for *byte arrays* as *ByteBuffers* already contains methods to do that.
h5. Re endian-ness
Java uses the big-endian format all the time, and since JGroups does not have to communicate with non-Java processes, we'll ignore endian-ness for the time being. (Note that ByteBuffer does *not* ignore endian-ness).
Shift operators ({{<<}} {{>>}}) defined by Java and used in Bits don't simply shift left or right, but they shift towards the MSB ({{<<}}) and LSB ({{>>}}) respectively, so the result is the same in little or big endian systems, and that's why communication between processes on different architectures works in Java.
h5. Example
The integer 322649 is stored as 0 4 -20 89 in big endian systems and 89 -20 4 0 in little endian systems. However, {{(byte)(322649 >> 8)}} always returns -20 (236), regardless of whether it is run on a little- or big endian system.
> Replace Exposed{Input,Output}Stream with ByteArray{Input,Output}Stream
> ----------------------------------------------------------------------
>
> Key: JGRP-1771
> URL: https://issues.jboss.org/browse/JGRP-1771
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
> The problem is that DataInputStream creates an 80 byte buffer for every creation, and also an array of 80 chars (additional 160 bytes + array header + pointer).
> Same thing for sending a message or message list.
> SOLUTION:
> * Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
> ** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
> *** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
> * Similar solution for sending of messages / message lists
> * Also create the corresponding unit tests
--
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
12 years, 2 months
[JBoss JIRA] (JGRP-1771) Replace Exposed{Input, Output}Stream with ByteArray{Input, Output}Stream
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1771?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1771:
--------------------------------
All relevant methods to read from and write to byte buffers will be defined in org.jgroups.util.Bits, similar to java.nio.Bits. This is only needed for *byte arrays* as *ByteBuffers* already contains methods to do that.
h5. Re endian-ness
Java uses the big-endian format all the time, and since JGroups does not have to communicate with non-Java processes, we'll ignore endian-ness for the time being. (Note that ByteBuffer does *not* ignore endian-ness).
Shift operators ({{<<}} {{>>}}) defined by Java and used in Bits don't simply shift left or right, but they shift towards the MSB ({{<<}}) and LSB ({{>>}}) respectively, so the result is the same in little or big endian systems, and that's why communication between processes on different architectures works in Java.
> Replace Exposed{Input,Output}Stream with ByteArray{Input,Output}Stream
> ----------------------------------------------------------------------
>
> Key: JGRP-1771
> URL: https://issues.jboss.org/browse/JGRP-1771
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
> The problem is that DataInputStream creates an 80 byte buffer for every creation, and also an array of 80 chars (additional 160 bytes + array header + pointer).
> Same thing for sending a message or message list.
> SOLUTION:
> * Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
> ** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
> *** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
> * Similar solution for sending of messages / message lists
> * Also create the corresponding unit tests
--
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
12 years, 2 months
[JBoss JIRA] (JBJCA-1137) NPE in o.j.j.c.CommonBundle.Annotations#processConfigProperty() line:765
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1137?page=com.atlassian.jira.plugin... ]
Darryl Miles commented on JBJCA-1137:
-------------------------------------
Fair enough, but it is an NPE.
The CNFE is handled gracefully further up the stack trace (by annotation lookup). It is gracefully handled by returning null.
The code in o.j.j.c.CommonBundle.Annotations#processConfigProperty() line:765 then tried to dereference this null. Which is an error.
Regardless of "class loading issues".
> NPE in o.j.j.c.CommonBundle.Annotations#processConfigProperty() line:765
> ------------------------------------------------------------------------
>
> Key: JBJCA-1137
> URL: https://issues.jboss.org/browse/JBJCA-1137
> Project: IronJacamar
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1.2.Final
> Reporter: Darryl Miles
> Assignee: Jesper Pedersen
>
> org.jboss.jca.common.CommonBundle.Annotations
> Map<Metadatas, ArrayList<ConfigProperty16>> processConfigProperty(AnnotationRepository annotationRepository, ClassLoader classLoader)
> for (Annotation annotation : values)
> {
> javax.resource.spi.ConfigProperty configPropertyAnnotation = (javax.resource.spi.ConfigProperty) annotation
> .getAnnotation();
> if (trace)
> log.trace("Processing: " + configPropertyAnnotation);
> XsdString configPropertyValue = XsdString.NULL_XSDSTRING;
> if (configPropertyAnnotation.defaultValue() != null && !configPropertyAnnotation.defaultValue().equals(""))
> configPropertyValue = new XsdString(configPropertyAnnotation.defaultValue(), null);
> javax.resource.spi.ConfigProperty configPropertyAnnotation = (javax.resource.spi.ConfigProperty) annotation.getAnnotation();
> can return null when there is ClassNotFoundException for the class with the annotation in it.
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.IllegalArgumentException: JBAS017220: Class not found
> at org.jboss.as.service.ReflectionUtils.getClass(ReflectionUtils.java:115)
> at org.jboss.as.service.ReflectionUtils.getClassHierarchy(ReflectionUtils.java:122)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:113)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:104)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: com.domain.project.ejb.mbean.Monitor from [Module "deployment.com.domain.project.ear.ear.com-domain-project.ejb-0.0.1-SNAPSHOT.jar:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
> at org.jboss.as.service.ReflectionUtils.getClass(ReflectionUtils.java:113)
> ... 9 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
12 years, 2 months
[JBoss JIRA] (WFLY-2261) standalone.sh --debug without port number not working
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2261:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1063289
> standalone.sh --debug without port number not working
> ------------------------------------------------------
>
> Key: WFLY-2261
> URL: https://issues.jboss.org/browse/WFLY-2261
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Brian Stansberry
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO [stdout] (main)
> 12:19:36,893 INFO [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {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
12 years, 2 months
[JBoss JIRA] (WFLY-2892) Deploying exploded RAR with exploded JAR fails with CNFE
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-2892?page=com.atlassian.jira.plugin.... ]
Darryl Miles edited comment on WFLY-2892 at 2/10/14 10:13 AM:
--------------------------------------------------------------
This is a RAR development matter (not a production matter) since the specification does not cover the development process that is 'JBoss added value' between the AS and the IDE tools.
So in order for the JBoss product suite to be consistent and "just work (tm)" either:
* AS to support exploded JAR inside exploded RARs, or
* JBoss Tools are not to deploy an exploded JAR (but create a synthetic real JAR from the data in the IDE).
This way the JBoss product suite works out the box to develop RARs.
was (Author: dlmiles):
This is a RAR development matter (not a production matter) since the specification does not cover the development process that is 'JBoss added value' between the AS and the IDE tools.
So in order for the JBoss product suite to be consistent either:
* AS to support exploded JAR inside exploded RARs, or
* JBoss Tools are not to deploy an exploded JAR (but create a synthetic real JAR from the data in the IDE).
This way the JBoss product suite works out the box to develop RARs.
> Deploying exploded RAR with exploded JAR fails with CNFE
> --------------------------------------------------------
>
> Key: WFLY-2892
> URL: https://issues.jboss.org/browse/WFLY-2892
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.CR1
> Reporter: Darryl Miles
> Assignee: Stefano Maestri
> Priority: Optional
>
> This is the default method of deployment for JBoss AS Connector when using Eclipse and JBoss Tools.
> The resulting file layout is like:
> deployments/com.domain.rarproject.rar/com.domain.rarimpl.jar/com/domain/MyClassFile.class
> When the RAR is built into a JAR file, that contains the com.domain.rarimpl.jar inside deployment is sucessfull.
> The RAR deployer should allow the exploded layout where the "com.domain.rarimpl.jar" is of type directory (not file).
> Or JBoss AS Tooling should be fixed to understand the limitation of the AS RAR deployer during development of RAR/JCA driver.
> Other kinds of deployments allow exploded format via JBoss VFS.
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-2892) Deploying exploded RAR with exploded JAR fails with CNFE
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-2892?page=com.atlassian.jira.plugin.... ]
Darryl Miles edited comment on WFLY-2892 at 2/10/14 10:15 AM:
--------------------------------------------------------------
This is a RAR development matter (not a production matter) since the specification does not cover the development process that is 'JBoss added value' between the AS and the IDE tools.
So in order for the JBoss product suite to be consistent and "just work (tm)" either:
* AS to support exploded JAR inside exploded RARs, or
* JBoss Tools are not to deploy an exploded JAR (but create a synthetic real JAR from the data in the IDE).
This way the JBoss product suite works out the box to develop RARs.
A Lazy way to address this would be to detect the exploded JAR exists (by file type) and throw up a useful error instructing the user that an exploded JAR is not supported here. This may save someone else several hours wondering why when using the JBoss product suite things didn't just work out the box.
was (Author: dlmiles):
This is a RAR development matter (not a production matter) since the specification does not cover the development process that is 'JBoss added value' between the AS and the IDE tools.
So in order for the JBoss product suite to be consistent and "just work (tm)" either:
* AS to support exploded JAR inside exploded RARs, or
* JBoss Tools are not to deploy an exploded JAR (but create a synthetic real JAR from the data in the IDE).
This way the JBoss product suite works out the box to develop RARs.
> Deploying exploded RAR with exploded JAR fails with CNFE
> --------------------------------------------------------
>
> Key: WFLY-2892
> URL: https://issues.jboss.org/browse/WFLY-2892
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.CR1
> Reporter: Darryl Miles
> Assignee: Stefano Maestri
> Priority: Optional
>
> This is the default method of deployment for JBoss AS Connector when using Eclipse and JBoss Tools.
> The resulting file layout is like:
> deployments/com.domain.rarproject.rar/com.domain.rarimpl.jar/com/domain/MyClassFile.class
> When the RAR is built into a JAR file, that contains the com.domain.rarimpl.jar inside deployment is sucessfull.
> The RAR deployer should allow the exploded layout where the "com.domain.rarimpl.jar" is of type directory (not file).
> Or JBoss AS Tooling should be fixed to understand the limitation of the AS RAR deployer during development of RAR/JCA driver.
> Other kinds of deployments allow exploded format via JBoss VFS.
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-2892) Deploying exploded RAR with exploded JAR fails with CNFE
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-2892?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-2892:
------------------------------------
This is a RAR development matter (not a production matter) since the specification does not cover the development process that is 'JBoss added value' between the AS and the IDE tools.
So in order for the JBoss product suite to be consistent either:
* AS to support exploded JAR inside exploded RARs, or
* JBoss Tools are not to deploy an exploded JAR (but create a synthetic real JAR from the data in the IDE).
This way the JBoss product suite works out the box to develop RARs.
> Deploying exploded RAR with exploded JAR fails with CNFE
> --------------------------------------------------------
>
> Key: WFLY-2892
> URL: https://issues.jboss.org/browse/WFLY-2892
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.CR1
> Reporter: Darryl Miles
> Assignee: Stefano Maestri
> Priority: Optional
>
> This is the default method of deployment for JBoss AS Connector when using Eclipse and JBoss Tools.
> The resulting file layout is like:
> deployments/com.domain.rarproject.rar/com.domain.rarimpl.jar/com/domain/MyClassFile.class
> When the RAR is built into a JAR file, that contains the com.domain.rarimpl.jar inside deployment is sucessfull.
> The RAR deployer should allow the exploded layout where the "com.domain.rarimpl.jar" is of type directory (not file).
> Or JBoss AS Tooling should be fixed to understand the limitation of the AS RAR deployer during development of RAR/JCA driver.
> Other kinds of deployments allow exploded format via JBoss VFS.
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-2893) Determine cause of unreported test failures
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-2893:
--------------------------------------
Summary: Determine cause of unreported test failures
Key: WFLY-2893
URL: https://issues.jboss.org/browse/WFLY-2893
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Build System, Test Suite
Affects Versions: 8.0.0.CR1
Reporter: Brian Stansberry
Assignee: Tomaz Cerar
Fix For: 8.0.1.Final
Identify the reason why the failing tests that needed https://github.com/wildfly/wildfly/commit/90643bc435a9ba439cf2988e5b7407d... to get working did not fail the build. Those tests were failing for 2.5 months. Fortunately it was just a test problem, not a broken feature.
They involved separate surefire executions. We want to avoid those, but sometimes they are needed to use different config files. We have separate executions in testsuite/integration/basic as well, covering a much broader scope, so if this kind of problem happened there as well we could have a big problem.
--
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
12 years, 2 months