Win a copy of Java by Comparison (eBook) this week in the Java in General forum!

Dan Lingard

Greenhorn
+ Follow
since Aug 12, 2009
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
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dan Lingard

Hi all - thanks for the reply, even if it was a little after the fact!

In the end I reported this as a bug to the JDBC provider, and they fixed it to work as I thought it should... Whether this then broke the driver for others I can't say!
5 years ago
Hi all,

I've got (hopefully!) a quick question around WAS 7 and shared libraries. I've not made use of shared libs before, so forgive me if my questions seem a little stupid!

I've got everything working from my development workspace and using an application with shared libraries pointing to JAR files. This is great, but it means I have to keep JAR-ing up my workspace to test out changes I make to the Java code.

Is it possible to use shared libraries but *not* use JARs? Previous to using shared libs I was using the ws.ext.dirs attribute on the server JVM to point to the root folder of various class paths, e.g.

c:\myApplication\myJavaProject\;c:\myApplication\anotherJavaProject\;

This has become something like this in my libraries XML file:



Ideally I'd like to change this so that it worked as before, pointing to the root of the package folder structure:



Unfortunately this doesn't seem to work. Is there something I've missed out, or is this just not possible using shared libs?

Many thanks,

Dan
7 years ago
Hi Selva,

I'm afraid I can't help you, as I don't really use swing in my line of work.

I think you'll have more luck posting in the Swing / AWT / SWT / JFace section of the forums, rather than the JSP section.

Dan
7 years ago
Hi,

I guess your application takes input via JSPs?

1) Are you using Windows? You may find that the input has changed from Chinese to English when you change applications (check the language bar settings).

2) Can you copy and paste the Chinese from notepad into your input field?

3) Do you have the correct page encoding set? You should probably have the charset set to UTF-8 on your JSP page.
7 years ago
Thought I'd post an update, as I think I've solved this!

The issue appears to be because the EJB I'm trying to inject is in a different EAR to the servlet I'm trying to inject it into. As a result, the look up fails. However, if I give it the full JNDI name like so:


It all appears to work. That said, it doesn't seem to be working now, but I'm sure I had it working earlier!

In my case (using IBM's WAS 7.0), the default JNDI name appears to be of the format:

ejb/<EAR Name>/<JAR name within the EAR that contains the EJB>/<Class name of the bean>#<fully qualified name of the interface>

As I said, I'm sure I had the dependency injection working using the method specified above even if it's gone AWOL for the moment. However, the look up using the initial context object certainly works, like so:


Curiously, attempting to combine the obj2 = ... and the cast to the remote interface fails with an exception. Quite why it should work as two separate lines, but fail if I try to combine it like this:


is a mystery, but not one I'm going to look into just now!

Hope this helps any other EJB3 newbies out there - there's loads of documentation, which just meant I got lost looking for specifics!
How odd - changing this hasn't fixed it, with helloRemote still being null.

I used some built in tools to migrate the project from 2.3 to 2.5 and then manually updated the web.xml to fix the issues that arose. It may be that all projects need to be at this level before everything works properly? I'll give that a try and let you know what happened.

Jaikiran Pai wrote:

Dan Lingard wrote:

The stuff in the web-app element looks very different. I've no idea what this means, unfortunately, but I presume this is the root of my problem? Would just changing the web-app line to be in line with my working web.xml be sufficient?


Yes, changing the web.xml to use the 2.5 version of the xsd should be enough. That would then instruct the server that you are deploying a 2.5 version of a web application. Prior versions did not have support for injection into servlets, so containers ignore the annotations in your servlet.

Many thanks Jaikiran - I'll give that a try!

Jaikiran Pai wrote:What is the xsd declaration in the web.xml of your application which is running into trouble? The "version" attribute should be 2.5


You may be on to something here!

It looks like this:



In the project that works, it looks like this:



The stuff in the web-app element looks very different. I've no idea what this means, unfortunately, but I presume this is the root of my problem? Would just changing the web-app line to be in line with my working web.xml be sufficient?

Many thanks for your help - I've been banging my head against a wall the last couple of days trying to work out why this isn't working!

Dan
Hi Jaikiranm,

Earlier versions of WebSphere did not support EJB 3, but the version I'm currently using does (or at least it says it does!).

This question is why I went back to a stand alone simple "hello world" type of bean - this deploys and works fine on my WebSphere server, using DI. My test servlet looks like this:



... and works fine. However, when I try to use my "proper" servlet from my main application, it fails.



The code is the same, which is why I'm confused - it must be some thing to do with my deployment?

Dan
Hi all,

I'm trying to migrate an application from EJB 2 to EJB 3, and I've encountered a problem with dependency injection.

I've got a really simple bean, pretty much defined as on this tutorial: http://www.webagesolutions.com/knowledgebase/waskb/waskb032/index.html

I can deploy this to my server (WebSphere Application Server 7), run the test servlet, and everything appears to work fine.

However, when I try to use this simple bean in an existing servlet within my application, the dependency injection fails (no error message, but the object is null), and I'm stumped as to why. Is it because it exists within a different EAR to my main project?

Also, how do I use the bean if I can't use DI? I haven't defined anything in terms of deployment descriptors or JNDI files, but I don't believe that I need to. However, I don't know what the JNDI name is of my bean, so looking it up is proving a little tricky! Does anyone know how I define the JNDI name, and if this is done via the annotation?

Any help or guidance would be gratefully received!

Dan
Hi Paul,

Thanks for your response. I create the buffer by appending the various field values to a StringBuffer, and then doing a .toString on it (code snippet in my original post). I've gone so far as to create a byte array working through the characters in each field and then later creating a string from the array, but with the same effect when I come to inspect it in debug (although I think the order is maintained correctly within the array).

Something I have noticed is that if I paste the buffer into MS Word, the order is correct - if I post it into notepad, the order is messed up. However, I have inspected the buffer when it's passed to the stored procedure via a callable statement, and unfortunately it's this messed up version of the buffer that makes its way across the JDBC connection.

Any options or light you (or anyone else) can shed on this would be greatly appreciated.

Dan
8 years ago
Hi all,

I hope someone knows the answer to this issue!

I've got an application in Java which calls another app via a callable statement, passing various parameters across. One of these parameters is a buffer containing transaction information.

Now we're working on an Arabic proof of concept, and when I create this buffer containing both Arabic, Latin and numeric data, the order of the string is messed up.

E.g.

The data may be:

I
AED
17
شارة النقاط
1.7
101010
Test seventeen
17D

This appears in the buffer (with some padding) as:
IAED17شارة النقاط 1.7 101010Test seventeen 17D

As you can see, the order has changed - the numeric fields appear to have been included with the Arabic text.

This causes the API we're calling to break, as you can imagine - expected fields are not appearing in the right place.

The string is being built as follows:
StringBuffer paramBuffer = new StringBuffer(BUFFER_INITIAL_CAPACITY);
while (iterator.hasNext()){
String fieldName = iterator.next().toString();
// Get Object using field name from Vector.
FieldApi field = (FieldApi)fields.get(fieldName);

tempCtr = tempCtr + field.getLength();
if (field.getLength() == 0) {
break; // We have reached end of the fields
}

//Add each formatted field to param.
paramBuffer.append(field.getString());
}
}

Now, I suspect that I could get around this by constructing a byte array and using a setBytes method on my callableStatement. However, the set up of my JDBC connection means that I can't use setBytes (translateBinary is set to true, giving a data type mismatch exception), and this set up is something I can't change.

I'm sure this is a problem with the fact that Arabic languages are right to left rather than left to right, and the String I create attempts to format it in this manner (and gets it wrong). Is there a way I can tell the String to leave things exactly as they're added, rather than messing around with them?

Any help would be appreciated! :-)

Cheers,

Dan
8 years ago