Problem retrieving DataSource in Wildfly: javax.naming.NameNotFoundException

Question

Problem retrieving DataSource in Wildfly: javax.naming.NameNotFoundException

Navigation

#1 by (5 votes)

4

I'm trying to establish a connection using DataSource, and it's returning the following error:

Feb 08, 2016 8:15:03 PM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.2.Final
Feb 08, 2016 8:15:03 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.2.Final
Feb 08, 2016 8:15:03 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version (unknown)
Feb 08, 2016 8:15:04 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
INFO: EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
Feb 08, 2016 8:15:04 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@2a556333, receiver=Remoting connection EJB receiver [connection=Remoting connection <b96b4f4>,channel=jboss.ejb,nodename=ingo-pc]} on channel Channel ID de71a44d (outbound) of Remoting connection 0f720e7c to localhost/127.0.0.1:8080
Feb 08, 2016 8:15:04 PM org.jboss.ejb.client.EJBClient <clinit>
INFO: JBoss EJB Client version 2.0.1.Final
javax.naming.NameNotFoundException: jboss/datasources/trabalhoes14bim -- service jboss.naming.context.java.jboss.exported.jboss.datasources.trabalhoes14bim
    at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:104)
    at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
    at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
    at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:127)
    at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Exception in thread "main" java.lang.NullPointerException
    at col.cliente.ColCliente.consultaClientePorCPF(ColCliente.java:136)
    at manager.cliente.UCCliente.cadastrarCliente(UCCliente.java:32)
    at view.teste.Main.populate(Main.java:73)
    at view.teste.Main.main(Main.java:277)

I'm not able to resolve, I retrieve DataSource remotely from JNDI, as below:

public static void getConnection() {

    DataSource ds = null;

    try{
        Properties properties = new Properties();
        properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
        properties.put(Context.PROVIDER_URL,"http-remoting://localhost:8080");
        properties.put(Context.SECURITY_PRINCIPAL, "user");
        properties.put(Context.SECURITY_CREDENTIALS, "password");

        properties.put("jboss.naming.client.ejb.context", true);

        Context init = new InitialContext(properties);
        Context ctx = (Context) init.lookup("java:");
        ds = (DataSource)ctx.lookup("jboss/datasources/trabalhoes14bim");
        ctx.close();
        con = ds.getConnection();
    } catch (NamingException e) {
        e.printStackTrace();
    } catch (SQLException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }

}

I'm using the server - WildFly 10.0.0 Final - Eclipse Luna - MySQL 5.0.7

java wildfly jndi

asked by anonymous 08.02.2016 / 23:21

1 answer

Python how to print output Check the integrity of batch video files

score 5 · Accepted Answer

In a nutshell: can not do remote lookup of a datasource on JNDI in versions higher than JBoss AS 7 .

I'll show you a basic example of how a client might try to retrieve a datasource from JNDI in versions higher than JBoss AS 7, showing some problems that occur and what makes it impossible to do this. >

I'm considering that your AS is all set up, so I will not treat any of this, only the post-declaration phases of datasource .

Below is a common example of how we usually declare datasources on Wildfly:

<datasource jta="true" jndi-name="java:jboss/datasources/SOPT" pool-name="poolSOPT" enabled="true" use-ccm="true">
    <connection-url>jdbc:postgresql://192.168.99.10:5432/stack</connection-url>
    <driver>postgresql</driver>
    <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
    <pool>
        <min-pool-size>5</min-pool-size>
        <max-pool-size>30</max-pool-size>
        <use-strict-min>false</use-strict-min>
        <flush-strategy>IdleConnections</flush-strategy>
    </pool>
    <security>
        <user-name>postgres</user-name>
        <password>postgres</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
        <background-validation>true</background-validation>
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
    <timeout>
        <blocking-timeout-millis>30000</blocking-timeout-millis>
        <idle-timeout-minutes>5</idle-timeout-minutes>
    </timeout>
    <statement>
        <prepared-statement-cache-size>1000</prepared-statement-cache-size>
        <share-prepared-statements>true</share-prepared-statements>
    </statement>
</datasource>

This will be our first attempt at testing (with the exception of jndi-name , as discussed below) and after starting the AS it is expected that the datasource will be published, as shown below:

INFO  [o.j.a.c.s.datasources] (MSC service thread 1-13) JBAS010400: Bound data source [java:jboss/datasources/SOPT]

As our test is for remote recovery of the resource, let us first make a change, as noted below:

Only features published in java:jboss/exported are accessible remotely

That said, our jndi-name will not be java:jboss/datasources/SOPT , but java:jboss/exported/datasources/SOPT , in addition to removing the jta attribute. With this, with the server running, we will now create a client class to retrieve the datasource. I will set the properties directly in the code, but you can create a file named jndi.properties , by default the InitialContext retrieves information from there.

I've created a project

09.02.2016 / 19:43