Home

I had the tingling feeling with the previous release of tapestry-security but since we have such a blind faith in our functional testing suite, and the tests all passed, we went ahead and managed to cause some headache for all of our users deploying their secure applications to non-root contexts. At least I'm happy the library is popular enough that I get immediate feedback when I screw up (thanks Lenny!). Anyway to restore our crisis of faith, we responded by writing even more tests and here we go again, upgrade to tapestry-security 0.4.4, it's all fixed. There's also some updates to the documentation, check out tapestry-security guide!

Release notes:

Sub-task

• [TYNAMO-144] - This patch broke fallbackURL functionality
• [TYNAMO-145] - TYNAMO-133 breaks SecurityUtils.logout() from within Tapestry onEvent methods

Bug

• [TYNAMO-124] - Context path duplicated when redirecting to saved request

The Tynamo team never rests and is at it again, bringing you a new Tapestry module: tapestry-activiti. This module allows you to integrate Activiti into your Tapestry application. Activiti is a workflow and Business Process Management (BPM) platform. Its core is a super-fast and rock-solid BPMN 2 process engine for Java. We are very excited about this new module and can't wait to hear your thoughts, suggestions and how you put it to use. Go check out tapestry-activiti!

Cheers,
Tynamo Team

PS: We'd like to thank Omar Carvajal for all the work he has put into this.

I rarely find it good use of my time to read random blog posts, but every once and a while you hit a gem. The following is not written by me but I agree with it word for word, and is one of the reasons I left the enterprise world:

"Today I found myself thinking again of what I see as two distinct cultures in the development world: Hackers and Enterprise Developers. This really isn’t any kind of a rant just an observation that I’ve been thinking over lately.
Hackers are really bleeding edge. They have no problem using the commandline, using multiple languages, or contributing back to open source. They’ll find and fix bugs in the opensource software they use and issue pull requests frequently. They’ll always be willing to use new tools that help them produce better software when there might not even be any good IDE support. Finally, they’re always constantly investigating new technologies and techniques to give them a competitive edge in the world.
Now when I say hacker I don’t mean someone who just hacks lots of random shit together and calls it a day (that kind of developer isn’t good for anyone). Just someone who isn’t afraid to shake up the status quo, isn’t afraid to be a bit different and go against the grain. They’re the polar opposite of enterprise developers.
Enterprise Developers on the other hand are fairly conservative with their software development methodology. I’m not saying that a lack of standards is a good thing, but enterprise developers want standards for doing everything and they want it standardized across the company. If there isn’t IDE support for a tool they’ll refuse to use it. Want to use mongodb, riak, etc? Not unless there’s a fancy GUI client for interacting with it. If they find a bug they’ll back away from the framework they’re using and simply declare that the company shouldn’t use the framework until the bug is fixed externally. I find this group prefers to play it safe and work on solidifying their existing practices rather than explore new ideas.
Now don’t get me wrong, this isn’t another rant on IDEs or developers who don’t use the command line. But give me a couple days in any organization and I can quickly point out who the Hackers and Enterprise Developers are."

It's also noteworthy to point out that at least from my experience, the average enterprise developer typically makes much more than the average hacker. So who's really the smart one, eh? Read the whole post at: http://www.javacodegeeks.com/2012/03/tale-of-two-cultures-hackers-and.html

I swear, I thought tapestry-security already implemented anything you need for security. But turns out I was wrong. So, we quickly put together another, even more awesome release of tapestry-security for Apache Tapestry 5 from tynamo.org, with the following enhancements in the newly baked 0.4.3:

Bug

• [TYNAMO-124] - Context path duplicated when redirecting to saved request
• [TYNAMO-133] - ShiroHttpServletRequest isn't used if there's no chain associated with the request

Improvement

• [TYNAMO-121] - Ability to plug into ExceptionPage for the same exception type
• [TYNAMO-127] - Make SubjectFactory and RememberMeManager their own services for better flexiblity

New Feature

• [TYNAMO-128] - Make Authenticator its own service to allow registering authenticationlisteners

Check out the tapestry-security guide for more information and enjoy!

Oh and btw, we had also previously released but hadn't announced a bug-fix release 0.1.2 for the exceptionpage module, that tapestry-security uses for exception handling. The lone issue was:

Bug

• [TYNAMO-126] - Exceptionpage doesn't work for page contributions

Read more about the exceptionpage module from tapestry-exceptionpage guide

Tynamo's ranks are growing yet again! Please join me welcoming Dragan Sahpaski to the project. Dragan is a highly skilled individual whom I had a privilege to work with last summer when I was mentoring him for a GSoC project. I've had this idea for a light in-place content editing component for Tapestry5 and when I was looking for a reasonable rich text editor to integrate with, of course I found tapestry5-ckeditor, a brilliant CKEditor integration for T5 that Dragan had put together. At the same time, he was looking for a solid home to publish the component. Fits like a Huggies diaper, right? This marks the first foray into UI components for Tynamo.org though, but hey what's life without risks?

The following is an unedited reply to an email from a good friend of mine who is desperate to run his own startup. Thought it might be an interesting read to other non-engineers who find themselves in a similar situation.

Hey XXX, somehow our conversation from the other day got stuck in my head. First, I have to say that it looks to me you are putting too much emphasis on technologies. You should let your engineers and the business needs guide your technological choices, not the other way around. It's going to be expensive to rewrite your application later if you need to, but so what, it's going to be much more expensive to change the business if your current one doesn't work, and yet you are still doing it. Unless you want to make it your core competency to implement the solutions using the chosen technologies, you have to trust and rely on your engineers to make the right choices for the given problems. What you primarily need from your engineers is motivation and experience with one of the reasonably good technological choices and leave it at that. It's difficult to predict the future so whether you pick RoR, Django, Play or some other hot technology today, you don't know if it'll be a success anymore a few years down the road.

On the popularity of Tapestry, you asked "so how come nobody uses it?" By many measures, Java is the most popular language in the world but very few think of it as cool or hype it. The hyped Java is today pronounced "Android" or "Scala". Tapestry is a good example of what's left after the hype has deflated. Ruby on Rails is a fairly successful and popular framework, yet it was much, much more popular six years ago than it is today. In the world of Java, Tapestry, Play or Lift are still newcomers compared to such behemoths as Struts (one of the original web frameworks in Java). Java is just popular and old enough that the space is fragmented. The good news is that beyond "just" the web layer, you have libraries implemented in Java for almost any imaginable purpose you can simply take into use. Tapestry, or Java are not always good choices for web applications, because the needs for most of the websites are simple, so a simpler language and a simpler framework will not only suffice, but work better because more people are more productive with it and there may be less room for grave mistakes. For lots of applications you simply don't need all of the power Java or the JVM has to offer, but when you do, you really need it. The classic example for this is a highly threaded back-end application - if you have a need for it, a typical RoR or Python-based architecture implements the web layer in the given language, but the back-end architecture with a different language. Few other languages and platforms besides Java are comprehensive enough to implement everything from web to the database with the the same language (although certain Microsoft language comes to mind as an alternative). With RoR, Python or PHP, you pair it with MongoDB (implemented in C++) or perhaps MySQL (in C++ as well). A Java web framework, you pair with Cassandra, Hadoop, hsqldb or any of the other strong alternatives based on need, all implemented in Java. It makes it all more complex, which is also reflected in the pay grade between a typical Java developer and a php developer, or any of the other languages in between. What makes this even more interesting to you, is that as a business owner you have to consider the costs so the best solution for you might be finding the most inexpensive developers that are highly productive with their language of choice.

*** UPDATE ***: A bit after my email, my friend sent me a link to this great blog post by the Tumblr guys, to which I just had to reply. Again, I've re-posted the unedited follow-up below. Keep in mind that I'm purposefully making some simplifications to make my point clear (after all, I'm talking to a business dude). Anybody who's battled with scalability issues knows that while theoretical numbers might justify more modest hardware, it's all about building for the worst-case scenario with plenty of reserve capacity.

Nicely proves my point, no? :) Anyway, it's a surprisingly honest read about their architecture, and shows how most of the time it's all organically grown. They are getting reasonable results with their infrastructure, but still, paying a heavy penalty for the suboptimally performing web layer - 500 web servers versus 200 database servers, where most of the latter are used for stand-by high availability. In a typical scenario, the bottleneck should almost always be the database layer, not the web layer. Sharding is a way to get scalability out of MySQL, but it's far, far away from the highest performing SQL databases. Now, imagine if you could serve the whole database layer with 20 servers instead of 200.

For an all Java implementation with an embedded database, it's not uncommon to require 90th percentile response time within 10ms with at least 1 million page views a day from a single server. Performance matters (http://docs.codehaus.org/pages/viewpage.action?pageId=190316696).

At long last, we've gotten off our collective lazy ass and worked harder than ever for free to bring you tapesty-federatedaccounts 0.1.0, with twitter as the new authentication provider. Some jokesters might question why it took so long since we are just using the super-great twitter4j library, which is almost as good as RestFB that we use for Facebook integration. We are first to admit that twitter4j takes all the pain away from Oauth 1.0a's obnoxious request signing business, so we decided to spend our time refactoring the code to support the Oauth 1.0a/Oauth 2.0 call flows with the same base classes, as well as modularizing the whole implementation because one size just doesn't fit all. Now of course, you my dear don't even have to know any of the these details but just check out tynamo-federatedaccounts guide and open the gates for all of the Facebook and Twitter users to flock to your website

Release notes:

New Feature

• [TYNAMO-92] - Twitter realm for federatedaccounts

Just like that, we released tapestry-security 0.4.2. Nothing major, just one pesky little bug that we managed to miss on the last go-around:

[TYNAMO-120] - FallbackURL is no longer honored

You should upgrade.

Tapestry-security, the comprehensive security package for Tapestry just got a bit more comprehensive with the new 0.4.1 release! 0.4.x is tested with and meant both for T5.2 and T5.3.

We picked up the brand new Apache Shiro 1.2.0 release of which development snapshots we've been running against for months now. We also decided it's time to start eating our own dog food, so we delegated tapestry-security's exception handling to another module from tynamo.org, tapestry-exceptionpage, in order to gracefully handle security responses as redirects, ajax or not. Read more about what tapestry-security can do for you from tapestry-security guide. Special thanks to Lenny Primak for relentlessly bugging us until we just had to get the 0.4.1 out the door

Release notes:

Bug

• [TYNAMO-102] - Specify id for RequestExceptionHandler advice for preventing unintentional override
• [TYNAMO-103] - @Security, tapestry.secure-enabled, MetaDataConstants.SECURE_PAGE not honored by Tapestry security
• [TYNAMO-105] - Warning is issued in the log file on every startup

Improvement

• [TYNAMO-87] - Redirects should honor localization
• [TYNAMO-106] - Login screen background file (login-bg.png) is too large for the web - smaller file attached
• [TYNAMO-109] - Allow Unauthorized and Login page to be a single page
• [TYNAMO-110] - redirect to login page for pages secured with @RequiresXXX annotations
• [TYNAMO-113] - Test for ajax in the AccessControlFilter.issueRedirect and issue a client-side "soft" redirect if so
• [TYNAMO-117] - Add symbol for disabling redirect to saved request
• [TYNAMO-118] - Store savedrequest into a cookie instead of session
• [TYNAMO-119] - In SecurityFilterChainFactoryImpl, use componentClassResolver to resolve pageclasses to urls

New Feature

• [TYNAMO-111] - Add support for SslFilter & PortFilter

Winter is still in full swing, but the hibernation period for Tynamo is clearly over. I don't want to steal any of Alex' thunder from his JDO release, but on the heels of it we quickly shipped another release from our module warehouse. Tapestry-exceptionpage 0.1.1 is particularly useful, so handy in fact that we even started using it ourselves  Tapestry-exceptionpage forms the foundation for handling exceptions in our upcoming tapestry-security 0.4.1 release. Read more from tapestry-exceptionpage guide.

Release notes:

Bug

• [TYNAMO-97] - tynamo-exceptionpage doesn't handle operationexceptions

Improvement

• [TYNAMO-112] - Properly handle ajax "redirects"
• [TYNAMO-114] - Improve exception cause handling and documentation

I am excited to announce the release of the new addition to Tynamo's beautiful set of modules : tapestry-jdo . It brings the idioms that many Tapestry developers have come to enjoy w/ Hibernate and JPA to JDO users. Read more on the Tapestry JDO Guide.

This module has been a long time in the making - the initial commit of the basic functionality was added about 6 months ago when I had just finished working on a JDO based app running on Google App Engine. The module was inspired by the tapestry-jpa module at Tynamo. 

JDO as a standard is a curious beast. It was the first attempt at building solid ORM functionality for the Java platform, there were a bunch of solid implementations out there (Apache JDO, Kodo, etc); however, it somehow never managed to catch fire like Hibernate. For a while, at least for me, it felt like the standard was on its way out, giving way to JPA; yet, it keeps coming back: Google App Engine JDO support, MongoDB JDO API through DataNucleus, etc.  

Enjoy !

After grueling six months of development on Android, I'm back at the server side. I'll be cutting a new, T5.3 specific version of Tynamo's tapestry-security in the near future, though unfortunately it won't make it to Santa's sleigh. I'm hoping to also pick up Shiro 1.2 as a dependency if we get that finalized in time. If there's anything you really wanted to change or fix in tapestry-security but never got around reporting it, right about now would be a good time. All the currently open issues will be resolved as well. Thanks to all, it's been a great year for Tynamo as well as Tapestry!

Please join me in welcoming Alex Kotchnev, our newest Tynamo committer! What has almost become a tradition, a new committer brings a few gifts and so does Alex, namely a new Tapestry integration module for JDO2. We imported the new, aptly named tapestry-jdo module into our repository in no time and patted Alex on the back as a signal to start hacking! More to follow I'm sure. Hey Alex, where's that jdo release again I needed yesterday? Just kidding, no pressure

You've spoken and we aim to please! In tapestry-security 0.4.0 we did away with the shiro.ini and allowed configuring security Tapestry-style with all-in-Java contributions. The release finally combines all features from separate Shiro integrations (original tapestry-security by Kalle Korhonen) and tapestry-jsecurity (originally by Valentin Yerastov). We'll be adding a few signatures in minor revisions, but the interfaces are already stable and the release is fully integration tested against T5.2.5. Among other improvements are some performance enhancements: processing Shiro filter chains should be much quicker with 0.4.0. More information at tapestry-security guide.

Release notes:
Improvement
TYNAMO-67 - Allow contributing new security filters
New Feature
TYNAMO-76 - Re-write the built-in Shiro filters as Tapestry filters

Enjoy!
Tynamo Team

Here comes yet another beautiful little module called tapestry-routing.

In a nutshell, tapestry-routing allows you to provide your own custom mapping between Tapestry pages and URLs.

Did you ever wanted to change the order of the path params in an URL? now you can!

Let's say you have a page: pages.projects.Members which have 2 parameters in its activation context: (Long projectId, Long memberId) and you want the URL for that page to look like /projects/1/members/1 Just add the @At annotation to you page, like this:

That's it!
tapestry-routing Dispatcher will take care of recognizing incoming requests and dispatching the proper render request
tapestry-routing PageRenderLinkTransformer will do the rest of the work, it will transform every Link for a page render request formatting it according to your route rule.

We really need some feedback, so please give it a try:http://tynamo.org/tapestry-routing+guide

Enjoy!