Okay, let me start of with stating that I am probably doing something wrong here, but yesterday I was amazed by the speed of Sun AS 9.
I'm working on a backend system that uses JPA, and connects with a MIDlet, or rather, at the moment the MIDlet is connecting with the backend. But that's not the issue today. The backend has a daemon running (a thread in the web tier) started by a servlet that generates a data-structure and expands it over time. Because I wanted this to be started at server startup, the thread was started in the servlet's overridden init() method. Because I wasn't sure whether or not my code was working, I set a breakpoint in the init() and started debugging. Guess what, nothing happened, the breakpoint was never hit! Adding some System.outs in the init() showed that it was called, NB's debugger was just never ready to stop on the breakpoint. It seems to be too slow, or the interaction between Sun AS and NB is not synched correctly.
So now I moved the code to the doGet and I kick off the thread in there. It all works nicely and my code works like a charm. And I can debug the code.
So what is going on? I tried several scenario's each time ensuring that I did a clean-build prior to my trial.
Scenario 1: Start my web app from NetBeans by hitting the debug button. Breakpoint in init() didn't pause the app.
Scenario 2: Start Sun AS in NetBeans in debug mode. Breakpoint in init() didn't pause the app.
Scenario 3: Start Sun AS in debug mode and start my web app from NetBeans by hitting the debug button. Breakpoint in init() didn't pause the app.
In all three scenario's the breakpoint in doGet() worked perfectly. Really weird, but at least after a lot of trial and restart of NB it worked, some way.
Iwan
Tuesday, December 19, 2006
Wednesday, December 13, 2006
J2ME connectivity with a server app... Ooops I did it again
Recently I was looking at connecting my MIDlet with a backend application running in Sun AS 9, of course developed in NetBeans as well and since I am not really sure whether or not WS are supported by the phones the MIDlet will run on, I generated, well I had NB generate the web connectivity. Really cool stuff.
Then I wanted it all to work, ie send data from the phone to the backend and have the data stored in a database, Java DB included by NB. To get some grips on the whole Java EE 5 thing, I had NB generate a CRUD frontend for the entity classes and I looked at the generated code. This is actually rather clean code and very comprehensive indeed. But from the NB generated servlet unusable. It took me some digging in the Java EE 5 tutorial to find out how to get it all up an running with PersistenceUnits, Resources, annotations and transactions, but I got it all running in the end. I added the annotation of the Persistence Unit to the generated servlet and changed the EndToEndSupport class (I'm not really sure that it is called exactly that way, but it was generated by NB during the generation of the backend connectivity). The change included providing the EntityManager obtained in the servlet to the actual code that is to do the persistency. This was about 2 minutes of work and I was thrilled to see it all working.
Now the "Ooops I did it again" comes into play. I changed the backend functionality a bit, or rather I moved some classes and added some features which wasn't a problem until I had NB generate the code again so I could use the new backend functionality from the MIDlet. All code I had changed to get the persistence working was gone. Fortunately I remembered what I had done, and it all was still in SVN, so not too much harm done.
And this is when I started wondering about where that checkbox is that asks me whether or not I want to use the JPA in the backend I am connecting to from my MIDlet and when checked it will generate all the code for actually persist data send across.... or maybe I am not looking in the right direction to read all about it. Anyway, the tutorial on mobility assumes a working webapp, the web tutorial assumes JSF to be used and it doesn't all come together in one tutorial... maybe I'll document my efforts more detailed, until then: Drop me an email if you get stuck on this.
E-One
Then I wanted it all to work, ie send data from the phone to the backend and have the data stored in a database, Java DB included by NB. To get some grips on the whole Java EE 5 thing, I had NB generate a CRUD frontend for the entity classes and I looked at the generated code. This is actually rather clean code and very comprehensive indeed. But from the NB generated servlet unusable. It took me some digging in the Java EE 5 tutorial to find out how to get it all up an running with PersistenceUnits, Resources, annotations and transactions, but I got it all running in the end. I added the annotation of the Persistence Unit to the generated servlet and changed the EndToEndSupport class (I'm not really sure that it is called exactly that way, but it was generated by NB during the generation of the backend connectivity). The change included providing the EntityManager obtained in the servlet to the actual code that is to do the persistency. This was about 2 minutes of work and I was thrilled to see it all working.
Now the "Ooops I did it again" comes into play. I changed the backend functionality a bit, or rather I moved some classes and added some features which wasn't a problem until I had NB generate the code again so I could use the new backend functionality from the MIDlet. All code I had changed to get the persistence working was gone. Fortunately I remembered what I had done, and it all was still in SVN, so not too much harm done.
And this is when I started wondering about where that checkbox is that asks me whether or not I want to use the JPA in the backend I am connecting to from my MIDlet and when checked it will generate all the code for actually persist data send across.... or maybe I am not looking in the right direction to read all about it. Anyway, the tutorial on mobility assumes a working webapp, the web tutorial assumes JSF to be used and it doesn't all come together in one tutorial... maybe I'll document my efforts more detailed, until then: Drop me an email if you get stuck on this.
E-One
Subscribe to:
Posts (Atom)