Group items tagged

"AtomServer is a generic data store implemented as a RESTful web service. It is designed as a GData-style Atom Store. It is based on the following concepts and protocols; REST. REST is a design pattern. It's not a technology like SOAP or HTTP. REST is a proven design pattern for building loosely-coupled, highly-scalable applications. There are important benefits to sticking to the REST design pattern; Simple. REST is incredibly simple to define. There are just a handful of principles and well defined semantics associated with it. Scalable. REST leads to a very scalable solution by promoting a stateless protocol and allowing state to be distributed across the web. Layered. REST allows any number of intermediaries, such as proxies, gateways, and firewalls. Ultimately REST is just a web site, albeit one that adheres to a design pattern, so one can easily layer aspects such as Security, Compression, etc. on an as needed basis. Atom. Fundamentally, Atom is an XML vocabulary for describing lists of timestamped entries. These entries can be anything, although because Atom was originally conceived to replace RSS, Atom lists are Feeds, and the items in the lists are Entries. Atom is a RESTful protocol. AtomServer stands on the shoulders of giants. It is built on top of several open source projects - most notably, Apache Abdera (a Java-based Atom Publishing framework) and Spring. AtomServer is an Atom Store. Thus, it requires a relational database to run. AtomServer currently supports; PostgresSQL, SQLServer, and HSQLDB. Using HSQLDB, AtomServer requires zero configuration and can run out-of-the-box. While this configuration is suitable for many applications, those that see significant load will likely require a database with better transactional semantics, such as PostgreSQL. AtomServer is easy to use. It deploys as a simple WAR file into any Servlet container. Or alternately, can be used out-of-the-box as a standalone server, running with

Read this post to know how to install and configure Wowza media server. And let's see basic steps to create an application on Wowza server.

"The PrettyFaces team is currently working on an alternative way to configure URL mappings. PrettyFaces will soon allow to use annotations instead of the classic XML configuration file to declare mappings. We encourage everyone interested in PrettyFaces to take a look at this new way of configuration and share his or her opinion with us."

"This page describes how you can get an extended WADL from your REST app. It aligns mostly with the extended-wadl-webapp sample and uses these features: Add additional doc tags to the WADL Create JAXB beans from xsd - you might also create the schema from your beans Add the grammars element that includes the xsd file from which JAXB beans were generated to the WADL Add javadoc from your resource classes to the WADL, using most of the supported javadoc tags For getting the extended WADL as described above these things have to be done: Configure the maven-jaxb-plugin to create JAXB beans from xsd - this is described here just to describe what's done in the sample. Add the application-doc.xml and application-grammars.xml to the build classpath Configure the maven-javadoc-plugin with the ResourceDoclet provided by the wadl-resourcedoc-doclet artifact to create the resource-doc.xml. Create a subclass of WadlGeneratorConfig that defines/configures the WadlGenerators to use Specify your custom WadlGeneratorConfig in the web.xml as the WadlGeneratorConfig"

Eclipse Integration for Karaf is the integration of the Apache Karaf application platform and the Eclipse IDE. Notable features include: An Eclipse Run/Debug launcher configuration that configures Karaf to run inside the workbench transparently to the developer Automatic deployment of workspace plugin projects to running Karaf instances without copying files A Target Platform Definition that allows developers to target only the bundles found in Karaf distributions A Target Platform Provisioner that automatically constructs a target platform from any Karaf distribution on the user's local disk JMX instrumentation of the Running/Debugging Karaf instance. Eclipse views that display the Bundle and Service status of Karaf instances Experimental features: Web Tools Platform integration including: Karaf server runtime with associated classpath maintenance Karaf runtime locator that scans local disks for compatible Karaf distributions Install from the EIK Update Site

"You express your design intent in a textual DSL, from which Sculptor generates high quality Java code and configuration."

"Sculptor is an open source productivity tool. You express your design intent in a textual DSL, from which Sculptor generates high quality Java code and configuration."

migrate4j is a database migration tool. Suppose you determine that you need a new database table for your project. If you develop alone, you could write an SQL script that adds a table and manually apply this to your development system. But if you work with other developers, or need to keep a test system in synch with your development system, this become tedious and error prone. Migration tools make it possible to add your new table (or make any other schema changes) in an automated fashion, ensuring all your systems are always in synch. Migration tools also make it possible to quickly and easily roll back previous changes. Unlike typing commands into an interactive SQL window or storing SQL scripts, migration tools keep a detailed history of how your database schema evolved (just in case you need to go back to a previous version). Finally, migration tools minimize or eliminate the problem of having to use vendor specific syntax - you may never switch database products, but if you do, using a migration tool will make your life much easier. The initial intent of migrate4j was to make a Java version of Ruby's db:migrate. If you've used db:migrate, you probably fell in love with it's simple syntax, easy configuration and ability to roll changes up and back effortlessly. The intent (and the challenge) of migrate4j is to bring the power and simplicity of db:migrate to Java programmers, using familiar type safety and syntax. Along the way, we're adding additional functionality that makes migrate4j more than just another Ruby tool rewritten for Java - it is a Java project intended to make other Java projects even better.

Aspect-oriented computing is continuing to increase in popularity. The modularity inherent in OSGi and Eclipse offers unique opportunities for managing and applying aspects by supplying them in bundles and directing their application to particular sets of bundles. This incubator work area is dedicated to delivering an integration of aspects and OSGi. The goal is to allow developers to use the Equinox together with AspectJ by combining the benefits of both worlds. Using a load-time weaving extension you are able to add AspectJ aspects to your bundle-based system just by putting them into general OSGi bundles. It does not matter if the pointcuts you defined inside the aspects contain join points that are defined by classes within the same bundle or any other bundle in your installation. The load-time weaving extension will take care that your aspects are woven with the appropriate classes at load-time. To illustrate this lets assume the following situation: You would like to write an aspect that traces something within the JDT plug-ins of Eclipse. Without some kind of load-time aspect weaving you would somehow need to recompile those JDT plug-ins using AJDT (for example) together with your aspect. By using the load-time aspect weaving extension all you need is to implement your aspect and add that bundle to your system. The load-time aspect weaving extension takes care of weaving your aspect with the JDT code as it is loaded. And it doesn't matter if a new JDT is installed by the user later on. The next time your application is started the load-time aspect weaving will take care of weaving your aspect into these bundles as well, if necessary. With this technology is becomes possible to modularize crosscutting concerns across different plug-ins while keeping the idea of separate compilation for bundles. Goals Provide Runtime Modularity and Versioning for Crosscutting Concerns: Aspects are used to implement crosscutting concerns. However such concerns usually compr

Sample of using Hibernate Annotations by reducing XML configuration files thus making it simpler to define required metadata directly into our Java code. When using annotations, we no longer need the additional mapping file (*.hbm.xml). The metadata for the ORM is specified in the individual classes.

An Example explaining on how @Required annotation from Spring Framework works. Provides sample on how to use @Required and expected exception if beans are not properly configured like BeanInitializationException or Property is required for bean.

Janino is a super-small, super-fast Java™ compiler. Not only can it compile a set of source files to a set of class files like the JAVAC tool, but also can it compile a Java™ expression, block, class body or source file in memory, load the bytecode and execute it directly in the same JVM. Janino is not intended to be a development tool, but an embedded compiler for run-time compilation purposes, e.g. expression evaluators or "server pages" engines like JSP. JANINO is integrated with Apache Commons JCI ("Java Compiler Interface") and JBoss Rules / Drools. JANINO can also be used for static code analysis or code manipulation. JANINO can be configured to use the javax.tools.JavaCompiler API (available since JDK 1.6), which removes the Java 5-related limitations.

Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. CXF includes a broad feature set, but it is primarily focused on the following areas: Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the WS-I Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, WS-Security, WS-SecurityPolicy, WS-SecureConverstation, and WS-Trust (partial). Frontends: CXF supports a variety of "frontend" programming models. CXF implements the JAX-WS APIs (TCK compliant). CXF JAX-WS support includes some extensions to the standard that make it significantly easier to use, compared to the reference implementation: It will automatically generate code for request and response bean classes, and does not require a WSDL for simple cases. It also includes a "simple frontend" which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java. For REST, CXF also supports a JAX-RS (TCK compliant) frontend. Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.x XML support to make configuration a snap, and much more. Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport. To get started using CXF, check out the downloads, the user's guide, or the mailing lists to get more information!

Shrinkwrap provides a simple mechanism to assemble archives like JARs, WARs, and EARs with a friendly, fluent API. JavaArchive archive = ShrinkWrap.create(JavaArchive.class,"archive.jar")    .addClasses(MyClass.class,MyOtherClass.class)    .addResource("mystuff.properties"); From there you may deploy directly into any supported integration container like JBoss EmbeddedAS, GlassFish v3 Embedded, Jetty, or OpenEJB.  Or perhaps you'd like to export the archive to a file or exploded directory structure.  Maybe you'd prefer to serialize it over the network to a remote host.  The possibilities are limitless. To boot, ShrinkWrap is the supported deployment mechanism of the Arquillian project, and together we render the testing of true enterprise components amiable as a puppy.  Where Java EE brought a POJO programming model to application development, we've brought it to testing.  You handle your business logic; we'll do the rest. To foster community participation, the majority of documentation and examples are available through our Wiki. Releases are available either via our Downloads section, or through the JBoss Maven Repository, which we recommend is configured in ${userHomeDir}/.m2/settings.xml:

This project will mainly contain utility stuff for diverse purpose. Initially it will primarily comprise of Spring Utilities which will perform the following purposes: Load a single resource properties file from pre-configured locations with priority based override. Application context registrar to make the context available to other interested components. Use Cacheable Jersey Client Use a generic RESTful WS Client OpenSearchDescriptor JAX-RS Provider based on XOM based DOM I/O Useful utilities for Atom Syndication Feed, such as pagination over entities, retrieval of resource to certain depth, etc.

"The NetKernel Resource Oriented Computing (ROC) platform separates architecture from code. With ROC you can compose your architectural design independently from implementation code. By keeping the details of code separate from high-level information architecture you gain: freedom of choice in implementation language rapid click-fit compositional development long-term evolvable solutions Threading and scheduling is managed by the microkernel so your code execution is efficiently optimised with linear scaling on multi-core without the need to learn new languages. Something brand-new also comes from separating architecture and code. NetKernel provides system-wide caching of every area of your system. For free. No configuration. NetKernel learns what information is reusable and reuses it. This makes NetKernel systems fast. Very fast."

Sapphire - develop UI without wiring individual widgets Little has changed in the way Java desktop UI is written since the original Java release. Technologies have changed (AWT, Swing, SWT, etc.), but fundamentals remain the same. The developer must choose which widgets to use, how to lay those widgets out, how to store the data being edited and how to synchronize the model with the UI. Even the best developers fall into traps of having UI components talk directly to other UI components rather than through the model. Inordinate amount of time is spent debugging layout and data-binding issues. Sapphire aims to raise UI writing to a higher level of abstraction. The core premise is that the basic building block of UI should not be a widget (text box, label, button, etc.), but rather a property editor. Unlike a widget, a property editor analyzes metadata associated with a given property, renders the appropriate widgets to edit that property and wires up data binding. Data is synchronized, validation is passed from the model to the UI, content assistance is made available, etc. This fundamentally changes the way developers interact with a UI framework. Instead of writing UI by telling the system how to do something, the developer tells the system what they intend to accomplish. When using Sapphire, the developer says "I want to edit LastName property of the person object". When using widget toolkits like SWT, the developer says "create label, create text box, lay them out like so, configure their settings, setup data binding and so on". By the time the developer is done, it is hard to see the original goal in the code that's produced. This results in UI that is inconsistent, brittle and difficult to maintain.

"Out of the box Jersey generates basic WADL at runtime that you can obtain from your REST app via GET http://path.to.your/restapp/application.wadl. Additionally you can configure Jersey to create an extended WADL including e.g. additional doc elements or javadoc read from your resource classes: There's a custom doclet that writes your javadoc to a file so that it can be used to extend the WADL. Additionally there's the maven-wadl-plugin that allows you to create the WADL without your running REST app."

When creating a REST api with Java EE 6 and JAX-RS there comes the time when you start thinking about security. In our case we were trying to set up HTTP Basic Auth for the REST api to identify users and keep them from deleting other peoples stuff. It took me a while to understand the different aspects of configuring HTTP Basic Auth when using GlassFish: