I desire NOT to incorporate Spring with the mix I have.  I will if that is the 
standard way, but not sure how you would do that.

    On Monday, July 30, 2018, 12:29:20 PM EDT, Mark Nuttall 
<mknutt...@gmail.com> wrote:  
 
 Are you using Spring with the Java DSL? Just not sure if you are / aren't.

On Mon, Jul 30, 2018 at 11:45 AM, John F. Berry <bohnje...@yahoo.com.invalid
> wrote:

> Thanks Quinn for the helping hand.
>
> I've been looking for examples of how to declare the servername/instance
> name, username password to utilize a MS SQL endpoint.  Looking at the
> Apache Camel: SQL Component page, it shows utilizing  the declared object
> like "mydbconnection" that is the named DataSource option, and shows all on
> what you can throw through that connection... except seems to skip over how
> to specify connection criteria.  It does reference the DataSource option as
> a pointer to look up in the "registry" but I don't know if that is an
> inherited existing entity it's talking about or the need to declare a new
> registry and import a form of camel registry or something.  The only
> examples where I've seen servername, un/pw declared in an example was in a
> Spring one.  I don't know if we want to "un-translate" a Spring example,
> but point me in the direction of where I should natively set these things
> in Java DSL.  The above mentioned page even says "This component uses
> spring-jdbc behind the scenes for the actual SQL handling", so I figured
> that is why I cannot seem to get away from Spring.
> When I look at the Apache Camel: SQL Example( http://camel.apache.org/sql-
> example.html )  page, it talks about "In the camel-context.xml file in
> the src/main/resources/META-INF/spring folder we have the Spring XML file
> to setup and configure the database"
>
> I see connection parameters set like in this other example:
>
> <bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource"
> destroy-method="close">
> < property  name = "driverClassName"  value = 
> "org.apache.derby.jdbc.EmbeddedDriver"
> />
>
> < property  name = "url"  value = "jdbc:derby:memory:orders;create=true"
> />
>
> < property  name = "username"  value = "" />
>
> < property  name = "password"  value = "" />
>
> </bean>
>
>
> but not declared in the Java DSL, if that's even possible.. Perhaps
> .setheaders() ?  but then.. what are the paramater names?
>
>
> Sorry.. I know it's a bit of a "thrashing" response...
>
>
>
> On Monday, July 30, 2018, 10:43:34 AM EDT, Quinn Stevenson <
> qu...@pronoia-solutions.com> wrote:
>
>
>
>
>
> From my experience, I’ve always been able to to more with the Java DSL
> than with Spring.  I think routes written using the Spring XML are easier
> to read than routes written the Java DSL, but that’s just me.
>
> If you could post you’re Spring XML that you’re trying to translate, I’m
> sure we can help with that.
>
> > On Jul 30, 2018, at 8:00 AM, John F. Berry <bohnje...@yahoo.com.INVALID>
> wrote:
> >
> > I've been perusing ways to declare connection to a MS SQL server.  There
> are plenty of Spring examples.. but how about Java DSL?  I have been
> attempting to utilizing the JDBC endpoint provided though camel-sql.. but I
> cannot seem to either find documentation of how to place a configuration
> file with an unknown name in an unknown location in the project, or declare
> it in-line.  Been looking at setting it first in the "camel registry", but
> no luck so far.
> > I did not include any code, since I have nothing functional or "in
> progress" to show for my efforts.  I'm not to the point I need to form any
> sort of SQL statement yet, since I cannot establish a connection.It seems
> so simple, but I cannot find how to simply declare server:port, un/pw
> without bringing a Spring context into the mix.  If that is needed to
> satisfy the camel vanilla SQL endpoint needs, how do I tie that into the
> Java DSL route I've already got going?  I went the Java DSL route simply
> because some other endpoints didn't have a straight forward Camel Spring
> solution to them.  Is this mixed environment normal?  Is there really not a
> choice to keep a route "clean" in one coding style or the other?
> > Thanks!
>  

Reply via email to