Flex/AIR - I've fallen in love with the markup based solution and the desktop deployment-- but why does Adobe torture me and place my app in a glass cage? The limited API and the initial security policies for the platform present a doubtful outlook for anyone attempting to do anything but create a fancy web page. Yes there's file system support, but please, at least allow us to create modules in native (C++) code if Adobe's not going to provide the feature out of the box (specifically thinking of device connectivity).
Java WebStart/JavaFX - Today I went to Java.com, hoping to see some examples of Java WebStart, after all, I've heard a bit on JavaScript/deployment issues. Of course, I was rewarded with about five JavaScript errors when I loaded Java.com-- lovely. What can I say about JavaFX now? While I liked programming in Lisp in college, I don't care to write:{my:[{UI:'s'}, in:it]}.
]]>Much of this goes back to my previous blog on desktop Java and deployment-- where it's becoming much more appealing for business services. To me, it's not a matter of blurring the user experience, but of optimal data boundaries and scalability of deployment from a features standpoint.
Now, with JavaFX and the potential that it offers (again mainly because of Sun's announced product strategy and commitment), I'm still firmly behind my statement before on JSF 2.0 with pushing for a renewed focus on traditional web paradigms or at least optimizing for it. If we push for even more catering to AJAX within the
Lastly, when we are talking about specs/JSRs, we aren't creating solutions for now, it's more like two to three years from now. Where will the rest of the platform be going and when will JSF become the optimal choice for all web sites, including things on the scale of eBay or Yahoo?
]]>@PostConstruct and @PreDestroy. Coming from action frameworks, these 'implicit' hooks make composite presentations a bit easier to pull together, even in the stateless HTTP GET case.
JavaServer Faces currently has a couple great frameworks that extend application coordination and ease development. Since not everyone uses these frameworks, I wanted to write a short blog on what you can do out of the box with JavaServer Faces 1.2 and the reference implementation.
Since JSF's inception, you've been able to declare any number of java objects within multiple faces-config.xml files as termed 'managed beans'. Traditionally with action frameworks, each request is primarily sourced from a single action instance-- anything it can create is pushed into existence for the view to use. With JSF's managed beans, you can compose a series of stand-alone objects which can be pulled into the view in any quantity.
Sometimes it's difficult with action frameworks to be able to setup (push) everything the view may or may not need at the time of evaluation. When you have something like managed beans and EL within JSF, nothing needs to be pre-executed as your view can just pull in the managed beans it needs.
A simple use case is displaying data conditionally in the view-- happens all the time. Since you can pull only what you need into your view, there's less concern of pushing unnecessary database state into a view which may not actually need it. A second case is reuse. You may need to generate a list of current orders in multiple places. With JSF, the practice is to just create a 'CurrentOrdersBackingBean' which can be pulled into any view. Often many from the Struts world would've populated that list within any possible action that results in a view which may display the list of orders.
Basically, the development mentality with a pull MVC is to create fine-grained beans with a single purpose (SRP). JSF's managed bean declarations will allow you to wire in other state from session beans or request parameters. In the case of displaying a list of orders, you may end up with a config like so:
<managed-bean>
<managed-bean-name>ListOrdersBean</managed-bean-name>
<managed-bean-class>ex.view.ListOrdersBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>credentials</property-name>
<value>#{AuthManager}</value>
</managed-property>
</managed-bean>
<managed-bean>
<managed-bean-name>AuthManager</managed-bean-name>
<managed-bean-class>ex.view.AuthManager</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>The above configuration will allow views to use/declare ListOrdersBean and when JSF instantiates it, the AuthManager will be assigned, allowing the ListOrdersBean to pull the correct set of orders for the current set of credentials in the session.
@PostConstruct and @PreDestroyThere's a problem from a programming standpoint with the above example. Even if JSF assigns the credentials to your ListOrdersBean, when does your bean know to actually fetch the list of orders? When 'getOrders()' is called by the view? JSF has five phases to it's lifecycle-- 'getOrders()' can be called with each phase and you don't want to duplicate lazy instantiation with each call. What do you do?
Aside from hacking the if (this.orders != null) ... within the getter, JavaServer Faces 1.2 has the @PostConstruct which gets called before returning the bean for use.
public class ListOrdersBean {
private List orders;
private Credentials credentials;
@PostConstruct
public void init() {
if (this.credentials != null) {
this.orders = ....;
} else {
this.orders = Collections.EMPTY_LIST;
}
}
public List getOrders() {
return this.orders;
}
public void setCredentials(Credentials cred) {
this.credentials = cred;
}
}The init() method will be called once for instantiating the request-scoped bean and succeeding calls to getOrders() will not need to have a bunch of lazy initialization code.
You can take this one step further with List/Detail views and
stateless HTTP GET requests (/employee.jsf?id=456).
<managed-bean>
<managed-bean-name>EmployeeFinder</managed-bean-name>
<managed-bean-class>ex.view.EmployeeFinder</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>id</property-name>
<value>#{param.id}</value>
</managed-property>
</managed-bean>Notice that we can instantiate this backing bean for the request and have JSF automatically assign a request parameter (id) to the backing bean.
public class EmployeeFinder {
private long id;
private Employee result;
@PostConstruct
public void findEmployee() {
if (this.id > 0) {
this.result = ...;
}
}
public void setId(long id) {
this.id = id;
}
public Employee getResult() {
return this.result;
}
}Your employee.html page can then simply just use #{EmployeeFinder.result} to display the employee that matches the id parameter passed. If none was found, you can just display an error message without producing a second page (as is a traditional practice with action frameworks).
Who says every JSF request has to be a POST?
Another good point is that this granularity of backing beans without Servlet API dependencies makes unit testing much more practical.
I'm not going to discuss resource injection because there's a bunch of other great articles/blogs on the topic [1]. But the flow within the JSF 1.2 RI for instantiating managed beans is as follows:
@Resource declarations@PostConstruct on the bean if declaredWith the JSF 1.2 RI, you can get the pre/post events outside of a Java EE 5 container by simply having the annotations.jar in your classpath.
I hope this blog answers some questions on how to properly instantiate managed beans with JavaServer Faces 1.2, it's a big improvement over JavaServer Faces 1.1 and usable today with the RI.
When the AJAX gimmicks clear, we'll be left with two camps: the keep it simple page paradigm and then those who want the full rich client. Where people are getting bit right now, or possibly realize they will be, is when you sit in the gray area of the two camps. Right now, that's about everyone.
Let's talk technical first.
Let's start out in the traditional page paradigm which is 99.9% of everything on the web. Let's add in some JavaScript and AJAX functionality. To do that, we add in about 150 KB of JavaScript to our pages which drops load times (yes, even cached) and then use all of those nifty behavioral decorations which walk the DOM tree assigning dynamic behavior-- dropping page performance even more. The kicker is that probably 90% of your page activity still causes a new page to be loaded where you get to re-introduce all of this overhead again.
If you continue this route and keep layering in functionality with AJAX/JS as the solution, you'll end up with neither a rich client app nor an efficient web application.
We took this route and then ended up backing a bunch of it out because of performance issues. Don't get me wrong, we were by the book with all of the tricks and optimizations-- beyond the appeal of AJAX-- functionally, nothing was really gained that couldn't be rethought from a pure task flow standpoint.
Now lets get ridiculous and talk (best) case scenarios. You are using JSF-EXT or Flex to build your pages-- you still wouldn't kick the user into a different page [load] with mouse clicks would you? Even if you did have WPF or Firefox 8.0 with better performance and features, you must also serve the end user and clever uses of AJAX and JS behavior can sometimes be difficult to interact with. Either go simple click-to-page flows, or stay in familiar boundaries of the desktop paradigm.
If we commit to saying there's only two paradigms in web application development and say that anything between will be covered by supplementing the two extreme use cases, then JSF 2.0 needs dramatic changes from JSF 1.2.
On one side, you have the traditional page paradigm. JSF works well in this solution, but comes at the cost of stateful management and processing overhead. In addition, JSF's actions are represented in POST requests, not efficiently handling the traditional GET/Restful actions which content-based sites follow.
On the other side of full rich UI clients, JSF works well here too, but to a point. It does a great job of setting up a screen of rich AJAX components, but when it comes to loading in new pieces dynamically or introducing a new tab of content, things start to fall apart as JSF's navigation structure is stuck in the page paradigm. In addition, the screens' state is retained in a singular whole, which forces you to load everything up front or run into discontinuities later.
You could say that JSF today sits in the gray area of solutions for web application paradigms. While this covers a large number of scenarios, it doesn't surprise me at all that a single development group may use multiple UI frameworks for their applications which are specialized to the two primary application paradigms. Example, using WebWork or Struts for your public application, but JSF or Flex for your internal maintenance/data applications.
With JSF 2.0, I'd like to see a re-write of JSP and basically say tags are stateless components. Introduce annotations and reduce XML within JSP into a very efficient and handy templating solution on the web which can be used with other frameworks or with simple servlets. Then come in with JSF 2.0 and add in support for stateful components which work seemlessly with the stateless components-- introduce @Stateful or @Event concepts into the foundation of the new JSP presentation framework.
This easy to use JSP templating solution would more than solve the traditional page paradigm avenue while providing a foundation for rendering back service-based messages for rich clients. Simply put, low overhead, stateless, and compiled for performance.
Like icing on a cake, layering in JSF 2.0 features can then more easily scale with functionality in a highly optimized manner. If we approach this strategy of integration, developers can be much more flexible in the Java EE 6 platform in accomodating different use cases, even when we are mixing paradigms. Conceptually, developers work with one kind of component and no longer would there be multiple phases in view construction which consistently confuse developers.
The fundamental gain of JSF as your application controller is the idea of automatic composition and scalability of complexity. I've written about this before, but even in stateless component form, this architecture would be like declaratively wiring together 10 or 15 Struts Actions, reflective of your matching UI.
You may read the above and ask how is that any different than JSF 1.2 and JSP 2.1 today and the answer is simple-- JSP and JSF weren't originally written together and succeeding maintenance releases have too much legacy compatability issues to really deliver the simplicity developers expect today.
]]>First, lets take a look at the pro's of web-based ASP models:
Basically we have a list of pro's for the developer which are founded in ease of deployment. The exception is zero install on the part of the customer as a pro for the end user. But, rationally speaking, this is where we draw the line.
The con's of web-based ASP models are:
When providing a service over the web, the crucial point of issue is how to integrate your data models with the customers'? In the case of providing a singular service as a facet of a customer's business, such as reporting or CSR facilities-- how will the customer's other systems, services and data integrate with your application? Often times this is approached through manual import tools to port data over for external storage within your own hardware.
Also consider how much the customer depends on your services to make their business function. If you have a web-based application, can they afford down time? Even as an example of non-ASP models, sometimes centralizing functionality to a central data center can cripple your business if not scaled out correctly. Online magazines reported some of the biggest IT failures of 2006 were attempts at centralizing business-critical operations.
So am I suggesting reverting back to pre-dot com with installed software nightmares? No. Just that we should be more open to moving back to distributed software on the client. Data is king-- and in application service models, it's often the customer that owns all of the data. Understandably in this condition, off site application services deployments seem to be wrong route.
Following the 80/20 rule, a majority of operational information is localized to the business where the minority service provided can instead be remoted into a localized platform on the client. In addition, you have a much more valuable and tangible revenue channel with the customer instead of a service that can simply be dropped next week (because it's too much of a headache to maintain data in multiple places just to use your service).
What's changed in Java world that makes desktop deployments more practical?
Bruce Eckle recently blogged about hybridizing Java. Hybridizing for what? Prettier animations with flash? The Java runtime download now sits at 7 MB, which is fairly reasonable (more info here). While both Flash and Java are OS agnostic, can the Flash platform deliver the springboard of functionality that exists in the Java platform? If I'm committing to doing a desktop deployment (where the mechanics of the web aren't going to fit), I'll want to be able to 'really' integrate with the network, data, OS, etc. Not just deliver a pretty UI over the web. If there was a real benefit from delivering a pretty UI, Flash would've been much more popular for application delivery years ago. Adobe Apollo shows a bit more promise, but then again it still doesn't have everything the Java platform has or ever will.
I've been going through phases at work where I keep feeling like I need to pick up .NET for desktop development. But a few things dawned on me. If I commit to .NET, then there's the whole issue of installing the .NET runtime, which is just as large, if not larger then Java. From my experience with ASP businesses, even with deploying to windows OS, the .NET runtime installations and updates come up constantly with support issues. Secondly, with the increasing popularity of Linux and the Mac, even with exceptions, the .NET platform isn't as 'native' here.
One of luxuries that web-based ASP models afford you is easy patching and updating. As a web developer, it's extremely difficult to pull yourself away from that security blanket. So what has Swing and Eclipse done to alleviate this concern? Swing hasn't done much. The whole module, OSGi attempts within the JCP have been poorly spec'ed. I was somewhat interested in the Swing application JSR, but all it ended up being was an exploration in the academic ideology of coding an application. It doesn't have any tangible benefits for actually solving the Java on the desktop issue except for add more useless code abstractions to the runtime.
Eclipse RCP on the other hand has deployment and modularization built in with native rendering. I can't emphasize enough over the importance of this in making Java work on the desktop!. Finally we have a solution that allows developers to push out updates and features the same as you would in web-based deployments. From an ASP perspective, you have a localized deployment where additional features can be added/purchased all while the customer continues to have ownership over the data. Ah, the security blanket exists on the desktop too.
]]>No where do requirements base themselves on 'do not store more than 200 widgets at once in memory'. So why do these caching implementations work that way? Granted, there's opportunity to roll over to the file systems in these cache frameworks, but really-- if I wanted to guarantee persistence like that, I'd just store it to the disk in the first place or in the DB. Seriously. Anything I'd throw into a 'cache' would be just extra. Hibernate has strongly referenced 1st level caching, which makes complete sense for transactions, second level caches are just there to help with performance.
So what do we do? Lets take OSCache as an example. What I really want to do is specify a time to live (requirement 1) and either softly or weakly reference the data to allow the JVM to naturally optimize memory use. This means I can store an unbounded set of widgets in memory (None of this LRU/FIFO/LFU stuff), but still enforce that if the widget sticks around long enough, to put some restriction on how long until we allow it to be dirty again (forcing a re-fetch).
If you are dealing with bounded sets-- such as a couple of known articles or highlighted data, then fine, use a cache capacity/LRU-- but for unbounded sets where caching is purely there to enhance performance of the overall system-- just weakly or softly reference the data. It is a cache after all.
This becomes especially important in web applications where traditionally, we store data per session to optimize the user experience. But-- what if 80% of that data is required by another user? Could we push the cache to a global scope, out of the session and weakly reference it, such that all users share the same memory? I guess you could still store reference in your session, but globally weakly referencing the data would be an 'automatic' way of sharing common session data that's purely there for cache optimization.
The other thing would be to softly reference everything. In this case, you would just be able to store whatever you can globally, knowing that it will get cleaned up as the VM needs to allocate memory elsewhere. Still retaining the time to live policy here is important to prevent objects from sticking around for days at a time when you want to 'update' the cached instance after 20 or 30 minutes.
Another performance tweak to this with soft references, if the overhead of using soft references becomes too much, you can decide to 'chunk' your caches into segments where a whole series of caches can be softly referenceable, instead of per object.
net.java.project.Widget.cache.duration=1800
net.java.project.Widget.cache.ref=soft
net.java.project.Widget.cache.chunk=100Lookups would then be Key to Reference, Reference to Cache, Key to Instance.
Anyways, again, let me know your thoughts-- I've committed to using an existing cache implementation, but all of the settings of these popular libraries just seems disjoint to actual application use cases.
I implemented a straight ConcurrentHashMap<String,SoftReference> as a cache, then experimented with also queuing a TimerTask to force clean up of older objects. As a control, I also used a straight hard reference cache ConcurrentHashMap<String,Object>.
What I wanted to see is how accurate the use of SoftReferences in keeping the largest chunk of recently added objects. It'd be bad if the GC tossed out all the references you never cared about. Adding the TimerTask would hopefully help the GC recover the correct memory by cleaning references ourselves. So lets see what happens with varying sized objects:
TimerTask runs actually removed the object before the gc did (higher the better).Small Objects (100b):
HardCache[total=14057,size=14057,time=735,failed=true,oldest=0,hits=14057]
SoftValueCache[total=50000,size=3759,time=1547,failed=false,oldest=46241,hits=46241]
ThreadCache[total=50000,size=9031,time=1984,failed=false,oldest=40969,hits=24124]
Medium Objects (500b):
HardCache[total=3437,size=3437,time=781,failed=true,oldest=0,hits=3437]
SoftValueCache[total=50000,size=427,time=7297,failed=false,oldest=49573,hits=49573]
ThreadCache[total=50000,size=2085,time=8844,failed=false,oldest=47915,hits=43633]
Large Objects (1,000b):
HardCache[total=1849,size=1849,time=547,failed=true,oldest=0,hits=1849]
SoftValueCache[total=50000,size=430,time=10078,failed=false,oldest=49570,hits=49570]
ThreadCache[total=50000,size=393,time=11391,failed=false,oldest=49607,hits=45769]
So what do the numbers mean? ThreadCaching adds some overhead, to time/memory, but when the timer is able to clean up references before the GC, then we do get a better set of recent objects sticking around in the cache (good). For large objects, they get gc'ed before the timer can get to them, rendering them useless.
]]>If you have many different types of domain artifacts that you want to cache with a given lifespan, how come all of these caching frameworks (EHCache, OSCache, etc) don't automatically clean up the memory? It becomes a game of roulette in trying to optimize the most memory usage vs. potential usage for any given time of day.
This becomes a greater issue when we get into SOA where we've previously been able to sneak away with scoping information in the session, knowing well that it will be cleaned up after a certain period of use. With stateless service tiers, the caches are based on some interval-- but EHCache/OSCache don't guarantee object expiration when the objects aren't needed anymore.
It seems just silly that these caches will retain reference to Objects needed 2 days ago, only to tell me they are no good when/if someone wants them again.
Am I wrong in this expectation? I would the execution would go something like:
public void store(String key, Object value, long time) {
this.concurrentMap.put(new TempKey(key, System.currentTimeMillis() + time), value);
this.queueThread.notify();
}
protected final Thread queueThread = new Thread(new Runnable() {
public void run() {
try {
this.wait();
// clean up expired keys
} catch (Exception e) { ... }
}
});More on the topic here: Dion's Blog
I'm of the opinion that if you are willing to make a commitment to closures, then we do the same for properties-- something similar to C#. Spending time extending the long winded get/set convention is the wrong direction for the spec. Do everyone a favor and do properties right-- leaving the old Bean Property spec alone for APIs to accommodate and treating properties as a first class citizen in the metadata starting in SE 7.
Property[] p = class.getProperties();Aside from the misread syntax of an assignment arrow ('->'), I can see a lot of people get confused by implying method associations by some naming convention. Actually introducing a literal property syntax into the spec will make code much more maintainable in the long run, than visual guessing games around field accessors.
Some senior developers may scoff at the thought of bean naming conventions as confusing, but from being on web/el/mvc dev lists for many years, you are guaranteed to get those people who have problems with reading properties because they didn't capitalize/lowercase the right letter.
Please SE folks-- think outside the box.
]]>So I've been seriously looking for strategies that would prevent memory leaks, detecting dynamic changes in ClassLoaders or Classes. Some solutions go as far as to check the file system for class file changes, seems like a quite of overhead.
From talking with some of the guys from Sun, looking at ClassLoaders/Class implementations within the JVM, I thought looking at using WeakHashMaps and ConcurrentHashMaps together might provide a solution.
First, we would have a top-level WeakHashMap of ClassLoaders as the key. Secondly, we'll make the value of this ClassLoader WeakHashMap be a child Map of Class names to metadata (finally).
WeakHashMap<ClassLoader, ConcurrentHashMap<String, ClassMetaData>>The reason for this setup is:
Based on these points, I started throwing together a generic cache implementation that can be used to store anything per class, while attemping to avoid long term memory leaks.
public class ClassCache<V> {
private class ClassValue<V> {
private final Class type;
private V value;
public ClassValue(Class type, V value) {
this.type = type;
this.value = value;
}
public boolean matches(Class type) {
return this.type.equals(type);
}
public V get() {
return this.value;
}
}
private class ClassMap<V> extends ConcurrentHashMap<String, ClassValue<V>> {}
private class ClassLoaderMap extends WeakHashMap<ClassLoader, ClassMap> {}
private ClassLoaderMap classLoaders = new ClassLoaderMap();
public ClassCache() {}
public void set(Class type, V value) {
if (type == null) return;
ClassLoader loader = type.getClassLoader();
if (loader == null) loader = Thread.currentThread().getContextClassLoader();
ClassMap map = this.classLoaders.get(loader);
if (map == null) {
map = new ClassMap();
ClassLoaderMap replace = new ClassLoaderMap();
// copy on write
replace.putAll(this.classLoaders);
replace.put(loader, map);
this.classLoaders = replace;
}
map.put(type.getName(), new ClassValue(type, value));
}
public V get(Class type) {
if (type == null) return null;
ClassLoader loader = type.getClassLoader();
if (loader == null) loader = Thread.currentThread().getContextClassLoader();
ClassMap<V> map = this.classLoaders.get(loader);
if (map != null) {
ClassValue<V> value = map.get(type.getName());
if (value != null && value.matches(type)) {
return value.get();
} else {
map.remove(type.getName());
}
}
return null;
}
}This is just some ideas I've put together, does anyone else have specific suggestions on how to do this better/properly?
]]>JSF has two options for StateSaving: client and server (actually pluggable for anything you want). The basic rule of thumb is if you want to save memory, you go with client state saving-- pushing Object state to the client, encoded in the view. StateSaving server is a bit more performant, but retains stacks of views in the user's HttpSession.
What I want to focus on is client StateSaving. With saving state on the client, you are basically serializing an object graph and outputting it into the page as a Base64 String. Optional features here include encryption and compression. Encryption is only needed in rare cases-- but compression is often enabled. From my own tests, compressing JSF state means a reduction in size by at least a factor of 10 (hmmm... maybe this tells us something ;-).
By default, client state is compressed with normal GZip. I believe MyFaces actually opts out of compression by default, but any of Jason Hunter's old articles on Compression Filters actually tell you that compression is a good thing with network latency. Yes, compression adds processor overhead, but lets see if we can't look at some alternatives to GZip?
Diving through java.util.zip, I know that there are other 'Deflaters' available which have interesting 'types'-- such as Best Performance, Huffman, Best Compression, etc. Let's see how these compare with a grossly large JSF page (basically 100 pages put together in one) and averaged over hundreds of iterations of StateSaving:
Update: I've added Ryan's JMeter results from trying some of these algorithms against the CarDemo app with 50 threads running for 5 minutes at random intervals of 200-300ms.
| Algorithm/Type | Size in Bytes | Write in Milliseconds | Read in Milliseconds | Total in Milliseconds | Request/Second | Bytes/Second | # of Hits |
|---|---|---|---|---|---|---|---|
| None (Default MyFaces) | 174,345 | 78.14 | 198.12 | 276.26 | 91.8 | 2,529.89 | 27,598 |
| GZip (Default RI) | 12,864 | 103.72 | 205.68 | 309.4 | 58.6 | 518.05 | 17,633 |
| Default Compress | 12,852 | 93.42 | 174.08 | 267.50 | - | - | - |
| Best Compress | 11,855 | 110.24 | 171.04 | 281.28 | 62.2 | 544.76 | 18,695 |
| Best Speed | 16,480 | 86.58 | 176.24 | 262.82 | 63.5 | 569.02 | 19,091 |
| Huffman | 15,190 | 79.46 | 175.22 | 254.68 | 63.8 | 590.21 | 19,181 |
| Filtered | 16,480 | 79.36 | 176.88 | 256.24 | 64.1 | 600.97 | 19,272 |
The different algorithms are listed within the java.util.zip package in the javadocs, but I found the numbers to be pretty interesting. Of course, I'm a compression n00b, so if anyone had any comments on why it would be bad to switch to one of the other algorithms as a set-able option with JSF, please let me know!
I should note too that smaller page sizes, all the algorithms fluxate in timings between runs by quite a bit (5ms > 0ms) which may be attributed purely to GC or the ObjectOutput/InputStream itself.
]]>Anyways, if we have 5 different things we want to respond back with at once, how do we structure the HTTP response without ruining the original data-- may it be Strings, HTML, XML, or JSON?
We also have the use case of accepting the targeted response data, in addition to any other elements that are to be refreshed. An example would be responding back with some String, but your listeners on the server also want to re-render the cart total and a few other elements on the screen-- not part of the original response.
My first solution was to demarcate the response into separate headers. Each element to be updated had it's own header to occupy, leaving the body of the message alone (see above). This was a perfect or natural way of separating the response up based on HTTP's own spec. The problem is that HTTP containers never intended to carry that much information in their headers, and to prevent buffer attacks, many are capped at a few kb in size. So your refresh of the main table of data would always get chopped off or force an error in the container. Anyways, I think IE also caps the header size acceptable in the response.
So while this solution worked, it has a size cap which is very hard for a framework to enforce.
Another idea, which many use, is to break up the response into separate XML nodes in a parent document, allowing CDATA chunks of XML, HTML, or JSON:
<async-response id="5434">
<encode id="table"><![CDATA[ ... ]]></encode>
<encode id="cartSpan"><![CDATA[ ... ]]></encode>
<encode id="footerTotal"><![CDATA[ ... ]]></encode>
<body><![CDATA[ ... ]]></body>
</async-response>While we've moved all of the response out of headers and into the body, we've created issues for ourselves around doubling CDATA blocks, which are illegal according to the w3c police. Even if you do the ']]]]>' trick, you will still have problems with some browsers. It's still somewhat tricky.
JSON offers the same capabilities as using XML, being extremely flexible in representing different bits of data, but there's one major problem-- double encoding JSON. If we are trying to create a solution that accomodates all response types, who's to say that one of the responses isn't already JSON, and if we re-encode as JSON, we could end up with unusable garbage in the response.
{
id:543,
state:'REALLY+LONG+STRING',
encode: {
'table':'....',
'cartSpan':'....',
'footerTotal':'....'
},
body: '....'
}If we choose XML or JSON, it seems we might clobber encoding by either doubling CDATA/entity markup or double escaping JavaScript. So lets try to take those strategies out and just take the simplest approach of producing one Very Long String Notation!
Instead of trying to demarcate within a single body (XML, JSON), we just write everything out in one continuous String, noting when each chunk starts and stops in a separate table. This table can then be stored as a much smaller Response Header or as the first line of the response body.
{id:[0,3],state:[4,4503],encode:{'table':[4504,6004],'cartSpan':[6005,6240],'footerTotal':[6241,6733]},body:[6734,7320]}
340XHHUERe+JeKljfaefe.....Now you don't have to worry about encoding at all, you just take everything written as is!
]]>This release is considered 'draft' until users call it stable for production use. More information is found over at Facelets' web site.
Please give it a whirl and post any issues to the tracker or dev/user lists so we can push for another stable release!
]]>First is method invocations. Caching reflected data is so difficult to do without causing some kind of memory leak. I really wish JSE had some kind of ClassLoader listener API as a safer alternative to statically scoped data in web containers. Maybe others have more experience in this area? Anyways, performance of method invocation is pretty fast, it takes the same time to do a.b as to do a.getB()-- averaging 0.0016 ms on my laptop for both.
To be safe, I did add some logic for finding the best match if there are multiple methods with the same name. Tis better than nothing :-)
The more important addition is projections: a.{x|x.b} which means iterate over the Collection (a), for each, get (b).
Projections are useful in the presentation tier for binding sets of properties instead of requiring two parts: items="#{a}" var="v", value="#{v.b}". Actually, it may be more performant with the equivalent projection if you were to do: items="#{a.{x|x.b}}" var="v", value="#{v}". Anyways, there's a subtle difference in my implementation of projections as opposed to others.
Here's our model: A company has many departments, which have many employees. If I wanted to generate a list of employee names, I would do something like this:
#{company.departments.{x|x.employees}.{x|x.name}}
The OGNL equivalent is a little lighter in syntax:
company.departments.{employees.{name}}
..but produces a List of a List of Strings:
[['Bob','John','Sally'],['Jason','Marge','Kelly']]
That's not what we wanted! With the EL implementation, you instead get:
['Bob','John','Sally','Jason','Marge','Kelly']
Which seems more correct to me. The main reason is that EL is supposed to represent pointers to instances, so if I take the pointer (ValueExpression) and call the setValue on it-- I would expect that my target (each employee's name) would be set. So why would I return a List of Lists then?
Another cool feature of projections under the EL-API is the use of MethodExpressions. MethodExpressions work perfectly for hooking into Framework APIs as JSF has with generic actions, validators, etc. So lets say your backing model had a collection of Validators, but you didn't want to express each one separately?
<h:inputText value="#{bean.name}" validator="#{bean.validators.{x|x.validate}}"/>
What I'd really like to see added to the EL-API though is pluggable type conversion and method invocation. Right now you can plug in your own property resolution, but the strange thing is that if you take the expression #{a.b} as a value, you can customize the resolution of (b), but if you take it as a method, then you cannot customize the resolution of (b), so the method must always exist on that instance in accordance with the EL implementation's rules.
To correct these two missing pieces, I would like to see two methods added to the ELResolver API which allow near everything to be customized with:
public Object convertType(ELContext ctx, Object in, Class type)
public Object invoke(ELContext ctx, Object base, Object method, Object[] params)
public MethodInfo getMethodInfo(ELContext ctx, Object base, Object method, Object[] params)
The execution of these methods would work the same as the other ELResolver methods, requiring the propertyResolved to be set to 'true'. It'd be great then to allow customized extensions of Iterable/Collections/Maps such that one could do:
#{company.departments.asc{x|x.employees.{x|x.name}}}
Which would call into the ELResolver chain with the following:
public Object invoke(ctx, Collection, "asc", new Object[] { closure })
This would allow you to treat closures as value-types for some pretty extreme customization with mixing your own Java code into the execution of 'inlined' EL without requiring full API changes within the JSE.
Basically, these are just some future ideas for EL, whenever it becomes it's own JSR. With Facelets and custom EL-API implementations, such as this one, you can just set one property on the compiler and away you go with the added features.
(I have to start releasing stuff again)
]]>Two things: does T and D have anything to do with the noun 'comment', and why isn't the IDE smart enough to do this with one command? Consequently, running the comment command multiple times will keep on adding more '//' to the beginning of your lines. Great.
Hotkeys aside, I'll always try to right click to find associated features. This is fairly confusing in NetBeans for common tasks such as implementing abstract methods or generating bean accessors. When you are writing APIs and deal with inner classes, this only adds additional confusion with the IDE.
Right-clicking on a Class, under the Refactor sub-menu, you are presented with a list of options for all Java types-- including: Extract Method and Change Method Parameter types-- what does that have to do with a Class declaration? Feel free to pick these options, but you will be presented with an error.
If I'm declaring a new class, or add an additional abstract method, why can't I right-click and implement those methods. Yes, the option is on the top menu, under 'Source', but I'm concerned with the context of my cursor in the code-- may it be a method or class file, not 'mousing' away from it to the top menu under 'Source'.
Finally, many of the options around refactoring are always forced into a review dialog before committing the changes. If I want to generate getters and setters, and select the fields I want, why always force me to review in a second dialog? I've gotten caught off guard so many times because that bottom pane has everything loaded into it for output, junit results, etc. Clicking on 'next' in the pop-up dialogs, closes the dialog, then adds yet another tabbed panel to the bottom with the next step to confirm what I just said I wanted to do. It seems unecessary and should be an optional flow-- and even if I wanted confirmation, why close the dialog and put the next step in another panel?
Overall, NetBeans isn't bad. It's just not as intuitive as others I've used. It's still never obvious to me with what classes have errors and which ones don't without hitting the recompile button.
]]>I decided to test the following EL libraries available today:
Here's a table of features I thought were pertinent:
| Library | A.B Accessors | Math | Method Invocation | Projections | Regular Expressions | Coercion | Conversion | Pluggable Property Resolution | Pluggable Method Resolution | Serializable | Factory Caching |
| Commons-EL | Yes | Yes | No (functions) | No | No | Yes | No | No | No | No | Yes |
| OGNL | Yes | Yes | Yes | Yes | No | Yes | Yes | Yes | Yes | Yes | No |
| MVEL | Yes | Yes | Yes | No | Yes | Yes | No | No | No | ? | No |
| EL-RI | Yes | Yes | No (functions) | No | No | Yes | No | Yes | No | Yes | Yes |
| JEXL | Yes | Yes | Yes | No | No | Yes | No | No | No | No | No |
Pretty obvious things that stand out are that OGNL and MVEL have a lot more syntax features compared to the standardized EL. I think this is largely impart to the fact that EL was only intended for simple notation within the View counterparts and not as a scripting language. I will say that there's absolutely no reason why these other syntax features shouldn't be added to future releases.
Pertaining to pluggability of syntax evaluation, OGNL is the most expressive with Method, Property, Index, etc. The new EL-API has similar capabilities for Property and Index Accessors with chainable ELResolvers.
*Factory Cached means the API's factory method inherently cache expressions to some degree and do not re-parse on every call.
API Use:
Commons-ELExpressionFactory fact = new ExpressionFactoryImpl();
VariableResolver vars = new VariableResolverImpl(..);
Expression expr = fact.parseExpression(str, Object.class, null);
Object value = expr.evaluate(vars);Map vars = new HashMap();
Object expr = Ognl.parseExpression(str);
Object valu = Ognl.getValue(expr, vars);Map vars = new HashMap();
Object value = Interpreter.eval(str, vars);ExpressionFactory fact = new ExpressionFactoryImpl();
ELContext ctx = new ELContext(...);
ValueExpression ve = fact.createValueExpression(ctx, str);
Object value = ve.getValue(ctx);Expression e = ExpressionFactory.createExpression( jexlExp );
JexlContext jc = JexlHelper.createContext();
Object value = e.evaluate(jc);
Finally, I have some performance numbers at 10,000 iteration, average time in milliseconds:
| Library | test.fubar != null | test.num + 10 - 1 |
| Commons-EL | 0.00249 | 0.00343 |
| OGNL | 0.20751 | 0.23535 |
| MVEL | 0.02032 | 0.03775 |
| EL-RI | 0.00714 | 0.00715 |
| JEXL | 0.34199 | 0.21907 |
| Commons-EL (re-use) | 0.00597 | 0.01462 |
| OGNL (re-use) | 0.00342 | 0.00712 |
| EL-RI (re-use) | 0.00394 | 0.00767 |
| JEXL (re-use) | 0.04946 | 0.01123 |
*re-use means take the Expression returned from the factory and keep evaluating that instance instead of going back to the factory again. This didn't show much of a difference for those EL libraries that cache within their factories, but it did show a big improvement with OGNL and JEXL.
Serialization can be important for some libraries and the EL-RI was optimized for use with JSF's state-saving architecture. I'm sure other frameworks may have similar concerns. Here are the sizes in bytes for the couple libraries that were actually Serializable.
| Library | test.fubar != null | test.num + 10 - 1 |
| OGNL | 594 | 764 |
| EL-RI | 170 | 169 |
Synchronization was another thing I wanted to test, but haven't yet. Supposedly OGNL has some unwanted synchronization blocks and JEXL has not been optimized at the Factory level at all-- putting a synchronization block around expression creation, with calls to commons-logging.
In summary, here's just my observations from an afternoon of testing. While I'm not an expert on all of the libraries listed, feel free to comment on where I might have missed a point or gotten things wrong.
]]>