[IronJacamar] - Test connection through CLI when <allow-multiple-users/> is applied to a datasource
by anuragdebnath
anuragdebnath [https://community.jboss.org/people/anuragdebnath] created the discussion
"Test connection through CLI when <allow-multiple-users/> is applied to a datasource"
To view the discussion, visit: https://community.jboss.org/message/799863#799863
--------------------------------------------------------------
*Environment :*
JBoss EAP-6.0.1
JBoss AS 7.1.3
IronJacamar version used in above JBoss version - 1.0.13.Final
*Issue :*
Create a XA data-source(via CLI) which has the attribute <allow-multiple-users/> defined to true.
Testing the connection using CLI shows the below error -
**************************************
[standalone@localhost:9999 /] /subsystem=datasources/xa-data-source=OracleXA_DS:test-connection-in-pool()
{ "outcome" => "failed", "failure-description" => "JBAS010440: failed to invoke operation: JBAS010447: Connection is not valid", "rolled-back" => true }
**************************************
On checking the description of the attribute ( /subsystem=datasources/xa-data-source=OracleXA_DS:read-resource-description(recursive=true) ) it says -
"allow-multiple-users" => {
"type" => BOOLEAN,
"description" => "Specifies if multiple users will access the datasource through the getConnection(user, password) method and hence if the internal pool type should account for that"
When testing the connection through "test-connection-in-pool" there is no way to provide username/password for the above mentioned getConnection() and hence connection fails.
To confirm if applying <allow-multiple-users/> is a valid attribute to a datasource, i tested the same using a simple JDBC code and supplied the credentials to the .getConnection() like below and it works well-
InitialContext ic = new InitialContext();
Datasource ds = (DataSource)ic.lookup("java:/etsDataSourcexa");
Connection con = ds.getConnection("jboss","jboss");
I have raised a JIRA [1] but would like to know the expert's thought :)
[1] https://issues.jboss.org/browse/JBJCA-990 https://issues.jboss.org/browse/JBJCA-990
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/799863#799863]
Start a new discussion in IronJacamar at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 1 month
[EJB3] - Problems using the @RemoteHome annotation for backward compatibility
by Mike Miller
Mike Miller [https://community.jboss.org/people/mikemil] created the discussion
"Problems using the @RemoteHome annotation for backward compatibility"
To view the discussion, visit: https://community.jboss.org/message/799738#799738
--------------------------------------------------------------
We are (hopefully) coming to the end of our migration from EJB 2.1 to EJB 3 "exercise". We are encountering ClassCastExceptions when we try to load an EJB3 bean from one of our older, yet to be migrated EJB2.1 server instances. If I understood the 3.0 spec correctly, 3.0 can be a 'client' of 2.1 but not really vise versa.
Little bit of history - our product is a POS where we have a 'store server' at each retail store and a 'Central' server at company headquarters. This can NOT be big banged over night, so our migration/upgrade path means that Central will be upgraded to 3.0 first, then sets of stores will be upgraded, but not all at once. Most of the communication between servers is done thru JMS, but we do have some cases where we make what we call a 'reverse service call' which means a store loads an EJB from the Central Server's JNDI, or Central loads an EJB from the Store servers JNDI. This is where we are at right now. Central at 3.0 and Store at 2.1, then Store requests an EJB from Central and when we attempt to PortableNarrow - we get a ClassCastException.
We are doing this on JBoss 4.2.3.GA.
If I understand the documentation correctly, it sounds like we should be able to use the @RemoteHome to generate the home interface for the 2.1 clients to use to talk to our Central Server. I have tried this and assume that I am missing some piece of the puzzle. I have tried to compare mine agains the ejb21_client_adaptors sample in the EJB3 tutorial files but it's not working. The exception we get on the Store server side is below:
{code}
2013-02-26 13:33:00,985 ERROR [root] java.lang.RuntimeException: problem connecting to EJB container
at com.jda.portfolio.infrastructure.base.service.ServiceFactory.getRemoteService(ServiceFactory.java:503)
at com.jda.portfolio.infrastructure.base.service.ServiceFactory$CentralServerLookupThread.run(ServiceFactory.java:621)
2013-02-26 13:33:00,989 ERROR [root] Caused by: null
java.lang.ClassCastException
at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:245)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:153)
at com.jda.portfolio.infrastructure.base.service.ServiceFactory.getRemoteService(ServiceFactory.java:488)
at com.jda.portfolio.infrastructure.base.service.ServiceFactory$CentralServerLookupThread.run(ServiceFactory.java:621)
Caused by: java.lang.ClassCastException: $Proxy1238 cannot be cast to org.omg.CORBA.Object
at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:228)
... 3 more
2013-02-26 13:33:00,991 ERROR [root] Root cause: $Proxy1238 cannot be cast to org.omg.CORBA.Object
java.lang.ClassCastException: $Proxy1238 cannot be cast to org.omg.CORBA.Object
at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:228)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:153)
at com.jda.portfolio.infrastructure.base.service.ServiceFactory.getRemoteService(ServiceFactory.java:488)
{code}
Below are snippets from our classes
*EJB3 Session Bean*
{code}
package com.jda.portfolio.pos.server.service.security;
...
@Stateless
@RemoteHome(KeyManagementServiceHome.class)
@RemoteBinding(jndiBinding="ejb/KeyManagementService")
@LocalBinding(jndiBinding="ejb/KeyManagementServiceLocal")
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class KeyManagementServiceBean extends com.jda.portfolio.infrastructure.server.service.AbstractService implements KeyManagementService, KeyManagementServiceLocal
{
@Init
public void ejbCreate() {
System.out.println("**** ejbCreate() of " + this.getClass() + " called ****");
}
...
}
{code}
*New Home interface for 2.1 clients*
{code}
package com.jda.portfolio.pos.server.service.security;
...
public interface KeyManagementServiceHome extends EJBHome {
public KeyManagementServiceRemote create() throws CreateException, RemoteException;
}
{code}
*Remote interface created by Home*
{code}
package com.jda.portfolio.pos.server.service.security;
import javax.ejb.EJBObject;
public interface KeyManagementServiceRemote extends EJBObject {
public int addKey( com.jda.portfolio.infrastructure.base.util.KeyGenData keyGenData ) ;
public boolean publishKeys( java.util.List locationNumbers ) ;
public int removeKeys( java.util.List keysToRemove ) ;
}
{code}
Using no deployment descriptors. After making this change, I did dump the JNDIView for my Central (3.0) server from the console and noticed one strange entry that does not show up in our other servers. There is an entry that looks like a subcontext of "KeyManagementServiceBean" with a named pair of 'home' : $Proxy1256. The KeyManagementServiceBean is actually the name of the class for the EJB Session bean I am trying to make available as a 2.1 bean.
Setting breakpoints in the Store server where we are loading and attempting to narrow the reference - I also noticed that the class within the proxy class is usually 'ClientContainer' when things work, like for 2.1 - but when we load the 3.0 bean from Central, the class name in the proxy is StatelessRemoteProxy. Not sure if that means anything or just a result of the different implementations.
I know there's a lot of info here but I can help clarify it if it is not clear.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/799738#799738]
Start a new discussion in EJB3 at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 1 month
[JBoss Remoting] - EOFExceptions and IOExceptions in remote EJB calls under load
by Christian Kölle
Christian Kölle [https://community.jboss.org/people/chrkoelle] created the discussion
"EOFExceptions and IOExceptions in remote EJB calls under load"
To view the discussion, visit: https://community.jboss.org/message/800098#800098
--------------------------------------------------------------
Hi
I have posted this question in the JBoss 7 forum but didn't get an answer. I hope that somebody in this forum has some idea what's the problem here.
We have a web application that ist split up in a frontend and a backend application. The frontend calls EJBs in the backend. This works pretty well but in production we occasionaly we get exceptions at times that we know as high load periods.
Both applications run on JBoss 7.1.2 application servers.
In the frontend we see something like this:
00:59:10,337 ERROR [org.jboss.remoting.remote.connection] (Remoting "jboss-web-extern" read-1) JBREM000200: Remote connection failed: java.io.IOException: Input overrun
00:59:10,393 ERROR [****] (ajp-/0.0.0.0:8009-130) Cannot perform usecase ***
java.lang.reflect.UndeclaredThrowableException
$Proxy75.performUseCase(Unknown Source)
......
Cause: java.io.EOFException: Writes have been shut down
org.xnio.channels.FramedMessageChannel.send(FramedMessageChannel.java:220)
org.xnio.channels.Channels.sendBlocking(Channels.java:200)
org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:109)
org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:125)
org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:113)
In the backend something like this:
00:59:10,348 ERROR [org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler] (EJB default - 13) Could not write method invocation result for method public *** on bean named *** for appname *** modulename common-ejb distinctname due to : java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_06]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_06]
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:89) [rt.jar:1.7.0_06]
at sun.nio.ch.IOUtil.write(IOUtil.java:60) [rt.jar:1.7.0_06]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:450) [rt.jar:1.7.0_06]
at org.xnio.nio.AbstractNioStreamChannel.write(AbstractNioStreamChannel.java:303)
at org.xnio.channels.FramedMessageChannel.doFlushBuffer(FramedMessageChannel.java:297) [xnio-api-3.0.3.GA.jar:3.0.3.GA]
at org.xnio.channels.FramedMessageChannel.doFlush(FramedMessageChannel.java:311) [xnio-api-3.0.3.GA.jar:3.0.3.GA]
at org.xnio.channels.FramedMessageChannel.send(FramedMessageChannel.java:238) [xnio-api-3.0.3.GA.jar:3.0.3.GA]
at org.xnio.channels.Channels.sendBlocking(Channels.java:200) [xnio-api-3.0.3.GA.jar:3.0.3.GA]
at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:109) [jboss-remoting-3.2.7.GA.jar:3.2.7.GA]
at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:125) [xnio-api-3.0.3.GA.jar:3.0.3.GA]
at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:113) [xnio-api-3.0.3.GA.jar:3.0.3.GA]
at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:142) [xnio-api-3.0.3.GA.jar:3.0.3.GA]
at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:160) [xnio-api-3.0.3.GA.jar:3.0.3.GA]
at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:193) [jboss-remoting-3.2.7.GA.jar:3.2.7.GA]
at org.jboss.as.ejb3.remote.protocol.versionone.ChannelAssociation.releaseChannelMessageOutputStream(ChannelAssociation.java:85)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.writeMethodInvocationResponse(MethodInvocationMessageHandler.java:348)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$500(MethodInvocationMessageHandler.java:67)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:237)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_06]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_06]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_06]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_06]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_06]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_06]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
I haven't found more information on this exceptions on the net.
For me it is not clear what this means. Does this have an effect on the users? Is there a problem with our implementation or perhaps the configuration?
Christian
- See more at: https://community.jboss.org/thread/208053#sthash.kIA4sN06.dpuf
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/800098#800098]
Start a new discussion in JBoss Remoting at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 1 month
[Beginner's Corner] - Problem in jboss-log4j.xml file
by ashish joshi
ashish joshi [https://community.jboss.org/people/ashishjoshi106] created the discussion
"Problem in jboss-log4j.xml file"
To view the discussion, visit: https://community.jboss.org/message/799860#799860
--------------------------------------------------------------
my file is below and i want to stop sysout from server logs:
jboss-log4j.xml file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j=" http://jakarta.apache.org/log4j/ http://jakarta.apache.org/log4j/" debug="false">
<!-- ================================= -->
<!-- Preserve messages in a local file -->
<!-- ================================= -->
<!-- A time/date based rolling appender -->
<appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="File" value="${jboss.server.log.dir}/server.log"/>
<param name="Append" value="true"/>
<param name="DatePattern" value="'.'yyyy-MM-dd"/>
<!-- Rollover at the top of each hour
<param name="DatePattern" value="'.'yyyy-MM-dd-HH"/>
-->
<layout class="org.apache.log4j.PatternLayout">
<!-- The default pattern: Date Priority [Category] (Thread) Message\n -->
<param name="ConversionPattern" value="%d %-5p [%c] (%t) %m%n"/>
<!-- The full pattern: Date MS Priority [Category] (Thread:NDC) Message\n
<param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/>
-->
</layout>
</appender>
<category name="org.apache">
<priority value="INFO"/>
</category>
<!-- Limit the jacorb category to WARN as its INFO is verbose -->
<category name="jacorb">
<priority value="WARN"/>
</category>
<!-- Set the logging level of the JSF implementation that uses
| java.util.logging. The jdk logging levels can be controlled
| through the org.jboss.logging.log4j.JDKLevel class that
| in addition to the standard log4j levels it adds support for
| SEVERE, WARNING, CONFIG, FINE, FINER, FINEST
-->
<category name="javax.enterprise.resource.webcontainer.jsf">
<priority value="INFO" class="org.jboss.logging.log4j.JDKLevel"/><!--MODIFIED-->
</category>
<!-- Limit the org.jgroups category to WARN as its INFO is verbose -->
<category name="org.jgroups">
<priority value="WARN"/>
</category>
<!-- change two -->
<category name="org.hibernate">
<priority value="ERROR"/>
</category>
<!-- Limit the org.quartz category to INFO as its DEBUG is verbose -->
<category name="org.quartz">
<priority value="INFO"/>
</category>
<category name="com.sun">
<priority value="INFO"/>
</category>
<!--<category name="com.emitra">
<priority value="ERROR"/>
</category>-->
<!-- Limit the sun category to INFO as its FINE is verbose -->
<category name="sun">
<priority value="INFO"/>
</category>
<!-- Limit the javax.xml.bind category to INFO as its FINE is verbose -->
<category name="javax.xml.bind">
<priority value="INFO"/>
</category>
<!-- Limit the springframework category to WARN-->
<category name="org.springframework">
<priority value="WARN"/>
</category>
<!-- Limit JBoss categories
<category name="org.jboss">
<priority value="INFO"/>
</category>
-->
<!-- Limit the JSR77 categories -->
<category name="org.jboss.management">
<priority value="INFO"/>
</category>
<!-- Limit the verbose facelets compiler -->
<category name="facelets.compiler">
<priority value="WARN"/>
</category>
<!-- Limit the verbose ajax4jsf cache initialization -->
<category name="org.ajax4jsf.cache">
<priority value="WARN"/>
</category>
<!-- Limit the verbose embedded jopr categories -->
<category name="org.rhq">
<priority value="WARN"/>
</category>
<category name="org.jboss.seam">
<priority value="WARN"/>
</category>
<!-- Limit the verbose MC4J EMS (lib used by admin-console) categories -->
<category name="org.mc4j.ems">
<priority value="WARN"/>
</category> -->
<!-- Limit the org.jboss.serial (jboss-serialization) to INFO as its DEBUG is verbose -->
<category name="org.jboss.serial">
<priority value="INFO"/>
</category>
<!-- ======================= -->
<!-- Setup the Root category -->
<!-- ======================= -->
<root>
<!--
Set the root logger priority via a system property. Note this is parsed by log4j,
so the full JBoss system property format is not supported; e.g.
setting a default via ${jboss.server.log.threshold:WARN} will not work.
-->
<priority value="${jboss.server.log.threshold}"/>
<appender-ref ref="FILE"/>
</root>
</log4j:configuration>
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/799860#799860]
Start a new discussion in Beginner's Corner at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 1 month
[jBPM] - how to define a custom (maven-generated from sources) jBPM runtime
by Szymek Pindelski
Szymek Pindelski [https://community.jboss.org/people/sweeper] created the discussion
"how to define a custom (maven-generated from sources) jBPM runtime"
To view the discussion, visit: https://community.jboss.org/message/799847#799847
--------------------------------------------------------------
hello,
i'm trying to replace the default jBPM runtime that comes with jbpm full installer package with my own (maven-generated) one.
If i understand it correctly - 'jBPM Runtime' in eclipse jbpm-enabled project is nothing more than a way to gather all the necessary jar dependencies (drools + jbpm + knowledge api) in one place - am I right? Or is there something more to it?
The default jBPM runtime points to ./runtime folder holding the jars i mentioned above.
I managed to build these same jar packages using maven (mvn-all.sh clean install -DskipTests) but the resulting jars are scattered around my local maven repository (each jar in a proper groupId/artifactId/version directory subtree) so it's hard to define a single 'root' folder holding them altogether (.m2/repository perhaps?)
I removed the default jBPM library that has been added as Eclipse build path dependency by the Eclipse jBPM plugin, mavenized my demo project and added these same (compile-scoped) maven dependencies to a newly created pom.xml.
My demo project compiles all right but since i wasn't able to remove jBPM runtime from my demo projects properties, I fear that eclipse launcher will use the jar files from jBPM runtime directory instead.
Thanks in advance for any assistance
regards
Simon
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/799847#799847]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 1 month