Posts tagged Flex

Future of Flex – Whitepaper from Adobe

Moderator’s note: Although this blog post is not specific to LiveCycle, the Adobe enterprise community will likely find it useful. We’re taking the liberty of sharing it (with due thanks to Holly Schinsky).


There have been a lot of questions about the viability and future of Flex recently, and Adobe has published an official whitepaper today detailing their support for Flex going forward. The paper also contains details regarding Flash runtime support, Flash Builder support and other Apache contributions including the Falcon compiler. I believe the paper is a must read and can be found HERE.


Original article at

Flex is Alive!

- Holly Schinsky

Flex folks, first of all, today there’s a new official statement out on the Adobe website about Adobe’s commitments to the Flash Platform including plans for Flex that you should be aware of. Secondly there’s a new post from the Product Management team out now summarizing the recent Flex Q&A. There’s been a lot of frustration in the community (which I understand and can personally relate to having been part of the community myself for a very long time) and I wish that the sequence of events (and frankly the communication) did not happen as it did, but it is what it is at this point and we need to carry on. I hope people can see this move of Flex to an Apache model with dedicated full-time engineering resources in San Francisco as the good news that it is!! Flex is alive and well and will continue to grow as the dust settles. Even now we can build amazing applications over many other technologies in half the amount of time with it in its current state. And the growth in Flex and AIR for mobile is allowing us to do some super cool and fun stuff which is about to just get better with the upcoming release of Flex 4.6 in a couple weeks!

I realize people’s trust is tarnished and people are scorned and angry, but please try to remove your emotions from the equation and look at this for what it is. Any good developer knows that technology is ever-changing and you have to ride the current wave. It’s evident that HTML 5/JavaScript is gaining ground and needs to be kept on our radar of things to be learning (whether we love it or not). It should also be considered as an option right now for certain applications where it makes more sense. As much as I am passionate about Flex myself, it can be overkill for many applications. And what better way to refine our skills in the HTML/JS arena by actually building some apps to gain the experience. As we all know though, there are still a ton of applications where it makes more sense to use Flex (enterprise and many mobile AIR apps) and fortunately we still have that option!

I know many of you are having to answer some tough questions from your clients and management about all of this, I hope today’s statements can help in that respect. If there was a way I could change how things happened myself or wave a magic do-over wand I would in a heartbeat :) . This has not been easy for any of us. I just hope we can now start channeling our frustrations into something more positive and productive and get back to having some fun!

I will continue to post any updates on the move to Apache as I find out. Start thinking about how you might be able to contribute ;) !


Original article at

ADEP Data Services for Java EE 4.6 released on Adobe Labs

- Tom Jordahl

As of Monday, October 4 2011 we have made a preview release of the next version of Data Service available up on Adobe Labs.

Some the sweet goodness in this release include:

  • Adobe Flash® Builder® 4.6, Flex 4.6, AIR and AIR Mobile Support — Build Flex and Flex Mobile applications that run in the browser, desktop or on mobile devices using the very latest cutting edge Adobe technology.
  • Managed Remoting — Leverage the power of Data Services Data Management features such as inter-client data sync, paging, entity associations and lazy-loading, with the ease of use of Remoting to create powerful data-centric Flex applications. Re-use your existing Java Beans and persistence using simple JPA-based annotations.
  • Native HTML5 Client SDK — Support for building high performance and very lightweight HTML5/JS applications with Remoting (RPC) and Messaging (push) networking capabilities leveraging HTML5 WebSockets and HTTP AMF channels.
  • Native Apple iOS Client SDK — Support for building very high performance Apple iOS applications with Remoting (RPC) and Messaging (push) networking capabilities leveraging RTMP and HTTP AMF for online, and Apple Push Notification Network (APN) for offline app support.
  • Native Android and Java Client SDKs —Support for building very high performance Google Android and Java applications with Remoting (RPC) and Messaging (push) networking capabilities leveraging RTMP and HTTP AMF channels.
  • .NET Adapters and IIS Plug-ins — Create apps that communicate with server-side .NET code using the new .NET Adapters for Remoting, Messaging, Data Management and MSMQ, or use the all-new native C#-based Microsoft IIS Remoting and Messaging plug-ins to directly access C# server-side code in an all-C# environment.
  • SAP Connector — Create RIA or Mobile applications that connect to server-side SAP ABAP server. Leveraging powerful Model-Driven Development technology, high performance SAP-backed applications can be created in just minutes and hours versus days, weeks or months.
  • Spring Support — Leverage the new built-in support for the Spring Framework Servlet and NIO-based channels, including with NIO channels hosted via Data Services Edge Server for DMZ deployments.

Check it out and leave us some feedback on the Labs forums.

Original article at

Quick Tip: CSS to customize the TabbedViewNavigator and ActionBar in Flex Mobile Applications

- Kevin Schmidt

If you are building Flex Mobile applications on of the first things you will end up wanting to change is the default look of the TabbedViewNavigator and ActionBar! This can be done through skinning but for simple changes it can be done much quicker with CSS. The CSS below illustrates how to do this.

@namespace s "library://";

s|TabbedViewNavigator #tabBar {

	chromeColor: #028bba;
	fontSize: 28;
	fontWeight: bold;

Save the file as a CSS file and include it in the Flex Mobile application using MXML

<fx:Style source="file_name.css" />

This is the CSS that I used for mapi and ends up looking like this:

All the CSS properties for both the TabbedViewNavigator and ActionBar can be found here:


A general article on Styling and Themes can be found here: Styles and themes

Original article at

Solutions and the Application Context

Saket Agarwal

Solutions over ADEP have introduced the concept of an application context (aka app context), which can be seen as a unique identifier, that various server side modules use to identify the execution context (from the current execution thread) and process requests in context of that solution. For instance, when persisting content/assets onto the CRX repository, the platform’s persistence module (official known as Platform Content) uses the current (invoking) app context to determine where to store the content/assets, and what configurations to use (which would typically be different for different solutions). See snapshot below, indicating the solution specific content areas.

Note that the storage location is /content/apps/cm for Correspondence Management, and /content/apps/icr for Integrated Content Review, which happen to be the app contexts for the two solutions.

Since it is essential for the server to identify the execution context, if you do not set or establish the application context before you make calls to the solution APIs, you will encounter a server error that says :  “Unable to fetch application context“. To set the app context, use one of the two methods:

App context in your Flex application

If you are invoking a solution API from a flex application, ensure that you set the app context using:

var appToken:AsyncToken ="/content/apps/cm"); // setting app context for the CM solution
appToken.addResponder(new mx.rpc.Responder(<your success handler>, <your fault handler>));

App context in your Java application

If you are invoking a solution API from a java based application, ensure that you set the app context using:

com.adobe.livecycle.content.appcontext.AppContextManager.setCurrentAppContext("/content/apps/cm"); // setting app context for the CM solution


The app context concept is also used (or rather leveraged) in other scenarios such as driving solution specific Building Block (BB) configurations. Since a Building Block is meant to be reusable across solutions, it exposes certain configurations that can be different for different solutions. Hence, the BB needs to behave differently depending upon the context in which it is being used or invoked. Below is an example where the Data Dictionary BB is used by two solutions – CM and ICR – and has configurations specific to each solution, lying within the solution’s specific app context - /apps/cm for CM and /apps/icr for ICR.

Original article at

LCDS Multi-Client Support: Native iOS, Android, HTML, Java, and Flex

Christophe Coenraets

Last year at MAX, we announced and sneak peeked the new multi-client support in LCDS. LCDS will soon provide native client libraries for iOS, Java, Android, HTML / HTML 5 (with WebSockets support when available), and Flex. The engineering team has been hard at work on this. My friend Mete Atamel has been leading the charges, and he recently recorded the screencast below showing six different clients connecting to an LCDS server.


Original article at

UDDI Integration with LiveCycle

Shone Sadler

On several occasions I have been asked about the possibility of integrating LiveCycle ES with UDDI to provide a standards based way of browsing LiveCycle services. Well I figured MAX2008 was a good motivator for getting such an integration working and so that is what I kicked off several weeks prior to MAX. I decided I would build a LiveCycle Component that allowed for both the publishing and querying of data to and from UDDI from within LiveCycle. Unfortunately, I quickly realized that there still seemed to be limited tooling around UDDI. So while, I could use a complete Java implementation of the UDDI specification from Apache, JUDDI, there was no easy means for me to browse the registry to show the results. This inevitably lead to the 2nd part of this proof of concept which was to build a UDDI browser with Flex. Note: there is an open source Java UDDI Browser available at that works well, however using it for a UDDI LiveCycle demo didn’t seem right for my purposes ;-)

You can view an entire walkthrough at Or the following lower res videos at YouTube.


So why did I create this demo?

  1. To provide a Proof of Concept for Integrating LiveCycle with UDDI
  2. To Discuss features and concepts around the LiveCycle Registry
  3. Learn How-to(s) with Flex and Web-Services (i.e. another excuse for me to improve my Flex chops)

IMPORTANT DISCLAIMER: This was a demo done as a proof of concept for which I am making the source code available. However note that the LC Component, and UDDI browser need a lot of fine tuning, which I have not and probably won’t have the time to complete anytime soon. The demo did accomplish its goal of proving that it is not only possibly but very feasible to integrate LCES with UDDI.

Below is a high-level diagram for the architecture of the UDDI/LCES proof of concept.

LCES UDDI ArchitectureLCES UDDI Architecture
  1. JUDDI: A Java based implementation of the UDDI 2 Specification which was used for purposes of this demo. You can find more info about JUDDI at
  2. UDDI Component: A custom LiveCycle component deployed in a LiveCycle Instance capable of querying the LiveCycle Registry and publishing service meta-data to a UDDI Registry
  3. UDDI Browser: An AIR application for browsing Businesses, Services, and TModels in a UDDI Registry.

LiveCycle ES Registry
The “Collective” Registry within LiveCycle ES is made up of at least 6 sub registries that store meta-data around the components deployed within ES. The meta-data in the LiveCycle Registry is used at both Runtime (e.g. Service & version resolution) and Designtime (e.g. to build composite applications).

LCES RegistryLCES Registry
  1. Component Registry: Stores the base information relevant to a component such as component id, title, description, etc…
  2. DataType Registry: DataTypes are Java classes that are exported from a component and that can be leveraged by the LCES tooling
  3. PropertyEditor Registry: Property Editors are UI elements implemented in Java that control the visual rendering of types and properties within LiveCycle ES tooling.
  4. Connector Registry: Connectors are integration mechanisms that define a means by which to invoke a LiveCycle service. Example connectors include EJB Connector, SOAP Connector, and VM Connector.
  5. Service Registry: Maintains all the meta-data we have around services such as the signature of a service, description, hints, config values, etc…
  6. Endpoint Registry: Stores configuration necessary to bind a service to one or more connectors. This provides for the loose coupling between service implementations and the means by which they are invoked (i.e. Connectors).

Trying out the UDDI Proof Of Concept
Unfortunately, I have not setup an environment where demos such as this are available online.
For now however you will need to do the following steps:

  1. Download and install the LiveCycle trial (if you haven’t already) from
    Note: This demo was built on LCES Update 1 (also known as 8.2.1)
  2. Download the Source Code for a) the AIR app and b) the LiveCycle Java Component (i.e. uddi-dsc.jar) used from Download Source Code Note: uddi-dsc.jar contains the related Java code within
  3. With LiveCycle up and running go to LiveCycle Workbench and click on Window–>Show View–>Components. In the Components view you can right click the top node to then install the Java Components downloaded (i.e. uddi-dsc.jar) Note: You will need to configure the UDDI3Service by right clicking it in the components view, setting the user/password expected by JUDDI (‘admin’/” for me), and setting the publishAsHost & publishAsPort (used to fill int the WSDL URL in the UDDI Registry)
  4. Import the Flex Project included in the Download to your Flex Builder environment
  5. Run the AIR APP!
  6. Oh wait….. Before any LC Services are available in the UDDI Registry you need to invoke the UDDI2Service.publishLiveCycleService. You can do this from the “Components View” in Workbench, however, you need to first turn on the unsupported workbench option –> -Dcom.adobe.workbench.unsupported.dscadmin.invoke.enable=true in the workbench.ini file

Anyway, Good Luck! there is a lot to play with there.

Few more notes for those digging deeper:

  • I packaged two modified WSDLs from which the WebService ActionScript stubs were generated within Flex Builder. I had to modify the WSDL to get around issues with the decoding of arrays.
  • If you need to regenerate the WebService ActionScript stubs then you will need to modify the src/webservices/inquiry/ file to change the isWrapped properties of the WSDLMessages to false rather than true.
  • The calls between LiveCycle and JUDDI seem to be slow on the perf side, but I haven’t drilled into that aspect as of yet

Original article at

Java exceptions and Flex

I’ve seen some articles on this subject but I have not found one dealing with all cases (webservices, BlazeDS, BlazeDS and Spring, data management). Also the approach for BlazeDS is different than the one used with Spring/BlazeDS integration, and this thing can be a little bit confusing for a beginner.

Let’s assume that you have a layer of services that should be invoked from your Flex application. You can expose these services as web services or as remote methods. Or you can use data management. The Java methods may throw errors and you want to display them in the Flex application.

For simplicity I will use a very short method as an example. The method signature is :

public String returnResults() throws DatabaseDownException;

There are four main use cases:

a)You have to write a webservice to return the result as XML. For example:

<?xml version="1.0" encoding="UTF-8"?>

In this case you will need to enhance your XML to add a structure for keeping error messages – like this:

<?xml version="1.0" encoding="UTF-8"?>

When building the XML the <error> body is going to envelope the exception message. Of course more information can be added, including exception type, severity, and so on. The same approach should be used also when working with SOAP services

b)You plan to use BlazeDS and Java remoting

In this case things are going to be easier,  because BlazeDS is able to automatically serialize the thrown exception and you can find the serialized exception in the FaultEvent object. Assume that you have the Java exception declared below. It extends the RuntimeException and it has a getter method for a custom field.

public class DatabaseDownException extends RuntimeException{
private String customField;
public String getCustomField(){
return customField;

The Flex code declares a remote object and registers a handler (which is also included) for failure.

<mx:RemoteObject id="test" destination="testDestination" result="resultHandler(event)" fault="faultHandler(event)"/>
private function faultHandler(event:FaultEvent):void{
var exception:Object = event.fault.rootCause;;;;;

There are four fields in the serialized exception. The first three are inherited from the Throwable object, the last one is declared in your exception. It is interesting to note that you need not have a pair of set/get function in order to have your property serialized. The Throwable object is the only object in which  it is enough to have get methods in order to serialize the values (you can take a look at to check that).

The only drawback is that you are working with untyped objects..if you don’t like that you can throw instead instances of flex.messaging.MessageException. This Java class is part of the BlazeDS and it will be deserialized using the class mx.messaging.messages.ErrorMessage (obtained from the event.message property).

You can add your custom data in the MessageException class using the extended property. For example:

MessageException messageException = new MessageException();
HashMap<String,String> map = new HashMap<String,String>();
map.put("clientName", "JOHN");
map.put("clientSurname", "MASTER");
throw messageException;

And on the Flex side:

private function faultHandler(event:FaultEvent):void{
var errorMessage:ErrorMessage = event.message as ErrorMessage;

You probably do not want to have an explicit dependence between your service layer and the BlazeDS libraries, so in this case you should build a delegate on top of it, which will also act as an exception translator.

c)Using Spring BlazeDS Integration

You have several benefits when using Spring BlazeDS integration, and if your middle tier is already using Spring it’s a must. The benefit related to exception handling is the exception translator mechanism. This translator will catch all the exceptions thrown from the services invoked from Flex and you can translate them into something more meaningful for the client.

First you need to declare the exception translator:

<bean id="exceptionTranslator" class="com.test.exception.ExceptionTranslatorImpl" />
<flex:message-broker services-config-path="/WEB-INF/flex/services-config.xml">
<flex:exception-translator ref="exceptionTranslator" />

The exception translator is below:

public class ExceptionTranslatorImpl implements ExceptionTranslator{
//handles all
public boolean handles(final Class<?> clazz){
return true;
public MessageException translate(final Throwable throwable){
if (throwable instanceof DatabaseDownException){
MessageException exception = new MessageException();
return exception;
if ...........//check another things

Note that in the current version of Spring/BlazeDS integration it is mandatory to have an exception translator, otherwise the original error is going to be swallowed and you will receive some generic error.

d)Using data management

The same approach from point c) applies here. Basically your assembler – which is going to invoke some service to obtain/create data – will take care of translating the exceptions into something meaningful for the client. I wrote some time ago a short post about that here.

Note: this article was translated also in Belorussian (thanks Patricia), you can find it here.

Original article at

Go to Top