Unable to read TLD “META-INF/c.tld” from JAR file

I was trying to run spring mvc with maven and got this error - “Unable to read TLD “META-INF/c.tld” from JAR file…”.

After a research I have found the fix.

So JasperServer contains in WEB-INF/lib some servlet libraries?!?! Could be possible it’s not a war made by me so somebody could have made some mistake. Listing the files in WEB-INF/lib i found the entire world of web libraries, included jsp-api. Yes this is the problem!

Tomcat excludes genonimo.jar because it contains Servlet api’s but loads jsp-api located in WEB-INF/lib because no checkis made. No jsp can be compiled because jasper (not jasper reports) compiles from a classloader and jsp-api are located in a different classloader.

Removig jsp-api everything works fine again.

My first iPhone Application - I call it oTweet :-)

Seriously this time, the new language on App Engine: Java™

Today, Google has announce the availability of a new programming language for Google App Engine. Please welcome the Java runtime!

Realized that the chance to bring this kind of simplicity to Java developers was too good of an opportunity to pass up. When App Engine launched publicly, that Java language support was both the first and the most popular request filed in the Issue Tracker. I am thrilled to see that this enthusiasm extended beyond the Java language to all of the various programming languages that have been implemented on top of the Java virtual machine -- not to mention all of the popular web frameworks and libraries.

Also knew that Java developers are choosy:

• They live by their powerful tools (Eclipse, Intellij, NetBeans, Ant, etc.).
• They try to avoid lock-in and strive for re-use. Standards-based development (defacto or otherwise) is key.
• They harness sophisticated libraries to perform language feats which are nearly magical (GWT, Guice, CGLIB, AspectJ, etc...).
• They even use alternate languages on the JVM, like Groovy, Scala, and JRuby.

Google wants to give developers something that they could be ecstatic about, but google knew that it would have to marry the simplicity of Google App Engine with the power and flexibility of the Java platform. Google also wanted to leverage the App Engine infrastructure -- and by extension Google's infrastructure -- as much as possible, without giving up compatibility with existing Java standards and tools.

And so that's what Google did. App Engine now supports the standards that make Java tooling great. (Google is also working on the tooling too, with Google Plugin for Eclipse). It provides the current App Engine API's and wraps them with standards where relevant, like the Java Servlet API, JDO and JPA, javax.cache, and javax.mail. It also provides a secure sandbox that's powerful enough to run your code safely on Google's servers, while being flexible enough for you to break abstractions at will.

There is a vast amount of Java code out there, much of it written without consideration of sandboxing, and we can't test it all. 

The google team has also been working on many other improvements to App Engine, which we're really excited to launch to you as well:

• Access to firewalled data: grant policy-controlled access to your data behind the firewall.
• Cron support: schedule tasks like report generation or DB clean-up at an interval of your choosing.
• Database import: move GBs of data easily into your App Engine app. Matching export capabilities are coming soon, hopefully within a month.

Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.

Some of this content has extracted from http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html

A short introduction to SIP (Session Initiation Protocol)

SIP stands for Session Initiation Protocol and is an application level signaling protocol. It is designed to create, modify and terminate sessions between one or more participants. Typical SIP sessions can be telephone calls, multimedia distribution and conference participations.

The base SIP specification is defined by IETF rfc3261.

SIP container/Sip Servlet API (SSA).
The Sip Servlet API (SSA) is an extension of the HTTP Servlet Specification. Some important aspects of the SSA :

• For developing SIP enabled applications. Supporting UAC, UAS, Proxy and B2BUA.
• Aligned with HTTP Servlet API for development of converged applications (originating HTTP, sending SIP request, bridging HTTP and SIP Session) spawning multiple protocols and media types.
• Separating the developer and the deployer roles by deployment descriptors 
• Several applications may execute on the same incoming or outgoing messages, which allows application composition. Every application processes the message independently from one another.
• Application data can be stored in sessions and application context.

There are two versions of SSA, 1.0 and 1.1:

SSA 1.0 is defined in JSR 116, which have reached final status (released).
SSA 1.1 is defined in JSR 289, which is still on early stage (under development).


The SIP container is under development, towards SSA 1.1 (JSR 289). SSA 1.0 Test Compatibility Kit (TCK) tests towards the SIP container passes with the exception of two failures :

• test_context. This test case, among other, checks that the information in context is Servlet related. But some extra information is stored there by the application server which causes this to fail. This is not a violation of the SSA 1.0 and can be counted as not critical.
• test_proxy_gen2xx. This tests the ability of a proxy to generate its own 2XX responses, to act as an UAS. This functionality is not implemented in current version, but there is ongoing effort to add this.

The Sip Stack

The Sip Servlet implementation requires a Sip stack to control the signaling operations. The Sip Stack is provided by Ericsson Inc, and is currently used for Ericsson IMS products. The Sip Container and Stack were developed at Ericsson R&D sites in Stockholm, Sweden.

Some characteristics of the Sip Stack implementation :

• Lazy Parsing
• Low footprint
• Efficient

Sailfin: Open Source SIP Servlets Technology for GlassFish.
The Sailfin project, adds SIP Servlets technology extension to Glassfish, providing high availability, clustering features and integrating with the existing services. Sailfin is a joint effort, working towards to achieve JSR-289 compatibility and will be the source of all SIP related development for Glassfish.

How Did Cloud Computing Start?

At a basic level, cloud computing is simply a means of delivering IT resources as services. Almost all IT resources can be delivered as a cloud service: applications, compute power, storage capacity, networking, programming tools, even communications services and collaboration tools.

Cloud computing began as large-scale Internet service providers such as Google, Amazon, and others built out their infrastructure. Architecture emerged: massively scaled, horizontally distributed system resources, abstracted as virtual IT services and managed as continuously configured, pooled resources. This architectural model was immortalized by George Gilder in his October 2006 Wired magazine article titled “The Information Factories.” The server farms Gilder wrote about were architecturally similar to grid computing, but where grids are used for loosely coupled, technical computing applications, this new cloud model was being applied to Internet services.

Both clouds and grids are built to scale horizontally very efficiently. Both are built to withstand failures of individual elements or nodes. Both are charged on a per-use basis. But while grids typically process batch jobs, with a defined start and end point, cloud services can be continuous. What’s more, clouds expand the types of resources available — file storage, databases, and Web services — and extend the applicability to Web and enterprise applications.

At the same time, the concept of utility computing became a focus of IT design and operations. As Nick Carr observed in his book The Big Switch, computing services infrastructure was beginning to parallel the development of electricity as a utility. Wouldn’t it be great if you could purchase compute resources, on demand, only paying for what you need, when you need it?
For end users, cloud computing means there are no hardware acquisition costs, no software licenses or upgrades to manage, no new employees or consultants to hire, no facilities to lease, no capital costs of any kind — and no hidden costs. Just a metered, per-use rate or a fixed subscription fee. Use only what you want, pay only for what you use.

Cloud computing actually takes the utility model to the next level. It’s a new and evolved form of utility computing in which many different types of resources (hardware, software, storage, communications, and so on) can be combined and recombined on the fly into the specific capabilities or services customers require. From CPU cycles for HPC projects to storage capacity for enterprise-grade backups to complete IDEs for software development, cloud computing can deliver virtually any IT capability, in real time. Under the circumstances it is easy to see that a broad range of organizations and individuals would like to purchase “computing” as a service, and those firms already building hyperscale distributed data centers would inevitably choose to begin offering this infrastructure as a service.

Sun Tech Days

Zend Announces Beta of Zend Server, Includes Java Capability

Zend today is announcing that it has opened a public beta of their new product called Zend Server. It's completely free for anyone to go download and try it out. Zend is really hoping for some good feedback to make this product the best it can be.

The interesting thing is that even the free community edition now includes their Java capability, previously only available to high-end customers. They feel this will enable a lot more in the Java community to experiment with PHP and gain some of the benefits of dynamic scripting languages like PHP, in conjunction with running Java code they may have already built and have running in production.

Zend Server is designed to be an all-in-one installer to get setup quickly with Apache, PHP, Zend Framework, and a PHP optimizer (opcode cache, very much a necessity with dynamic languages like PHP). It also comes with an admin UI to configure PHP easily. It uses native installers for various operating systems, and is available for Windows, Mac OS X (the CE edition), and Linux (.deb, .rpm or tarball).

There are two versions being released. The full Zend Server (which after Beta will be a commercial product, price to be announced), and Zend Server CE, which is a version completely free to use however you wish. The full Zend Server comes with the following additional features:

* Page Caching (based on URLs, no code changes necessary)
* Monitoring (email alerts on slow DB queries, broken code executions, etc.)
* Support & Hot Fixes (so PHP is always up-to-date)

If you are interested in trying out Zend Server for yourself, check out some of the following links:

* Learn more about Zend Server. http://www.zend.com/en/products/server/
* Download Zend Server (either edition) to try out in beta. http://www.zend.com/en/products/server/downloads-all