I have an applicationContext xml file that imports multiple resources (camel context files).
<import resource="AddRequest.xml" >
<import resource="AdviseRequest.xml" >
I am caching the definitions of this xml before hand using new FileSystemXmlApplicationContext().
Say AddRequest.xml uses some method to connect to some host, while AdviseRequest.xml uses CXF endpoint to SOAP.
When I try to load the applicationContext xml, it tries to caches both files first before actually starting camelContext. At this stage, it is trying to check the CXF endpoint availabilty. Is there anyway to handle this, if the soap wsdl is actually down ?
The reason is, if there's some connection issues in the second xml, my first xml also fails, as it tries to cache both at a time.
Note: I cannot use two separate applicationContext files
I have used below code in the camel route.
<onException id="Request_onException1">
<exception>java.net.ConnectException</exception>
<handled>
<constant>true</constant>
</handled>
</onException>
Related
I'm trying to use the Ignite Jdbc connection; with my goal to be able to call the cache from any client over Jdbc.
I've got a number of scenario's working; so have data loaded correctly; and can run sql queries 'directly' against the cache.
When I try to call from a separate client with
ResultSet rs = conn.createStatement().executeQuery("select * from my_table");
I hit an error:
class org.apache.ignite.IgniteCheckedException: Failed to find class with given class loader for unmarshalling (make sure same versions of all classes are available on all nodes or enable peer-class-loading) [clsLdr=URLClassLoader with NativeCopyLoader with RawResources(
Is there a way to prevent the Ignite jdbc connection from trying to do any unmarshalling?
I would like my client to be as agnostic as possible to the Ignite classes. For example; I would like to swap out calling mariaDb to Ignite - with as little code change as possible on the client side.
If I'm thinking about things the wrong way; then answer along the lines of No, that will never work because ... are more than welcome too.
Thanks
Brent
If you don't want copy libs to client's lib folder, you can turn on Peer Class Loading:
<bean class="org.apache.ignite.configuration.IgniteConfiguration">
...
<!-- Explicitly enable peer class loading. -->
<property name="peerClassLoadingEnabled" value="true"/>
...
</bean>
Also, you can work with BinaryObject, instead of your classes. Here is some example of using sql with BinaryObjects. More information on the binary format is provided here.
I have a problem similar to the one described here.
I am using RESTEasy within a standalone Jetty application. When I start the application locally and call a service (e.g. localhost:16880/rest/user/login) bean validation works fine, i.e. I get validation errors like this:
[PARAMETER]
[UserService#login(arg0).appKey]
[app_key may not be null or empty]
[]
However, when I deploy my application to a remote host and call the same service (e.g. remotehost:16880/rest/user/login) bean validation is not invoked at all.
I am using the #ValidateRequest annotation for the service and #Valid annotation for the bean parameter.
My Resteasy version is 3.0.13.Final, though I have tried earlier versions as well. I have tried to write my custom validator, but that didn't work either.
I am puzzled why the validation works locally, but not on remote server. Any suggestions would be highly appreciated.
Since you are using Jetty as standalone server, you have to define RESTEasy validation providers where you define ServletContextHandler. Note that in standalone server there is no container to scan for #Provider classes and to activate them, so you must do it manually.
I expect that you create and start your server app something like:
//create a server listening at some port
Server server= new Server(port);
//add server handlers
HandlerList handlers= new HandlerList();
initHandlers(handlers);
server.setHandler(handlers);
//start the server
server.start();
In initHandlers you must have defined your RESTEasy support:
public void initHandlers(List<HandlerList> handlers) {
//define root context handler
ServletContextHandler servletContextHandler= new ServletContextHandler(ServletContextHandler.SESSIONS);
servletContextHandler.setContextPath("/");
handlers.addHandler(servletContextHandler);
//define RESTEasy handler
ServletHolder restServlet= new ServletHolder(new HttpServlet30Dispatcher());
//since this is a standalone server, somewhere you have to define RESTful services and Singletons
restServlet.setInitParameter("javax.ws.rs.Application", "com.exampleapp.MyRestApplication");
restServlet.setInitParameter("resteasy.servlet.mapping.prefix", "rest");
servletContextHandler.addServlet(restServlet, "rest/*");
}
So what is left to do now is to add Validation provider as init parameter:
restServlet.setInitParameter("resteasy.providers", "org.jboss.resteasy.plugins.validation.ValidatorContextResolver,org.jboss.resteasy.api.validation.ResteasyViolationExceptionMapper");
On this link I tried to find the name of the validator providers: https://docs.jboss.org/resteasy/docs/3.0.4.Final/userguide/html/Validation.html
RESTEasy obtains a bean validation implemenation by looking in the available META-INF/services/javax.ws.rs.Providers files for an implementation of ContextResolver
So it does not say what, but says where. Now open the "resteasy-hibernatevalidator-provider-3...*.jar (from Eclipse -> Maven dependencies or manually unzip) and look into META-INF/services/javax.ws.rs.ext.Providers It says:
org.jboss.resteasy.plugins.validation.hibernate.ValidatorContextResolver
org.jboss.resteasy.api.validation.ResteasyViolationExceptionMapper
If you don't have this dependency, then add it to your pom file:
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-hibernatevalidator-provider</artifactId>
<version>${resteasy.version}</version>
</dependency>
One more note: that at the same place where you described validation providers, you also add other providers, if you happen to need them (such as JacksonJaxbJson, etc).
Deploying an application in WAS 8 gives me an error:
Cannot find a match for supplied option: "[ejb.jar, ejbName, ejb.jar,META-INF/ibm-ejb-jar-bnd.xml, ejb/ejbName]" for task "BindJndiForEJBNonMessageBinding"
my entry in ibm-ejb-jar-bnd.xml
<session name="ejbName">
<interface class="com.manager.EJBNameManager" binding-name="ejb/ejbName"/></session>
my entry in deploy.jacl
[-BindJndiForEJBNonMessageBinding ejb.jar ejbName ejb.jar,META-INF/ibm-ejb-jar-bnd.xml ejb/ejbName]
my ejb.jar structure has META-INF/ibm-ejb-jar-bnd.xml also.
Was my entry in ibm-ejb-jar-bnd.xml correct? Please enlighten me on this one. Thanks.
Instead of providing the path to your ejb jar bindings (ejb.jar,META-INF/ibm-ejb-jar-bnd.xml), you should be providing the path to your ejb deployment descriptor (e.g. ejb.jar,META-INF/ejb-jar.xml).
In addition, you shouldn't even need the ejb bindings file, because you are creating the binding using JACL. The ibm-ejb-jar-bnd.xml file will automatically be created for you as a result of your deployment.
(Also, as a side note, WAS deprecated its use of JACL in WAS 7, so you should consider using jython for your wsadmin scripts instead.)
I have a web-app that requires two settings:
A JDBC datasource
A string token
I desperately want to be able to deploy one .war to various different containers (jetty,tomcat,gf3 minimum) and configure these settings at application level within the container.
My code does this:
InitialContext ctx = new InitialContext();
Context envCtx = (javax.naming.Context) ctx.lookup("java:comp/env");
token = (String)envCtx.lookup("token");
ds = (DataSource)envCtx.lookup("jdbc/datasource")
Let's assume I've used the glassfish management interface to create two jdbc resources: jdbc/test-datasource and jdbc/live-datasource which connect to different copies of the same schema, on different servers, different credentials etc. Say I want to deploy this to glassfish with and point it at the test datasource, I might have this in my sun-web.xml:
...
<resource-ref>
<res-ref-name>jdbc/datasource</res-ref-name>
<jndi-name>jdbc/test-datasource</jndi-name>
</resource-ref>
...
but
sun-web.xml goes inside my war, right?
surely there must be a way to do this through the management interface
Am I even trying to do the right thing? Do other containers make this any easier? I'd be particularly interested in how jetty 7 handles this since I use it for development.
EDIT Tomcat has a reasonable way to do this:
Create $TOMCAT_HOME/conf/Catalina/localhost/webapp.xml with:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiResourceLocking="false" privileged="true">
<!-- String resource -->
<Environment name="token" value="value of token" type="java.lang.String" override="false" />
<!-- Linking to a global resource -->
<ResourceLink name="jdbc/datasource1" global="jdbc/test" type="javax.sql.DataSource" />
<!-- Derby -->
<Resource name="jdbc/datasource2"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.apache.derby.jdbc.EmbeddedDataSource"
url="jdbc:derby:test;create=true"
/>
<!-- H2 -->
<Resource name="jdbc/datasource3"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.h2.jdbcx.JdbcDataSource"
url="jdbc:h2:~/test"
username="sa"
password=""
/>
</Context>
Note that override="false" means the opposite. It means that this setting can't be overriden by web.xml.
I like this approach because the file is part of the container configuration not the war, but it's not part of the global configuration; it's webapp specific.
I guess I expect a bit more from glassfish since it is supposed to have a full web admin interface, but I would be happy enough with something equivalent to the above.
For GF v3, you may want to try leveraging the --deploymentplan option of the deploy subcommand of asadmin. It is discussed on the man page for the deploy subcommand.
We had just this issue when migrating from Tomcat to Glassfish 3. Here is what works for us.
In the Glassfish admin console, configure datasources (JDBC connection pools and resources) for DEV/TEST/PROD/etc.
Record your deployment time parameters (in our case database connect info) in properties file. For example:
# Database connection properties
dev=jdbc/dbdev
test=jdbc/dbtest
prod=jdbc/dbprod
Each web app can load the same database properties file.
Lookup the JDBC resource as follows.
import java.sql.Connection;
import javax.sql.DataSource;
import java.sql.SQLException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
/**
* #param resourceName the resource name of the connection pool (eg jdbc/dbdev)
* #return Connection a pooled connection from the data source
* associated with resourceName
* #throws NamingException will be thrown if resource name is not found
*/
public Connection getDatabaseConnection(String resourceName)
throws NamingException, SQLException {
Context initContext = new InitialContext();
DataSource pooledDataSource = (DataSource) initContext.lookup(resourceName);
return pooledDataSource.getConnection();
}
Note that this is not the usual two step process involving a look up using the naming context "java:comp/env." I have no idea if this works in application containers other than GF3, but in GF3 there is no need to add resource descriptors to web.xml when using the above approach.
I'm not sure to really understand the question/problem.
As an Application Component Provider, you declare the resource(s) required by your application in a standard way (container agnostic) in the web.xml.
At deployment time, the Application Deployer and Administrator is supposed to follow the instructions provided by the Application Component Provider to resolve external dependencies (amongst other things) for example by creating a datasource at the application server level and mapping its real JNDI name to the resource name used by the application through the use of an application server specific deployment descriptor (e.g. the sun-web.xml for GlassFish). Obviously, this is a container specific step and thus not covered by the Java EE specification.
Now, if you want to change the database an application is using, you'll have to either:
change the mapping in the application server deployment descriptor - or -
modify the configuration of the existing datasource to make it points on another database.
Having an admin interface doesn't really change anything. If I missed something, don't hesitate to let me know. And just in case, maybe have a look at this previous answer.
I am new to jboss and i have been asked to incorporate jboss connection pooling mechanism with an existing web application. Considering that a web application database layer is properly written i.e. all resultsets, statements and connections being closed properly when not needed, What all code changes i will have to make in my web app after i have configured the jboss datasource properly.
Can anybody please point me to a tutorial or a code sample which uses jboss datasource in a web app.
first create an xml file by name xxx-ds.xml and place this file in server/default/deploy/xxx-ds.xml
<datasources>
<local-tx-datasource>
<jndi-name>/jdbc/Exp</jndi-name>
<type-mapping>SQL</type-mapping>
<connection-url>jdbc:microsoft:sqlserver:// </connection-url>
<driver-class>com.microsoft.jdbc.sqlserver.SQLServerDriver</driver-class>
<user-name></user-name>
<password></password>
<min-pool-size>5</min-pool-size>
<max-pool-size>1000</max-pool-size>
</local-tx-datasource>
</datasources>
jboss-web.xml
<jboss-web>
<!-- <security-domain flushOnSessionInvalidation="false"/>-->
<!-- <context-root>/BSI</context-root>-->
<resource-ref>
<description>Database connection resource</description>
<res-ref-name>jdbc/Exp</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<jndi-name>java:/jdbc/Exp</jndi-name>
<res-auth>Container</res-auth>
</resource-ref>
</jboss-web>
web.xml
<resource-ref>
<description>Database connection resource</description>
<res-ref-name>jdbc/Exp</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
and now in your .java file
javax.naming.Context ctx1 = new javax.naming.InitialContext();
javax.sql.DataSource ds = (javax.sql.DataSource) ctx1.lookup("java:comp/env/jdbc/Exp");
con = ds.getConnection();
***** make sure that resource ref name should be same in all place
The pool in JBoss is all handled in the DataSource configuration. Here is the HowTo. The web app would have to do a JNDI lookup for the datasource to get the database connection rather than doing a direct JDBC URL, and then you will have pooling.
Transactions are another story, though.
EDIT: In response to your comment about how this affects the code, this is what it looks like:
String jndiPath = "java:DataSourceJNDIName"; //The exact prefix here has a lot to do with clustering, etc., but if you are using one JBoss instance standalone, this works.
Context ctx = new InitialContext();
DataSource ds = (DataSource) PortableRemoteObject.narrow(ctx.lookup(jndiPath), DataSource.class);
Connection c = ds.getConnection();
Technically speaking the PortableRemoteObject.narrow isn't necessary in a JBoss (4.2.2 anyway) single server configuration for sure, but it is more proper J2EE standard code, as general application servers don't have to return an object of the right type just for doing a Context.lookup.
The above doesn't cover the resource utilization and error handling issues. You are supposed to close that Context object when you are done with it, and of course the database connection, although JBoss will yell at you if you forget to close the database connection and the transaction ends, and close it for you.
Anyway, that Connection object is usable just as much as DriverManager.getConnection(url);
You don't have to change anything.
When you select the right kind of data source (local-tx-datasource / xa-datasource), connection handling and TX is done for you. In $JBoss/docs/examples/jca you will find templates for virtually every database, that you can just reuse.
If you are using XA, you need to configure Tx-recovery. See this posting on a how-to:
http://management-platform.blogspot.com/2008/11/transaction-recovery-in-jbossas.html (well, perhaps not a how-to in the standalone mode, but in conjunction with the Jopr source code).