My TPT project finally has been released to version 1.1 Main changes are pdf document viewer which allow to stream and view very large pdf files in a manner of google book reader and without downloading any contents to the client computer. Also, it has been aligned with recently released Vaadin 6.3.
Browse and download from google code - http://code.google.com/p/tpt or from Vaadin Directory
Feb 14, 2010
Debugging on usb-connected Android phone on Linux
Since my nvidia-broken mybook exchange process got extended by some unclear reasons - maybe russian customs sends us a nice "hello" or local Deep Apple screwed up, but I did not yet got my working machine back and still sitting on rented terrible asus u6v laptop and Ubuntu.
By the way, I need to work regardless the status of my macbook, so I installed Android sdk on Ubuntu this weekend. While sdk installation and development process went nice, I stuck on running my app on a real, usb connected device - IDEA / NetBeans were hanging on a device selection dialog and "adb devices" commands says "no permissions".
The answer was simple, so Im posting it here, basically for my own records and if this would be useful for anyone else. The problems is in permissions. To fix this, just become root and restart your adb server by invoking the following commands (as root !) from Android sdk:
adb kill-server
adb start-server
Now try to reinvoke your IDE Android devices list or just call "adb devices" - you should see your phone now ok.
In some cases, you'll need to add permissions to asb devices manager, in such case plase consult the source topic I found information in - it contains some more details on this question: http://androidboss.com/using-android-debug-bridge-adb-in-linux/
Tags:
android,
java,
linux,
permissions,
usb
Jan 10, 2010
Lack of JEE runtime configurability thoughts
What I still do not like in complete JEE stack is a lack of runtime configurability. Assume you created an EAR application and want to distribute it to your customers. Each customer has its own database. Yes, you do hardcode the JNDI name to your persistence units and may require customer to pre-create such JDBC resource in its appserver before deploying your EAR. But you CAN'T let your customer simply deploy your EAR, go to web app from it and let to choose the database, login and password in your own configuration web UI. And that's what most customers want, as they do not like (even tech guys) to dig with JDBC pools, etc.
At the moment I realized that the only solution is to merge the app server with your enterprise application installer as well. This way you could silently install the app server, run the series of DB (and other resources) configuration screens and finally tweak the app server xml files.
But what if your enterprise application uses JAP and needs to change, say, database at runtime ? The workaround paragraph above will not help in this case. And there could be a lot of similar use-cases collected.
Well, something needs to be enhanced in this area, I think...
Tags:
deployment,
ejb,
enterprise,
java,
jee,
thoughts
Subscribe to:
Posts (Atom)