I really like the concept of FutureValues. http://c2.com/cgi/wiki?FutureValue
And although I'm working in a CLDC 1.1 environment (Blackberry), I'm wondering if it is
possible to implement it with the available wait-notify / Threading support in Java 1.3.
Basically I want to create:
ExecutorService - to start threads
Each thread then communicates with its Future on completion.
You might look here, which formed the basis for the java.util.concurrent stuff... I don't know if you can get it to work on CLDC 1.1... but worth a look.
Related
Can somebody give me some insights what is the difference between Netflix Zuul version 1.x.x and new version 2.x.x?
Seems that both product line are maintained.
And version 2 is using Guice for DI and there are some difference in Filter implementation. ??
I got really nice answer from #NiteshKant on GitHub from Netflix:
Unfortunately there is no documentation about the motivations for 2.x and what it changes. I am intending to put together something in the coming weeks when time permits. As of today, I hope the following suffices:
What is 2.x?
2.x intends to move zuul from current synchronous execution model to a top to bottom asynchronous processing model. This includes using non-blocking I/O (practically RxNetty as the networking library) and application processing semantics (RxJava as the asynchronous library)
Why 2.x?
Intentionally staying away from proofs and benchmarks, the motivation for 2.x (essentially moving to an async model) is to have better resilience, control and performance characteristics for all applications inside Netflix.
Status
The current status of 2.x is snapshot. We are currently testing the new filter model (async) with blocking I/O inside netflix. Once we are comfortable with this change, we will be testing the changes with non-blocking I/O. After that we will be publishing release candidate and release artifacts.
Should you adopt 2.x now?
2.x is really very bleeding edge (sorry for the cliche) so we will be changing APIs, deployment models and implementations. So, unless you are prepared to take the burden of keeping up with these changes, I would recommend waiting a while.
Also, 2.x comes with lots of changes in usage, so most likely you will have to change all your existing filters, if any. This can be a big task depending on the current usage. So, it is your decision on that front in terms of ROI.
There are more related links to the subject on Zuul 2.x:
https://github.com/Netflix/zuul/issues/121
https://github.com/Netflix/zuul/issues/106
https://github.com/Netflix/zuul/issues/139
https://github.com/Netflix/zuul/issues/130
Do you know of any equivalent of Microsoft Application Verifier for managed applications?
Thanks!
The question doesn't make a lot of sense. The best equivalent for Application Verifier in a managed app is Application Verifier. It works just as well, a managed program also allocates memory from the Windows heaps and uses locks and handles. The odds that it will ever find anything wrong are just rather low. Managed code just doesn't suffer from the kind of problems that make Application Verifier useful for code written in an unmanaged language.
Maybe you want to verify something else, it isn't clear exactly what. The FxCop tool is a good one that analyzes managed code for all kinds of oopses that are common in .NET programming. An entirely different set of problems than Application Verifier checks for. It is also a static analyzer. At runtime, the verifier built into the jitter and the strong argument validation in .NET framework code and the CLR keep you out of trouble. Managed code was inspired in no small part by the kind of problems that required a tool like Application Verifier.
But no, there is no equivalent tool for managed code
It turns out that there are cases where this functionality is required for managed code.
Unfortunately I'm in one of those situations right now.
Have a look at Microsoft Research CHESS: http://research.microsoft.com/en-us/projects/CHESS/
And the Channel 9 video demo, the developers of the tool mention that the behaviour of the tool is very similar to appverifier and that it can test managed code: http://channel9.msdn.com/shows/Going+Deep/CHESS-An-Automated-Concurrency-Testing-Tool/
Download from: http://research.microsoft.com/en-us/downloads/b23f8dc3-bb73-498f-bd85-1de121672e69/
Is it possible to use JSF 2.0 (PrimeFaces for example) as view layer for Play Framework? I'd like to combine elastic hot redeployment of Play with easy component driven JSF developement (instead of MVC and template driven GUI design).
I think all I need is -
1. Run FAces Servlet (javax.faces.webapp.FacesServlet) and maybe some other servlet
2. Tweak el-resolver in faces-config.xml just like org.springframework.web.jsf.el.SpringBeanFacesELResolver does.
Have anyone did something like this? I'm new in Play Framework. I use JSF + Spring + JPA now.
JSF is fully based on the stateful aspect of Java EE web stack and on the servlet API!
Play is just a full stateless framework and doesn't use servlet API at all!
So the answer is "No you shouldn't use JSF as the view layer of Play". I use "shouldn't" instead of "can't" because everything is possible but it was be really bad thing!
Nevertheless, you really should think about leaving JSF after wanting to leave MVC. If Play! exists, it's not only because of Rails/Django/Symfony are good, it's also because JSF-like frameworks aren't good, efficient and viable solutions for many reasons you can find everywhere on the web or even in your own experience maybe.
I would advise you just to give a try to Play+JPA (or even something else to replace JPA such as Siena) for real. Don't begin by mixing Java EE stuff with it, use Play 100% to see how it performs. If you need to use Spring with Play, there is no problem but it's not required in many cases. You will discover how easy and efficient it is to build apps from the smallest to the biggest enterprise ones. In my experience, since I use Play, I find this framework promises things and keeps them which is very rare in this world!
Have fun!
By default, no this is not possible.
Play does not conform to the J2EE specification, and as such does not implement the Servlet specification.
However, it may be possible, with a fair amount of effort. Play developers have already created a ServletWrapper that allows Play to be deployed to standard servlet containers (like JBoss and Tomcat etc), so they have shown that you can integrate with J2EE technology, if you want to spend the time and effort to write your own Plugin that overwrites the default nature of Play.
I wouldn't bother though. Just take a look at the template engine that comes with Play. It is very good, and I have not missed JSPs at all since using Groovy.
You can use JSF2.2+Primefaces and Spring + AKKA framework which is better and faster than play.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Now that Google allows Java on App Engine, I'm wondering what effect this has on a choice of web framework for App Engine.
I realize Google provides the webapp
framework which is pretty barebones.
And the .96 version of django that's
available for App Engine is
restrictive.
web2py burns up resources, from what I've heard.
Rails (now available) can't use
ActiveRecord, ActiveResource,
restclient, rmagick.
Is there something I'm missing - do any frameworks work well on App Engine?
Actually web2py is very light and since ~1.50 on GAE, it caches all bytecode compiled models/views/controllers.
Nevertheless you need to consider that by default is has datastore based sessions and this may add some overhead when compared with framework that do not have sessions working on GAE (at least not by default).
The web2py DAL itself does not add a significant overhead when compared to the naive Google datastore APIs.
Personally, I have found Python to be more fun. That's just me. However there are several commited Java developers out there that will appreciate the Java support in GAE. Furthermore, supporting Java was a good choice by Google since it will allow the GAE platform to potentially host many other languages. It's obviously a little early to expect all JVM based languages to run on GAE, but the future looks promising. For now we can look at what is and isn't working by taking a look at this GAE Java Group Page.
Coming back to Python, I think small web applications will work great with the built-in webapp framework. Other applications will benefit more from Django 1.0. Have a look at the GAE articles under the frameworks section for a few good reads on this. In any case, you will undoubtedly have restrictions in any of your choices since most web frameworks are designed with relational databases in mind ... which datastore/bigtable is not. Furthermore, the GAE platform has to be sandboxed for security reasons which also restrict you to some extent. Hope this helps.
Try Spring. It supports JPA and JDO.
There's even a Python version for Spring now.
I don't know exactly the full range of options, but I can tell you a couple of things off the bat...
Google Apps is built on top of / using Django.
Django is pretty much what Google Apps cheer and support, so I'd expect it to integrate with Google Apps better than others.
Google Apps has restrictions built into it that you cannot circumvent (or shouldn't). These limitations are not related to any particular framework, rather they are built into the fabric of Apps, so to speak.
I wouldn't worry much about performance of the framework - try to improve your design/structure, it will certainly payback better.
Google will eventually move to Django 1.0 and newer, plus they are updating Google Apps too.
They do use memcache (or an equivalent) so take that into consideration and utilize it.
It really depends on what you want to do. In my experience something small hand made on top of Webob is really good for an API. But for full fledged sites that need templates/sessions/complex routing/caching django is hard to beat.
Take into account that if you huge frameworks (like django 1.0) the first request always takes around 3 seconds to load everything in memory and keeps it there until 15 secs after that request.
And while you shop around for frameworks take into account that:
ORM's don't apply to the platform so basically don't matter.
Fast templates (like Cheetah) won't be fast (or even work) as they can't use c extensions.
Caching might be the most important thing to make everything fast.
If you are looking for Python, then Django would be your best bet.
Struts 2 is purported to work on Google App Engine (at least in terms of the example applications). Follow this thread:
http://www.nabble.com/Google-App-Engine-support--td22972179.html
It appears that there are some issues with Sitemesh in terms of templating, but if you're using JSP you should be ok.
It's a good choice as a web application framework goes.
I recommend web.py if you're using Python.
I use new framework GAE framework. This is similar with Django, but work on AppEngine.
Best regards!
For Python use webapp2 (comes bundled with app engine)
If you want to build large scale application and need more flexible framework, then you can take a look at Pyramid Python Framework. Previously it is called as Pylons. There are lot of good companies using this framework.
My experiences with web-frameworks was that they are relative "unstable". Not that they crash but that there are quite a few changes which then force one to reprogram ones code. I wonder what web development packages you've used and how much work it was/is to maintain that code?
"Changes are a part of the requirement."
I dont think that the web packages that we design changes a lot. If it changes, then it is a bad design. If we use external API's, a very few get deprecated, otherwise most of them are the same.
Some packages used as a JAVA/J2EE programmer:
- MVC
- Struts
- few AJAX frameworks
These are very basic one used. Most the other ones are self developed and once the design of the web package is done, we don't change the design.
Any library which is under active development would be unstable. Look at .NET for example, every month there's a new better way to do old stuff. On the other hand open source libraries tend more to throw old deprecated methods away because it makes code better and that's what makes them happy.
But I wouldn't recommend to use anything old and unsupported anyway, you'll be on your own although the environment would be completely stable.
The best way possible seems to be just freeze the version of library you start using and switch to new one only there's huge benefit in doing so. At least that's how everyone is doing that.
Frameworks like .NET and jQuery have been largely backward compatible and allows you to use new features slowly.
Mootools however... the API broke so many things from 1.11 to 1.2 to 1.3. Upgrading was not straightforward in that case.
As a rule, I try to wait for something to be out of beta before embracing it in production code. An endorsement can go a long way too - since Microsoft has called jQuery the winner of client-side frameworks its been easy to encourage others to pick it up too.
Most of my experience is with Ruby on Rails, so I'll share what I've seen with it over the last few years.
Rails updates at a pretty good clip, but you don't really need to update unless you need features or the rare security patch. As an example, I have a rails app running in our company right now that was coded about 2.5 years ago that only needed to have some work done to it once this year to upgrade it to a new version to be compatible with apache mod_rails, it was originally written against Rails 1.2 I believe. Of course, that was an intranet app which didn't have any security requirements. All in all, it's been pretty pain free. If I had kept using mongrel + mod_proxy it wouldn't have only needed to be updated once for a security patch.
Rails is pretty secure, vulnerabilities are fairly far between. There have been a few more Ruby vulnerabilities than Rails vulnerabilities if memory serves me right, but all in all it's pretty solid, and upgrading your ruby shouldn't break rails, especially if you use a distro that backports security fixes.