[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
12 years, 10 months
[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
12 years, 10 months
[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
12 years, 10 months
[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
12 years, 10 months
[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
12 years, 10 months
[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
12 years, 10 months
[JBoss JIRA] (JBJCA-1075) ironjacamar-deployers-common.jar contains source files (*.java)
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1075?page=com.atlassian.jira.plugin... ]
Lin Gao commented on JBJCA-1075:
--------------------------------
Send PR for branch 1.1 and 1.0
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
> Key: JBJCA-1075
> URL: https://issues.jboss.org/browse/JBJCA-1075
> Project: IronJacamar
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.0.20.Final, 1.1.0.Final
> Reporter: Lin Gao
> Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao@dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
> 8739 08-30-2013 16:30 org/jboss/jca/deployers/DeployersBundle_$bundle.java
> 7944 08-30-2013 16:30 org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.
--
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, 10 months