Simple is a high performance XML serialization and configuration framework for Java. Its goal is to provide an XML framework that enables rapid development of XML configuration and communication systems. This framework aids the development of XML systems with minimal effort and reduced errors. It offers full object serialization and deserialization, maintaining each reference encountered. In essence it is similar to C# XML serialization for the Java platform, but offers additional features for interception and manipulation.
SmartFrog is a powerful and flexible Java-based software framework for configuring, deploying and managing distributed software systems.
SmartFrog helps you to encapsulate and manage systems so they are easy to configure and reconfigure, and so that that they can be automatically installed, started and shut down. It provides orchestration capabilities so that subsystems can be started (and stopped) in the right order. It also helps you to detect and recover from failures.
Such systems typically have multiple software components running across a network of computing resources, where the components must work together to deliver the functionality of the system as a whole. It's critical that the right components are running in the right places, that the components are individually and collectively correctly configured, and that they are correctly combined to create the complete system. This profile fits many of the services and applications that run on today's computing infrastructures.
SmartFrog consists of:
A Language for defining configurations, providing powerful system modelling capabilities and an expressive notation for describing system configurations
A secure, distributed Runtime System for deploying software components and managing running software systems
A Library of SmartFrog Components that implement the SmartFrog component model and provide a wide range of services and functionality
jConfig is an extremely helpful utility, arming the developer with a simple API for the management of properties. Parts of the implementation are based on the idea that Properties, from Java's perspective, are a good thing, but can be better. jConfig employs the use of XML files for storing and retrieving of property information. The information can be stuffed into nice categories, which makes management quite a bit simpler. The ability to load from a URL is also a nice feature. It allows for a central repository where multiple instances of jConfig can read a single file. The nifty ability to
switch between XML and Properties files isn't fully exploited yet, but will be coming soon. That will mean that the developer would take their existing Properties files and export them to XML. That means less time to get up and get going with jConfig.
With jConfig we hope to have provided the developer with another powerful accessory for his or her's toolbox.
Java applications are typically deployed in multiple environments and platforms, each requiring some unique configuration. JFig gives developers a simple yet powerful tool to manage their applications’ configuration. It allows them to:
1. Store application configuration in one common repository of XML files
2. Access configuration data using one common, convenient interface
3. Easily define multiple configurations, dynamically modifying those variables that need to change in different situations
4. Eliminate the error prone practice of defining the same configuration variables in multiple locations
5. Ease the management, deployment, and control of configuration files
Griffon is a Grails like application framework for developing desktop applications in Groovy. Inspired by Grails, Griffon follows the Convention over Configuration paradigm, paired with an intuitive MVC architecture and a command line interface. Griffon also follows the spirit of the Swing Application Framework (JSR 296), it defines a simple yet powerful application life cycle and event publishing mechanism. Another interesting feature comes from the Groovy language itself: automatic property support and property binding (inspired by BeansBinding (JSR 295)), which makes creating observable beans and binding to their properties a snap! As if property binding was not enough Groovy's SwingBuilder also simplifies building multi-threaded applications, say goodbye to the ugly gray rectangle (the bane of Swing apps)!
Grails developers should feel right at home when trying out Griffon. Many of Grails' conventions and commands are shared with Griffon. Granted, Swing is not the same as HTML/GSP but Builders simplify the task of creating the UI.
Seasoned Java developers will also be able to pick up the pace quickly, as the framework relieves you of the burden of maintaining an application structure, allowing you to concentrate on getting the code right.
Simple-JNDI is intended to solve two problems. The first is that of finding a container independent way of opening a database connection, the second is to find a good way of specifying application configurations.
1. Unit tests or prototype code often need to emulate the environment within which the code is expected to run. A very common one is to get an object of type javax.sql.DataSource from JNDI so a java.sql.Connection to your database of choice may be opened.
2. Applications need configuration; a JNDI implementation makes a handy location for configuration values. Either as a globally available system, or via IoC through the use of some kind of JNDI configuration facade (see gj-config).
A Solution
A simple implementation of JNDI. It is entirely library based, so no server instances are started, and it sits upon Java .properties files, XML files or Windows-style .ini files, so it is easy to use and simple to understand. The files may be either on the file system or in the classpath.
Simple-JNDI depends on no external jars for its basic functionality, however to get certain optional features you will still need to download external jars. When describing these features, the manual will point out which jars are needed and where to get them.
SwitchPipe is a proof of concept "Web application server" or, more accurately, a Web application process manager and request proxy. Backend Web applications are loaded into their own processes, making SwitchPipe language agnostic. HTTP requests are proxied at the TCP level using information extracted from the headers to establish which backend application is being demanded.
Finally a useful article on eclipse.ini memory settings: "Many users seem to have problems with running out of memory when using Eclipse 3.2 in combination with additonal plugins such as those from JBoss Tools or even Eclipse WTP."
The goal of Simple is to bring the power of simplicity to the world of server side Java. The primary focus of the project is to provide a truly embeddable Java based HTTP engine capable of handling enormous loads. Simple provides a truly asynchronous service model, request completion is driven using an internal, transparent, monitoring system.
This allows Simple to vastly outperform most popular Java based servers in a multi-tier environment, as it requires only a very limited number of threads to handle very high quantities of concurrent clients. Simple has consistently out performed both commercial and open source Java Servlet engines and has a fully comprehensive API that is as usable for experienced Java developers as it is for beginners. Best of all, Simple is completely free, and is released under the terms of the GNU Lesser General Public License, LGPL, which ensures its availability for use by open source and proprietary developers alike.
It is currently common to build a number of releases from a single code base. For example, a development release, a QA release, a production release and perhaps customer-specific releases. However, these releases seem to differ mostly in the contents of their XML configuration files, and then only very little. Maintaining all these slightly different configuration files is a real nuisance.
XConf was created to simplify this maintenance. Its fundamental premise is that a single development-release (or production-release) configuration file is created and maintained, and is processed by XConf at either build or deployment time into an appropriate release by applying one or more XML-based scripts. Each script contains only the differences required to create the appropriate release, thus removing the need for the mass duplication of configuration files.
This is not really a new solution, since XSLT has been used in the past to do this quite successfully, but XPath can get a little arcane, and maintaining transformation scripts using XSLT can become really complex very quickly. XConf uses a very simple and compact method of specifying elements that need to be processed, and provides some very useful constructs to make transformations painless.
Changing Log4j logging levels dynamically
Simple problem and may seem oh-not-so-cool. Make the log4j level dynamically configurable. You should be a able to change from DEBUG to INFO or any of the others. All this in a running application server.