oracle.jdbc.driver.T4CConnection cannot be cast to oracle.jdbc.OracleConnection in JBOSS EAP 6.1 - jboss7.x

I have deployed my ear in JBOSS 7.1.1 AS.
For viewing the document in application we are using the BFILE.
Below code is used:
Connection con = this.jdbcTemplate.getDataSource().getConnection();
con = unwrapConnection(con);
if(null != con)
{
System.out.println("Is conncetion Closed" + con.isClosed());
PreparedStatement ps = con.prepareStatement(sql);
ResultSet rs = ps.executeQuery();
while(rs.next()) {
{
OracleResultSet ors = rs.unwrap(OracleResultSet.class);
bfile = ors.getBFILE(1);
fileName = rs.getString(2);
docFormat = rs.getString(3);
}
bfileMap.put("EventDocDetails", bfile);
bfileMap.put("Format", docFormat);
bfileMap.put("FileName", fileName);
}
private static Connection unwrapConnection(Connection connection) throws SQLException {
System.out
.println("Datasource is maintained by Jboss so Unwarping Jboss JDBC Connection to oracle.jdbc.OracleConnection. Driver name is "
+ connection.getMetaData().getDriverName());
return (oracle.jdbc.OracleConnection) ((WrappedConnection) connection)
.getUnderlyingConnection();
}
We are using Ojdc6.11.2.0.3 jar.
In the manifest of ear I have dependencies org.jboss.ironjacamar.jdbcadapters.
This works fine for JBOSS AS 7.1.1
But same ear doesnt work in JBOSS EAP 6.1
I get below exception
oracle.jdbc.driver.T4CConnection cannot be cast to oracle.jdbc.OracleConnection
19:54:51,395 ERROR [stderr] (http-/192.168.178.31:8080-5) java.lang.ClassCastException: oracle.jdbc.driver.T4CConnection cannot be cast to oracle.jdbc.OracleConnection.
I am baffled as almost all the things are same.

Seems like a classload issue due to two same classes exist in Jboss and in your app(WAR or EAR).
In my Jboss 6.3 I'm found jboss\modules\com\oracle\ojdbc6.jar with T4CConnection.class inside which may be cause of issue. If it exist in your jboss you can try to exclude that lib in jboss-deployment-structure.xml like:
<deployment>
<exclusions>
<module name="com.oracle.ojdbc6"/>
</exclusions>
</deployment>
Hope it helps.

After a lot of head scratching i removed the JDBC drive from console of JBOSS and added a new one.It worked.

Related

EJB2.1 lookup issue in JBoss EAP 7.2.8

We have migrated our application from Weblogic to JBoss EAP 7.2.8 and now we are facing issue in JNDI lookup of remote interface.
Configuration in ejb-jar.xml:
<session>
<ejb-name>BeanSL</ejb-name>
<home>com.project.ejb.BeanSLHome</home>
<remote>com.project.ejb.BeanSLIF</remote>
<ejb-class>com.project.ejb.BeanSL</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
server.log entry in Jboss for EJB registration of above mentioned class:
java:global/ear/jarWithEJB/BeanSL!com.project.ejb.BeanSLIF
java:app/dbdocejb/BeanSL!com.project.ejb.BeanSLIF
java:module/BeanSL!com.project.ejb.BeanSLIF
java:jboss/exported/ear/jarWithEJB/BeanSL!com.project.ejb.BeanSLIF
java:global/ear/jarWithEJB/BeanSL!com.project.ejb.BeanSLHome
java:app/dbdocejb/BeanSL!com.project.ejb.BeanSLHome
java:module/BeanSL!com.project.ejb.BeanSLHome
java:jboss/exported/ear/jarWithEJB/BeanSL!com.project.ejb.BeanSLHome
Remote Interface: BeanSLIF
Home Interface: BeanSLHome
Class implementing Remote Interface: BeanSL
BeanSLIF beanSLIf = null ;
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, “org.wildfly.naming.client.WildFlyInitialContextFactory”);
p.put( Context.PROVIDER_URL, “http-remoting://localhost:8090” );
p.put(Context.SECURITY_PRINCIPAL, “jbossUser”);
p.put(Context.SECURITY_CREDENTIALS, “jbossPassword”);
p.put("jboss.naming.client.ejb.context", "true");
ctx = new InitialContext( p );
beanSLIf = (BeanSLIF) ctx.lookup(“ejb:/ear/jarWithEJB/BeanSL!com.project.ejb.BeanSLIF”);
On inspecting the above lookup code(cx.lookup(ejb:/...) code I am getting below ‘Proxy’:
Proxy for remote EJB StatelessEJBLocator for "/ear/jarWithEJB/BeanSL", view is interface com.project.ejb.BeanSLIF, affinity is None
And this further leads to:
com.sun.proxy.$Proxy39 cannot be cast to com.project.ejb.BeanSLIF
Any help would be really appreciated. Thanks in advance.

TomEE Embedded: Resource defined in resources.xml not available within webapp

I'm currently trying to run a simple webapp on TomEE Embedded (TomEE Version 7.0.5).
According to the docs, I can start the TomEE and deploy the classpath as a webapp like this. I've set the document base to src/main/webapp.
try (final Container container = new Container(new Configuration())
.deployClasspathAsWebApp("", new File("src/main/webapp"))) {
container.await();
}
I have defined a datasource in WEB-INF/resources.xml which looks like this:
<Resource id="myDataSource" type="javax.sql.DataSource">
JdbcDriver org.hsqldb.jdbcDriver
JdbcUrl jdbc:hsqldb:file:hsqldb
UserName sa
Password
</Resource>
And I've setup a reference in the web.xml:
<resource-ref>
<res-ref-name>myDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
</resource-ref>
Then I try to lookup this datasource in my Servlet via JNDI.
#Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
try {
Context initCtx = new InitialContext();
DataSource ds = (DataSource) initCtx.lookup("java:comp/env/myDataSource");
Connection connection = ds.getConnection();
...
}
When the TomEE starts, it seems like my DataSource is created (at least there is some output about that in the logs). However when I try to lookup the DataSource in my servlet, I get an unconfigured dbcp2 connection pool as a DataSource which throws the following exception when ds.getConnection() is called:
java.sql.SQLException: Cannot create JDBC driver of class '' for connect URL 'null'
at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createConnectionFactory(BasicDataSource.java:2186)
at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:2066)
at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1525)
at TestServlet.doGet(TestServlet.java:32)
...
The same configuration works fine on a standalone TomEE (I tried TomEE Webprofile) or when using the TomEE Maven Plugin. Is there anything I'm missing to get it running also for Embedded TomEE?
Thanks in advance
Tomee embedded does not bind a custom webapp classloader by default so does not have comp/ always bound. You can pass properties to the context to force it to be openejb one or use openejb:Resource/myDataSource or java:openejb/Resource/myDataSource naming.

sending mail with javamail throws NoSuchMethodError: sun.security.ssl.SessionId.checkLength

My Java ee 8 webapp is using javamail 1.6.1 to send emails via gmail. I'm running it on Glassfish 5, Mac os High Sierra, and Glassfish 5 is set to run on jdk1.8.0_20 and I start it from Netbeans 8.2.
Here's the snippet where it's being done:
Properties props = new Properties();
props.put("mail.smtp.auth", "true");
props.put("mail.smtp.starttls.enable", "true");
props.put("mail.smtp.host", host);
props.put("mail.smtp.port", port);
// Get the Session object.
Session session = Session.getInstance(props,
new javax.mail.Authenticator() {
#Override
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(username, password);
}
});
try {
Message message = new MimeMessage(session);
message.setFrom(new InternetAddress(from));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse(toEmail));
message.setSubject("Testing Subject");
message.setContent(
"<h1>This message is embedded in HTML tags</h1>",
"text/html");
Transport.send(message); // this line throws the exception
} catch (MessagingException e) {
throw new RuntimeException(e);
}
The Transport.send line throws the exception in the title above. More precisely:
Caused by: java.lang.NoSuchMethodError: sun.security.ssl.SessionId.checkLength(Lsun/security/ssl/ProtocolVersion;)V
at sun.security.ssl.HandshakeMessage$ServerHello.<init>(HandshakeMessage.java:504)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:209)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:984)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:919)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1043)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
at com.sun.mail.util.SocketFetcher.configureSSLSocket(SocketFetcher.java:619)
at com.sun.mail.util.SocketFetcher.startTLS(SocketFetcher.java:546)
at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:2135)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:738)
at javax.mail.Service.connect(Service.java:388)
at javax.mail.Service.connect(Service.java:246)
at javax.mail.Service.connect(Service.java:195)
at javax.mail.Transport.send0(Transport.java:254)
at javax.mail.Transport.send(Transport.java:124)
I've found this similar question here but all they say is to make sure that Glassfish is running on JDK 1.8, and mine is.
I noticed that the same javax.mail.Transport class exists in both dependecies, javaee-api and javamail, so I removed javamail from my dependencies in my pom.xml and I could still build the application, but got the same error when trying to send the email.
This is what my pom.xml looks like:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>8.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>javax.mail</artifactId>
<version>1.6.1</version>
</dependency>
Downgrading your JDK is not advisable. I found another solution which worked for me. See Antoine's answer in sun.security.ssl.SSLSessionImpl not found . You can remove the sun.* packages from the relevant file using a zip utility such as 7ZIP.
I haven't tried for this particular error message but I suspect it will be the solution as there seems to be many similar questions related to this package with the same root cause.
I upgraded the JDK 8 to 1.8.0_172 and started getting this other error:
NoSuchMethodError: sun.security.ssl.SSLSessionImpl.<init>(Lsun/security/ssl/ProtocolVersion;Lsun/security/ssl/CipherSuite;Ljava/util/Collection;Lsun/security/ssl/SessionId;Ljava/lang/String;I)V
That apparently is an issue with Glassfish 5 as discussed here.
So I downgraded the JDK 8 version to 1.8.0_152, which solved this problem.
To set netbeans to use the right update of the jdk configure this in the file netbeans_home/etc/netbeans.conf :
netbeans_jdkhome=/Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home

AbstractMethodError with jTDS JDBC Driver on Tomcat 8

I am deploying a web app (WAR) to a Tomcat 8 web container.
The WAR includes in the '/WEB-INF/lib' directory the following jTDS JDBC driver:
<dependency org="net.sourceforge.jtds" name="jtds" rev="1.3.1" />
(file is: jtds-1.3.1.jar).
This is how the resource is defined in META-INF/context.xml:
<Resource name="jdbc/jtds/sybase/somedb"
auth="Container"
type="javax.sql.DataSource"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sybase://localhost:2501/somedb"
username="someuser" password="somepassword"
/>
In my code I obtain the javax.sql.DataSource the normal way:
InitialContext cxt = new InitialContext();
if ( cxt == null ) {
throw new RuntimeException("Uh oh -- no context!");
}
DataSource ds = (DataSource) cxt.lookup( lookupName );
I further verify (by printing) that the DataSource object ds is of the expected type:
org.apache.tomcat.dbcp.dbcp2.BasicDataSource
… but when I try to get a connection out of it:
Connection conn = ds.getConnection();
… I get the following trace:
java.lang.AbstractMethodError
net.sourceforge.jtds.jdbc.JtdsConnection.isValid(JtdsConnection.java:2833)
org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.isValid(DelegatingConnection.java:924)
org.apache.tomcat.dbcp.dbcp2.PoolableConnection.validate(PoolableConnection.java:282)
org.apache.tomcat.dbcp.dbcp2.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:359)
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.validateConnectionFactory(BasicDataSource.java:2316)
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:2299)
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:2043)
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1543)
What gives?
Turns out I had to add:
validationQuery="select 1"
in the Resource declaration in context.xml.
This is mentioned here (although mispelled as validateQuery).
Digging into the implementation of JtdsConnection one sees:
/* (non-Javadoc)
* #see java.sql.Connection#isValid(int)
*/
public boolean isValid(int timeout) throws SQLException {
// TODO Auto-generated method stub
throw new AbstractMethodError();
}
This is really weird, I think AbstractMethodError is supposedly thrown by the compiler only, unimplemented methods ought to throw UnsupportedOperationException. At any rate, the following code from PoolableConnection shows why the presence or not of validationQuery in context.xml can change things. Your validationQuery is passed as the value of the sql String parameter in the below method (or null if you don't define a validationQuery):
public void More ...validate(String sql, int timeout) throws SQLException {
...
if (sql == null || sql.length() == 0) {
...
if (!isValid(timeout)) {
throw new SQLException("isValid() returned false");
}
return;
}
...
}
So basically if no validationQuery is present, then the connection's own implementation of isValid is consulted which in the case of JtdsConnection weirdly throws AbstractMethodError.
The answer mentioned above by Marcus worked for me when I encountered this problem. To give a specific example of how the validationQuery setting looks in the context.xml file:
<Resource name="jdbc/myDB" auth="Container" type="javax.sql.DataSource"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sqlserver://SQLSERVER01:1433/mydbname;instance=MYDBINSTANCE"
username="dbuserid" password="dbpassword"
validationQuery="select 1"
/>
The validationQuery setting goes in with each driver setting for your db connections. So each time you add another db entry to your context.xml file, you will need to include this setting with the driver settings.
The above answer works. If you are setting it up for standalone Java application, set the validation query in the datasource.
BasicDataSource ds = new BasicDataSource();
ds.setUsername(user);
ds.setPassword(getPassword());
ds.setUrl(jdbcUrl);
ds.setDriverClassName(driver);
ds.setMaxTotal(10);
ds.setValidationQuery("select 1"); //DBCP throws error without this query

Exception error in google doc api

I am new to google api. I am trying to create a simple web application (Java EE) to read DocumentListFeed from google doc. My code in the servlet is:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
{
try
{
DocsService service = new DocsService("Document List Demo");
service.setUserCredentials(NAME, PASSWORD);
response.getWriter().println("helloooooo");
//URL documentListFeedUrl = new URL("http://docs.google.com/feeds/documents/private/full");
URL documentListFeedUrl = new URL("https://docs.google.com/feeds/default/private/full?v=3");
DocumentListFeed feed = service.getFeed(documentListFeedUrl, DocumentListFeed.class);
for(DocumentListEntry entry : feed.getEntries())
{
response.getWriter().println(entry.getTitle().getPlainText());
}
}
catch (Exception e)
{
response.getWriter().println(e);
}
}
But it is showing me the error: java.lang.NoClassDefFoundError: com/google/gdata/client/docs/DocsService
I am using Glassfish server and Ecllipse. And added external jar file: activation.jar, guava-r07.jar, mail.jar, servlet.jar, gdata-client-1.0.jar, gdata-client-meta-1.0.jar, gdata-core-1.0.jar, gdata-media-1.0.jar, gdata-docs-3.0.jar, gdata-docs-meta-3.0.jar.
I have copied this same code to java standard edition and it is working fine. Could please tell me why this thing is not working in Java EE? Is it a problem in GlassFish server?
It just means that the jars are not present in your Glassfish server classpath.
Add all the jars you listed to yuor glassfish server classpath. Since am not an Glassfish expert i cannot help you in adding the jars to your server.
In case of weblogic, you just need to package all the jars in your project APP-INF directory.
Hope it helps.