Favil Von

Greenhorn
+ Follow
since Dec 10, 2013
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
2
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Favil Von

So, it turned out that I needed to explicitly name the parameters in my call, which is a good thing:



However, now I'm encountering, what it seems like, an uncommitted insert (note that my update basically inserts a new row and is not an update -- the PL/SQL wrapper's actual functionality is not important here, and I am looking at it as a blackbox for now). When I execute the method, I see it's writing to a row, but the subsequent attempts to run the Junit again would not commit the execute(). Nonetheless, after running the test another time, the insert occurs (what I am observing is that the sequence object [Oracle] is being incremented, but when the table is queried, it seems like one or two sequence numbers have been skipped).

1st call to callSP(), seq number is, say, 1000, with a row entry values
2nd call to callSP(), I don't see any new insert
3rd call to callSP(), no insert is witnessed
4th call to callSP(), seq number is 1003, with a row entry values
5th call to callSP(), no insert is witnessed
6th call to callSP(), seq number is 1005, with a row entry values



Any reason why this behavior is occurring?
10 years ago
Using Spring 3.0, I'm trying to make a stored procedure call using NamedParameterJdbcTemplate but getting a weird exception. My code reads:



Executing the test unit for this method would produce the following exception:



The stored proc works if I employ an extension of StoredProcedure, so I know the store proc works (from the SQL and the code). However, I have not been able to get it to work through templates.

Let me also add that the stored proc takes in 7 parameters, but even if I add an additional "mySqlParameters.addValue()" for the 7th parameter (which I do not update for this particular callSP()) and change the call to "{call MY_WRAPPER(?,?,?,?,?,?,?)}", it still complains about that it expects 0 parameters rather than 7. I have tried to change the SQL string to "MY_WRAPPER", "MY_WRAPPER(?,?,?,?,?,?)" or "call MY_WRAPPER(?,?,?,?,?,?)", but the exception remains.

I tried to pass in the actual SQL string ("myStoredProc") directly to ps.execute() or ps.executeUpdate(), but surprisingly, the debugger doesn't even get to "return ps.execute()" or "return ps.executeUpdate()". Also, I am making the invocation solely for updating and do not expect any data back. Any idea where the issue is orginating?
10 years ago

R. Jain wrote:You've 2 different instances of EmployeeDAO there. In one of them you're injecting dataSource, and in the other one, queryProps. So, for both the instances, one of the Properties references will be null. I suspect you're getting the 1st instance, that is why you're getting queryProps as null.
You need to inject both the properties in the same instance.



You're right. I injected both into a single instance of my DAO class and the Property seems to be populated accordingly. Thank you.

10 years ago


I am trying to load SQL queries from an XML property file and inject it as a java.util.Property into my DAO class. The SQLs.xml resides in the same directory as the application context (I'm using Maven structure, so they all under src/main/resources). My application context file looks like following:


And the SQLs.xml content is:


The DAO class:


I am loading the context file in the Main application with:

I can load the EmployeeDAO without an issue and call on its getEmployee() method. Even the datasource pulls all the needed key/values without an issue. But the queryProps is always null.
10 years ago

Martin Vajsar wrote:According to this table, it is possible to get or set stored procedure parameters by name only since Oracle JDBC driver version 10.1.0. (Generally, Oracle releases a new JDBC driver together with the database, so they usually share the database version number. The files themselves are always named ojdbc5.jar/ojdbc6.jar - hopefully you're not using the really ancient classes*.jar - so you've got to dig into the MANIFEST.MF file inside the jar to determine the driver's version number.)

I'd suggest upgrading to the newest Oracle JDBC driver your target database will support (see Which version?). Perhaps the code will just start working with a newer driver version. If it doesn't, well, you can always set parameters by position, instead of by name (which is what I always do). It should even possible to use positional parameters in JDBC to make a by-name parameters call in the database:

(I haven't tested this myself, I've just found it here.)



According to the ojdbc6.jar that I unraveled, the driver is 11.2, so it should support parameter name (as a matter of fact, it calls addParam() method of OracleCallableStatement). So, I don't believe is the version I am using.

Setting parameters based on position does not produce that error, however, with having 40+ parameters in the proc and 90% not being set (at least from our code), it becomes prone to error if indexing is utilized.

I had actually tried to get it to work by emulating the suggested answer on that page, but was running to some other issues. I had not, however tried your way (I will do that by EOD and let you know).

Tina Smith wrote:What is the signature of the stored procedure that you are attempting to call? Oracle usually has pretty descriptive error messages. Odds are that one of these parameter names does not match the parameter names of the stored procedure, or you have not passed all the parameters the stored procedure requires.

In my experience, case does not matter.



I have copied and pasted the parameter names from the package.procedure's own body in the database, so they are bounded to be corresponding (I've checked them multiple times).

There are several values that need to be passed as NULL due to values not being available. I have placed "null" in their spot, i.e. call MY_PKG.MY_STORE_PROC(?, ?, ?, ?, ?, ?, null)}", which produces the same error. I even passed a dummy value, but the problem persists. It always points to the very first parameter that it attempts to set, no matter which one it is.
Hi,

I'm having issues when I set values for the CallableStatement of Oracle JDBC driver when the parameter names are used.



Running the code would result in the following SQLException:



If I comment out the first setting, I get the same error for the second parameter (and subsequent ones if I go down the list commenting out the next parameter). I can run the procs through a SQL command without an issue.

g tsuji wrote:With keep, you'll see that it generates the needed interfaces (.java), and just like any other code generation in axis or .net or else, wsimport and wsdl won't possibly know the business logic and you've to code their implementation where the business logic goes into. Does it sound logic and reasonable?


I see. I was under the impression that wsimport would generate the implementation and operation "subs" the least (i.e. empty bodies -- some Eclipse tools, like Rational Application Developer do generate such class through web service wizard of some sort). Thanks for clarification.

P.S. Another issue that I ran into is that, with JAXB 2.1 (this problem has been resolved in JAXB 2.2.x apparently), it cannot generate the exception class, if it has been indicated for several of operations in the interface (portType), i.e. assuming all operations advertise that each throws a single type exception. But then again, this is something that can only be remedied by upgrading.

Thanks for your help.
10 years ago

g tsuji wrote:Have you checked out the -keep option?


I thought -keep flag creates portable client artifacts! In either case, -keep option doesn't generate the implementation class when I try it.
10 years ago

This creates a client (extends Service) rather than the service implementations (portType is for the service interface). What node (or option) should I pick for the subs?
Is this not doing what you meant to obtain where the name customized to anything you like and obviously not deliberately to create any collision?


That would change the name of the service interface, and binding the following (note "wsdl:service"),


merely changes the name of the "client proxy" (annotated with @WebServiceClient(...)). I need wsimport to generate the "service implementation" with subs contracted from the service interface (not the client code). Is there something I am doing wrong that the service interface "implementation" is not being generated?
10 years ago

g tsuji wrote:
I use a simpler posting of the problem from your first post.

If you want to customize wsdl proper you can use an external customization file to do that. For the schema part, you've to have jaxb:bindings instead. In case without import or include, all the schema(s) are inline, a single external customization file may be quite doable. But with schema import and include, at present, one would have to use a dedicated jaxb customization file for that purpose. Maybe one day a jaxws:bindings root would be able to consolide the two kinds of bindings including schemas import and include. But, at present, it seems not be the case.



Excellent! Thank you.

So, the trick was to have jaxws in its own binding document, and the schema(s) in its own (jaxb). And also, to set the natural package of the WSDL's targetNamespace first, then set the class names.

Now, the only issue that I have left is that the service implementation sub class does not get generated with the following:



This creates a client (extends Service) rather than the service implementations (portType is for the service interface). What node (or option) should I pick for the subs?
10 years ago

Thank you g tsuji.

I tried your suggestion to replace the root element with jaxws:bindings, however, I am not clear what needs to be changed in the content of the binding document. Are you saying that all the "jaxb:bindings" must now be converted to "jaxws:bindings" (beside the root element)?

I tried many combinations, but none seems to work. They either totally ignore the desired package structure or throw an error during parsing. Here are the things I have tried based on your comment:

1A) Replaced the root element to reflect "jaxws" namespace
1B) Kept all the "schemaBindings" as "jaxb" (with proper namespace as attribute when required)
1C) Only the bindings for the service interface and exception are handled via "<jaxws:bindings>" (as before)

This causes all the packages indicated in the binding file to be ignored (even the schemas where used to work).


2A) Replaced the root element with "jaxws" namespace
2B) Replaced every "jaxb" in the binding file with "jaxws"

This causes the following error:


parsing WSDL...


[ERROR] invalid extension element: "jaxws:package" (in namespace "http://java.sun.com/xml/ns/jaxws")


Failed to parse the WSDL.




Now, if I replace lines 20 and 26 to use "<jaxb:package>" instead of "<jaxws:package>" (with jaxb namespace indicated in "<jaxws:bindings>"), I can by pass the error message, but the packages indicated in the binding file are ignored and default in each schema and WSDL are honored.
10 years ago
Hi,

I'm trying to customize package swhere the service interface and the exceptions of WSDL are generated under using an external JAXB binding document. I'm doing this via wsimport 2.2.4 (and 2.1), but regardless of my binding, it places them in the (reversed) default namespace of WSDL. However, using a customized JAXB binding file(s), the schemas (XSD's) do get placed in the correct packages. Here are my WSDL and external JAXB binding file:

(As I said, the schema bindings work, but the service and exception binding in the WSDL do not)


And the WSDL:



This would place the XSD types that are imported/included in the WSDL under "my.namespace.mytype" and "my.namespace.myothertype" accordingly. However, the exception (ServiceFault) and the service interface (and the implementation respectively) are generated under "namespace.my" (the WSDL's reversed default namespace) rather than "com.myservice.service" and "com.myservice.exception".

I am running the wsimport with the following (all the files are in the same directory: WSDL, XSD's, and JAXB binding documents; MyService.wsdl, MyType.xsd, MyOtherType.xsd, MyFault.xsd (which contains schema for the fault details), MyBinding.xml, ServiceFaultBinding.xml (a binding to place MyFault.xsd type in its own package, which, like other XSD's, do get placed in the correct package)):


10 years ago