Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!

Nancy Lehrer

+ Follow
since Aug 28, 2002
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Nancy Lehrer

Can someone give me some pointers on how to deplpy a JWSDP developed SOAP service within a weblogic 8.1 sp 4 container.

My SOAP service is developed for document/literal style with no java binding. In other words, I pass SOAPElement directly to my implementation class. This allows me to selectively validate portions of the XML body so that I can do partial processing if possible. I use of Xalan to process the SOAPElement body and ultimately JAXB for the portions I'm going to process fully.

I have the service running beautifully in Tomcat, but my IS Dept will only support WebLogic 8.1 in production. The WebLogic 8.1 SOAPService development tools are not compatible with Xalan processing of the SOAP bodies (see below)


P.S. Info to the unsuspecting - SOAP services developed with WebLogic 8.1 sp 4 (and lower) tools (servicegen, wsdl2service, wspackage) CANNOT use Xalan or Jaxb to process the SOAP message. After hours of work with BEA Support they have confirmed this too. The problem is that the SOAPMessage and SOAPElement passed to implementation class inherits from a proprietary weblogic implementation of SOAPElement which DOES NOT inherit from org.w3c.dom.Node - therefore it cannot be passed into Xalan, Xerces, or JaxB methods.
16 years ago
Have you thought about puting the byte array into the RMS. This will move it out of memory, but make it available for the future. Also, if the user exits your app (or the app or jvm crashes... ), the image are still available.
The RMS API is quite easy to use, especially with byte arrays.
Some notes: The RMS implementation is slow to create new records, but writing and reading are "relatively" fast. So I would recommend that if can leverage the fact that your images are all the same size (i.e. the byte array is always the same size), you can reuse the records in the RMS.
Good luck.

Originally posted by Christian Wolf:

I just found out that converting a bytearray to string and back messes up the data due to some encoding issues. So if you sometimes get a byte array, do not convert this unless you know what you do. Using the original byte array for Image.createImage works quite fine.
Christian Wolf

18 years ago
I have determined that you need to use an SMS broker such as SimpleWire in order to send an SMS message from a server application to the phone.
Some folks set up their own "SMS server" by thethering a phone to their computer and using AT commands...
The cost to run an SMS message through a broker service varies upon carrier. The carriers charge the broker for sending the message, and the phone user gets charged for receiving the message.
From SimpleWire, Nextel is the least expensive at around 1.5 cents per message and ATT is the most expensive at 8.5 cents per message.
I think I will use sockets to notify my devices :0
18 years ago
Yes, JSR 212 seems to be exactly what I need, but alas is there no current implementation of a server-side SMS API?
Our DispatchSuite application is currently in production using a polling model (MIDP 1.0). By the end of this year we will have over 1000 end-users. The JumpStart Wirless DispatchSuite is a serious business application used send and receive work orders and work order data to/from mobile dispatched workers. So where having a phone be a WMA server seems like an interesting approach for a research project, I'm not sure it will scale to our needs. Would we put the phone in our data center ?
The Nokia Mobile Server looks way too heavy - really an app server all of its own. We already have a rather extensive J2EE server-side app (for the Dispatcher and office operations) running on WebLogic and MYSQL.
For the MIDP 2.0 implementation we are targeting the Nextel/Motorola i730 and the new generations of Nokia series 60 phones that will be running MIDP 2.0. I have posted to the Nextel board and will post to the Nokia forum.
Let me know if you think of anything else. I will experiment with the phone-based WMA gateway just for fun. (Hmm, I think I will need to buy another Motorola i730 as I'll need one to test the SMS Push and one for the gateway..)
18 years ago
I'm researching the use of Push technology in MIDP 2.0 on the iDEN network to send notifications to our DispatchSuite application that new dispatch data is ready on the server. I am trying *real hard* to avoid reqiring static IPs for our application to work, so I want to use the SMS protocol for the push registration.
The payload of SMS message we need to send is really a non-issue. All we want to do tell the handset to wake up and use it normal http GET mechanisms to get any waiting messages from our server. So there may be a control bit or two, but size is of no consequence.
The question is: what is required to send an SMS message over the iDEN nextwork to our J2ME application?
Do email messages automatically get transfered into SMS messages. So, would an email message to send using the JavaMail API translate to an SMS message when it gets to the phone? And what is the port that I should register from the phone?
Or do I need to use an "SMS broker" such as Simplewire and use the Simplewire SDK.
Thanks in advance for your knowledge,
Nancy Lehrer
JumpStart Wireless
18 years ago
Does anyone know where I can get the Java specifications for some of the phone models below. Specifically I am looking for the RAM/Heap, data space, and max jar size.
Siemens SL56
Panasonic GU87
NEC 515
Samsung V206
LG LX 5350
Sanyo SCP-4900, 5300, 8100
Nokia and Motorola make if fairly easy to find this info, but these phones ellude me.
18 years ago
If you are just experimenting, then it probably doesn't matter much.
If you are seriously trying to develop a business application, you need to ask a different question.
What carrier has better support for testing and distributing my application?
As far as maturity with this, I think that NexTel is way ahead of the pack. This would mean that you should work with Motorola iDEN phones such as the i88, i90 or i95cl. The big drawback to NexTel/Motorola is that they only support over the air provisioning through their proprietary technology. They do not support downloading jar's via a jad file.
If you want to work with Nokia, join the ATT developer community. I belive they support the standard over-the-air downloads as described at
Also, you want to make sure you get a platform that is big enough for what you want to do. Color is also a feature you might want to consider.
There is also the Motorola T720 offered by T-Mobile and others. But I find it slower than the iDEN phones under NexTel.
Hope this helps,
[ February 03, 2003: Message edited by: Nancy Lehrer ]
19 years ago
I have had very mixed results with POST to various different web servers. I believe the problem is related to a web server's ability to handle Http 1.1 "chunked" messages.
In my application, I use POST to send data to and from our server, but since I can control both the sending and receiving side, we use DataInputStreams to encode the body of the message.
Have you tried using GET. If the query string is not too long, it might work fine.
19 years ago
According to the MIDP documentation, screen.setTicker(null) is supposed to remove a ticker from a screen, however when I issue this command it just causes a NullPointerException during the painting of the screen.
I am executing within Sun's WTK 1.0.4
Good news, it seems to work on the i95cl fine. I haven't tested on the i85, but that will be next.
Anyone else seen this problem?
(stack trace)
at javax.microedition.lcdui.Screen.paint(+106)
at javax.microedition.lcdui.Display.serviceRepaints(+105)
at javax.microedition.lcdui.Display$DisplayAccessor.timerEvent(+
at com.sun.kvem.midp.lcdui.EmulEventHandler$
19 years ago
It looks like Kada Systems will be supporting MIDP on the Palm. The word I have from a sales guy there that they are targeting a release for late Feb.
They have just released a version of MIDP for the PocketPC.
Check out their Mobile Developers Network at
[ January 30, 2003: Message edited by: Nancy Lehrer ]
19 years ago
I've been developing J2ME apps for nearly a year now and we are
looking to port to the Palm OS.
Can someone point me in the right direction to get started either with
the raw runtimes provide by IBM or with wssd?
Read on for more background as to where I am at.
From my research, it looks as thought J9 from IBM and the Sun
reference implementation are the only available options. For several
reasons (speed, odd implementation, awt like extensions) I'd like to
use J9, but I'm having difficulties unraveling how exactly to use the
tools I've gathered.
I have downloaded, installed, etc the eval version of wssd, but it
seems not to find the runtime executables. Which is ok by me because
I'd actually rather stay with my current dev environment and just
leverage the J9 jvm.
Developing for NexTel, I would compile and preverify using ant, and preverify executable that come from Sun's Wireless
Toolkit. I'd jar up the results and create a jad file, load to the
phone - voila! a MIDlet on my phone.
Using J9, I'm assuming, I would compile against the .zip files that
are under D:\IBM\wsdd\wsdd4.0\ive\runtimes\palmos\68k\ive\lib\jclMidp
then preverify, and jar as before.
I tried this approach and loaded both the
onto my palm emulator.
Creating a prc from the jar/jad pair, but I got the following error
when trying to launch from the palm emulator:
Applications (3.5) called SysFatalAlert with message:
"LauncherMain.c, Line 9395, owner app not found"

Any pointers would be appreciated.
Nancy Lehrer
Sr. Architect
JumpStart Wireless
19 years ago
Here is what I have finally found. Just as background, I am porting a fairly substantial business application from the J2ME MIDP environment to a PDA environment. The LCDUI in the J2ME MIDP/CLDC stack just looks far too clumbsy on the larger PDA screens.
Espresso from is very nice, but very expensive. Not only do they want over $10K for the dev licence, they also want a hefty RTU licence for each product you sell. They are more in the market of selling full java environments for large platform companies to embed in their products. For example, Samsung might want to sell a PDA based on a Java OS and need a PIM. Hence, their prices are not aimed at the ISV.
On the other hand, I found this very nice package from a cool group of 4 guys from Belarus Look at the LwVCL from The documentation is somewhat sparse, but nothing that a good Java Developer can't work with. Although they don't mention it explicitly, it works beautifully in the pjava (PersonalJava) environment (my target environment) and it actually is aimed not at being built ontop of AWT, but replacing it with a more efficient GUI library. It looks very promising so far.
I also know about SuperWaba, but alas, since SuperWaba has a very small intersection with java (only java.lang), I would need to rewrite all my non-API code too.
Thanks for all the responses, and I hope that this information is useful for others.
19 years ago
If you just need something small for persisting your Java object, I've recently uncovered a product at call PJODe (The PesonalJavaTM Object Database Solution)
I haven't used it yet, but I plan on using it soon.
19 years ago
I am looking for AWT 1.1.8 compatible widget sets for a PersonalJava project I am working on. Specifically, I need something that behaves very similarly to the the javax.microedition.lcdui.List object. I need both the ability to display an image and label as essentially a link. I am going to start working on a little widget of my own, but 5 years ago AWT widget sets abounded. Alas, I have a short memory for where they lived '
I will also be looking for a calendar widget.
With the new Personal Profile in the works, I imagine this topic will really heat up!
19 years ago