radioAe6rt

Good news for JXTA developers: a pending addition to the platform API, NetworkConfigurator.java, will allow you to quickly and easily configure the platform for simple (read most) peer configurations. Developers can still use JXTA’s extension:config for more complex peer configurations, but NetworkConfigurator can serve simple configuration needs nicely.

At its inception in 2001, JXTA configuration consisted of an AWT interactive configuration suite. Late 2004 saw refinements in the AWT UI, as well as the introduction of the much needed extension:config. NetworkConfigurator takes the configuration process one step further and allows simple programmatic platform configuration.

See NetworkConfigurator.main() for typical usage.

[tags]jxta,p2p[/tags]

Mohamed has some interesting numbers on JXTASocket performance relative to Java Sockets. I’m guessing that the effect of essentially fixed JXTA framing goes down as the buffersize goes up.

[tags]jxta,p2p[/tags]

O’Reilly Emerging Telephony publishes my whitepaper on how PhoneGnome and Iotum engage in platform-to-platform signalling to the benefit of their mutual customers.

Voice 2.0 at its finest.

[tags]phonegnome,iotum,voice 2.0, web services, voip[/tags]

Your installation of the Java virtual machine contains a list of certificate authorities (CA) - like your browser has a list of CAs - that the JVM trusts are authentic.

Here is how to generate the list of CAs known to your Java VM:

$ keytool -v -list -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit

In trustedcerts.txt we’ve captured the first few certs.

[tags]java security,keytool,java certificates,cacerts[/tags]

Some time back I encountered a bug in a JXTA application that forced me to put the application under the control of NetBeans (NB) and come to terms with source code, line-by-line tracing therein. JXTA developers and NetBeans 5.0 users in general may be interested in how I configured NB to trace into foreign code. Foreign relative to my application code, and in this case foreign being the JXTA platform source on which the application depends.

How I achieved this NB tracing effect may be “by side-effect”, because some of the procedure I will outline I consider rather odd. I’ll let NB experts be the judge of whether I achieved my goal through side-effect, and then hopefully they can point out a better way. Or, how I achieved it may be the NB “right” way. I really don’t know. Much as I like NB, the docs fall short in this area.

Along the way, we will encounter two curious manual NB config steps that must be performed. I’ll point them out with VexingManualStepAlert. Experts, feel free to point out a better, smarter way.

First, make a project directory

$ mkdir -p TraceNetbeans/src/org/carpediem/trace
$ cd TraceNetbeans

Magically create the build.xml file and the JXTA sample app

 
$ ls build.xml
build.xml  

 
$ find src
src
src/org
src/org/carpediem
src/org/carpediem/trace
src/org/carpediem/trace/NetworkConfigurator.java
src/org/carpediem/trace/TraceNetbeans.java

At this point we have two files we care about, with links to reference examples

• The Ant build.xml file
• The JXTA sample app TraceNetbeans.java

The NetworkConfigurator source is from a pending addition to the JXTA platform API, designed to ease configuration for simple peer situations. See Issue 1531.

Next, check out and build the JXTA platform

$ pwd   # sanity check on where we are
/home/petrovic/projects/TraceNetbeans
$ cvs -d:pserver:guest@cvs.jxta.org:/cvs co platform
$ (cd platform/binding/java; ant dist)

Next, start NB and create a new free-form Ant-based project on this directory. Add src, platform/binding/java/api/src, and platform/binding/java/impl/src to the “Java Sources” dialog. If you forget any one of these, go back and add them in “Project Properties/Java Sources”.

Next, go to “Project Properties/Java Sources Classpath” and UNCHECK the checkbox next to “Separate Classpath For Each Source Package Folder”.

At this point, your NB session should look like this with respect to sources and source classpaths

• Project Properties/Java Sources
• Project Properties/Java Sources Classpath

Note that I changed the labels on the source trees to beautify them.

Onto the build.xml file and the required debug target:

VexingManualStepAlert:    Note that our build.xml contains a target representing a debug-nb target that NB will require shortly. You must add a pointer to this target manually in the nbproject/project.xml file so NB does not bug you later about not having a debug target. See the the NB project.xml project file for where to add the element. Do that now. It looks like this

 
<action name="debug">
   <target>debug-nb</target>
</action>

This manual editing of project.xml is vexing because my reading of the NB docs suggest that this target already has a placeholder in the “Project Properties/Build and Run” config UI for the Project, as Build and Run have their placeholder targets. I never found that field, nor do I consider the custom fields to be candidates. I probably misread the docs. In any event, add the debug action element so you can use the target provided in the build.xml file.

Finally, we must tell NB which source trees to use during debugging. I can’t find a better way to do this so…

VexingManualStepAlert:    In TraceNetbeans.java set a breakpoint on the line

  PeerGroup netpg = PeerGroupFactory.newNetPeerGroup();  

Start the debugger by pressing F5. When the debugger stops at that line, do Shift-Alt-8, or “Window/Debugging/Sources”. At this point you should see a small window open at the bottom of the NB display that is labelled “Sources”. Check each of the three sources trees of interest: src, api/src, and impl/src.

Here is what NB looks like at this step.

Note the breakpoint and the checked source trees in the Sources window. This is vexing because the sources trees to-trace are not visible until you start the debugger. Setting the breakpoint gives you a chance to select which source trees to trace before you execute to the line you want to trace into. Doubly vexing, because if above you do not uncheck the “Project Properties/Java Sources Classpath” checkbox, the platform sources do not appear in this “Sources” window list - only the application source appears.

For NetBeans Technical Documentation Specialists: Unchecking that “Separate Classpath For Each Source Package Folder” has always bothered me. It’s not that I can’t read the words and parse what it says. It’s that I can’t figure out what problem this checkbox was intended to solve. What am I doing and what am I trying to achieve if I need/want to check/uncheck the checkbox? It’s like the map of the shopping center that says “You are here”. I know I am here, but why am I here?

Finally, press F7 to trace into the platform code that starts the platform. In a few seconds you should see the code for PeerGroupFactory come up in your editor. For our simple example, this constitutes success, as PeerGroupFactory.java is the sought-after application-foreign code, and we’ve traced into it under NB platform control.

What I believe is significant about this method is that it does not require us to take advantage of the otherwise happy fact that the JXTA platform code has already been cast into a NB free-form project itself. See platform/binding/java/nbproject.

When all is said, and done, I don’t know if this is a good way to trace into foreign code under NB, but it seems to work. I’m mildly bugged by the unchecking of the classpath checkbox, but for now I can live with it.

If anyone has smart ways to avoid the VexingManualStepAlerts, I would love to hear of them.

Update, 5/29/06 Some fun JMX instrumentation has been added. While unrelated to platform tracing, it was fun to experimenet with it in this simple example. See the repository for details.

[tags]netbeans,netbeans debugging,jxta[/tags]

Surj continues to make progress with an open cell phone based on Linux. One more step toward throwing off one more set of reins.

[tags]surj patel,opencellphone.org,open source wireless[/tags]

A few people in the last few days on the Tomcat Users List

have essentially asked: How do I read a file from disk from within my web application, and furthermore, how do I declaratively configure the name of that file so as to keep its path out of my code?

It’s a common question, and one good solution applies to any Java application, not just a web application running in a container.

Here’s a frequently used scheme: bundle the file of interest in your application’s war file, and from within your application, read its contents as a resource.

Assume the application’s context is named myapp, the file of interest is thisfile.dat, and that you can arrange through the jar-ing process/task for the file to be placed in your application’s WEB-INF/classes directory. When the application is unbundled by Tomcat, you should see the file in a directory listing

$ cd CATALINA_HOME
$ ls webapps/myapp/WEB-INF/classes/thisfile.dat
webapps/myapp/WEB-INF/classes/thisfile.dat

And while this is clearly Unix-like syntax, the same ideas apply to Windows.

What have we done so far? Strategically place the file along the application’s classpath. This is essential to the scheme: the file must be along the application’s classpath - and nowhere else. This is probably worth a close read

Class Loader HOW-TO

Futhermore, to declaratively configure your application, you’d like to put this file path in your application configuration, which keeps it hardcoded out of your code. In other words, in the application’s web.xml file.

So among other application configuration, you put this in your web.xml

 
<servlet>
   <init-param>
      <param-name>thefile</param-name>
      <param-value>/thisfile.dat</param-value>
   </init-param>
</servlet> 

Finally, somewhere in your servlet, you set about retrieving the file contents as follows:

 
String thefile = this.getInitParameter("thefile");
InputStream is = this.getClass().getResourceAsStream(thefile); 

That’s all there is to it. Of course, all of this assumes you have a method of using an InputStream to parse or process the file, but that is generally a good assumption.

Update

Tim Lucia points to this good article on the same topic. There are some useful points therein regarding other forms of loading resources that are worth knowing.

[tags]tomcat,java resource[/tags]

A single war file download and a copy into Tomcat webapps/ and I have a Jabber server running: JiveSoftware’s WildFire server.

As if that were not impressive enough, on top of it all, the JiveSoftware Smack API is as clean an XMPP client-side programming experience as you can come by.

I don’t know where JiveSoftware is or what they put in their water, but someone there is paying attention to the thousand little details that sets righteous apart from good. Craftsmanship.

As more is better, I give these products my signature “Three Thumbs Up!” approval rating.

Awesome work, guys.

[tags]jivesoftware,jabber,xmpp[/tags]

Thanks to Jason Brittain for the BadInputFilterValve in his coauthored Tomcat book.

Here is a modified version that runs under Tomcat 5.5.12 (and hopefully 5.5.17, which is where I’m headed) without the need for Jakarta Regexp.

To activate copy the class to $CATALINA_HOME/server/classes and put this context.xml in your war’s META-INF directory:

 
<Context>
   <Valve className="org.carpediem.crm.BadInputFilterValve" deny="\\x00,\\x04,\\x08,\\x0a,\\x0d"/>
</Context>
  

While I have not tested it extensively, my version appears to do no harm as an intermediary along the call chain pipeline - not much of a guarantee, I know, but it’s a start.

catalina.jar, catalina-optional.jar, servlet-api.jar, commons-logging-api.jar all need to be on your compile classpath.

[tags]tomcat,valves[/tags]

Every year or so I get an idea for a cool media app, either audio- or video-based. It’s that time of year.

Being a crossplatform guy, Java Media Framework comes to mind. It’s in the Desktop Group at Sun, getting a much needed rework. Unlike some others, I see the JMF glass as half full: a great set of APIs for doing Java media on the desktop, but whose implementation, at least the one we’ve lived with thus far, suffers from a lack of full commitment.

In the meantime I noticed Flumotion did a Java applet to render streaming Theora. All good.

On that royalty free Theora note, what do we need to starting writing applications? Theora itself, a JNI implementation of Video for Linux, a DirectShow filter for Windows, and whatever the equivalent for the Mac is called. All three native capture schemes exist in running code (see UCL vic for most, if not all three). And we need this functionality in one binary executable so we can do p2p video streaming, where sometimes the peer is a server, sometime a client (a servent).

What I don’t know is whether traditional or conventional Theora streaming is constrained to or more naturally expressed over TCP, such that NAT traversal becomes an issue on the consumer side of a p2p interaction (port-forwarding is not an option). You can get around this with UDP based packet flows using STUN and ICE (although watching what two peers have to go through to get that done’ll make your head explode).

And, oh, yeah: we may need a solid Java RTP stack. Also in JMF.

Cross platform Java media is within reach, and has been for some time. It has so much to recommend it, yet has some ways to go before we can avail ourselves of it.

In the meantime, if you care about JMF, drop Tony Wyant at Sun a note. And Jonathan Schwartz. Let these guys know that cross platform media matters, that it adds value to Java, and how they can help.

[tags]theora,ogg,jmf,java media framework,sun[/tags]