Planet Apache

Syndicate content
Updated: 1 day 11 hours ago

Bryan Pendleton: Rain! Actual rain!

Thu, 2014-09-25 09:57

OK, it was only for a few hours.

But it was actual rain!

Wow that felt good.

Categories: FLOSS Project Planets

Justin Mason: Links for 2014-09-24

Wed, 2014-09-24 18:58
Categories: FLOSS Project Planets

David E. Jones: Making Apps with Moqui - Book Now Available

Tue, 2014-09-23 23:56
My latest book is now available on Amazon.com:

http://www.amazon.com/Making-Apps-Moqui-Enterprise-Applications/dp/0692267050/

Making Apps with Moqui is the official documentation for Moqui Framework and includes a comprehensive summary of Mantle Business Artifacts. Starting with basic concepts and a tutorial to try things rights away, it builds to complete examples of end-to-end business processes including procure to pay, order to cash, and work plan to cash.


The framework topics cover data and service tier tools, user and system interfaces, security, and performance. With dozens of diagrams and screen shots, and thousands of lines of code and configuration examples, this book gives you ideas of what you can do with Moqui Framework and shows you how too. This includes things as simple as defining your data model with entities to more advanced things like building hierarchical data documents based on entity data and feeding them to other systems or indexing and searching the documents through simple configuration.


Learn how to easily build remote and local services that handle validation, security, transaction management, and much more. Build screens quickly with a wide variety of dynamic widgets and forms styled any way you wish, or even define your own widgets to use consistently across your applications. Handle large scale and milt-tenant systems. Track your application use and performance. Implicitly handle multiple languages, currencies and other localization details. Control access to resources across all tiers through flexible authc and authz configuration. 


Written by the founder of Moqui and Mantle, and an enterprise application architect with 15 years of open source and commercial experience, this book provides the most accurate and useful information available for building modern enterprise applications with some of the best open source tools and technologies.

NOTE: this book is also available for free download from http://www.moqui.org.

Categories: FLOSS Project Planets

Justin Mason: Links for 2014-09-23

Tue, 2014-09-23 18:58
  • Avoiding Chef-Suck with Auto Scaling Groups – forty9ten

    Some common problems which arise using Chef with ASGs in EC2, and how these guys avoided it — they stopped using Chef for service provisioning, and instead baked AMIs when a new version was released. ASGs using pre-baked AMIs definitely works well so this makes good sense IMO.

    (tags: infrastructure chef ops asg auto-scaling ec2 provisioning deployment)

  • Introducing Groups.io

    Mark “ONEList” Fletcher’s back, and he’s reinventing the email group! awesome.

    email groups (the modern version of mailing lists) have stagnated over the past decade. Yahoo Groups and Google Groups both exude the dank air of benign neglect. Google Groups hasn’t been updated in years, and some of Yahoo’s recent changes have actually made Yahoo Groups worse! And yet, millions of people put up with this uncertainty and neglect, because email groups are still one of the best ways to communicate with groups of people. And I have a plan to make them even better. So today I’m launching Groups.io in beta, to bring email groups into the 21st Century. At launch, we have many features that those other services don’t have, including: Integration with other services, including: Github, Google Hangouts, Dropbox, Instagram, Facebook Pages, and the ability to import Feeds into your groups. Businesses and organizations can have their own private groups on their own subdomain. Better archive organization, using hashtags. Many more email delivery options. The ability to mute threads or hashtags. Fully searchable archives, including searching within attachments. One other feature that Groups.io has that Yahoo and Google don’t, is a business model that’s not based on showing ads to you. Public groups are completely free on Groups.io. Private groups and organizations are very reasonably priced.

    (tags: email groups communication discussion mailing-lists groups.io yahoo google google-groups yahoo-groups)

Categories: FLOSS Project Planets

Heshan Suriyaarachchi: Jmeter plugins for Apache Jmeter

Tue, 2014-09-23 17:20
I came across Jmeter-plugins project today and tried it out. It has a nice set of addons to support/complement existing functionality of Jmeter.
Categories: FLOSS Project Planets

Piergiorgio Lucidi: My talk at the Alfresco Summit 2014 in London

Tue, 2014-09-23 08:53

During the next Alfresco Summit I'll be involved together with Russ Danner (Crafter Software) to talk about our case for an european bank.

Categories: FLOSS Project Planets

Justin Mason: Links for 2014-09-22

Mon, 2014-09-22 18:58
  • The Open Source Software Engagement Award

    SFU announces award for students who demonstrate excellence in contributing to an Open Source project

    (tags: sfu awards students open-source oss universities funding)

  • DublinDashboard

    ‘provides citizens, public sector workers and companies with real-time information, time-series indicator data, and interactive maps about all aspects of the city. It enables users to gain detailed, up to date intelligence about the city that aids everyday decision making and fosters evidence-informed analysis.’

    (tags: dublin dashboards maps geodata time-series open-data ireland)

  • mcrouter: A memcached protocol router for scaling memcached deployments

    New from Facebook engineering:

    Last year, at the Data@Scale event and at the USENIX Networked Systems Design and Implementation conference , we spoke about turning caches into distributed systems using software we developed called mcrouter (pronounced “mick-router”). Mcrouter is a memcached protocol router that is used at Facebook to handle all traffic to, from, and between thousands of cache servers across dozens of clusters distributed in our data centers around the world. It is proven at massive scale — at peak, mcrouter handles close to 5 billion requests per second. Mcrouter was also proven to work as a standalone binary in an Amazon Web Services setup when Instagram used it last year before fully transitioning to Facebook’s infrastructure. Today, we are excited to announce that we are releasing mcrouter’s code under an open-source BSD license. We believe it will help many sites scale more easily by leveraging Facebook’s knowledge about large-scale systems in an easy-to-understand and easy-to-deploy package. This is pretty crazy — basically turns a memcached cluster into a much more usable clustered-storage system, with features like shadowing production traffic, cold cache warmup, online reconfiguration, automatic failover, prefix-based routing, replicated pools, etc. Lots of good features.

    (tags: facebook scaling cache proxy memcache open-source clustering distcomp storage)

  • DIRECT MARKETING – A GENERAL GUIDE FOR DATA CONTROLLERS

    In particular:

    Where you have obtained contact details in the context of the sale of a product or service, you may only use these details for direct marketing by electronic mail if the following conditions are met: the product or service you are marketing is of a kind similar to that which you sold to the customer at the time you obtained their contact details At the time you collected the details, you gave the customer the opportunity to object, in an easy manner and without charge, to their use for marketing purposes Each time you send a marketing message, you give the customer the right to object to receipt of further messages The sale of the product or service occurred not more than twelve months prior to the sending of the electronic marketing communication or, where applicable, the contact details were used for the sending of an electronic marketing communication in that twelve month period.

    (tags: email spam regulations ireland law dpc marketing direct-marketing)

Categories: FLOSS Project Planets

James Duncan: CocoaConf Yosemite

Mon, 2014-09-22 17:00

A few months back, Dave Klein got in touch and said that he was putting together a very special conference for Cocoa developers in the heart of Yosemite National Park. Then, he asked if I’d like to give a talk at the conferences and maybe lead a photo walk. Of course, I said yes. How could I not? Maybe I’ll see you there?

via permalink
Categories: FLOSS Project Planets

Jim Jagielski: iOS 8

Mon, 2014-09-22 07:49

With all the buzz around iOS 8, I decided to take the plunge. I went ahead and upgraded an iPad2, iPad Mini and iPad Retina. I didn't upgrade any iPhones.


Why?


I'm not crazy! I need my iPhone to work! 


Anyway, so after several days of using iOS 8 on these devices, I can come up with a singular conclusion: It Is Dog Slow.


I mean really, frustratingly slow. Like I could use a stop-watch to time how long it takes apps to open (even those specifically upgraded for "iOS 8 compatibility" or to get back to the home screen when the Home button is pressed. Once in the apps, things are better, but no app at all feels peppier under iOS 8, except for maybe Safari.


Plus, a lot of apps, like Scribd, don't even open up and just die. 


Continue reading "iOS 8"
Categories: FLOSS Project Planets

Adrian Sutton: Software is sometimes done

Sun, 2014-09-21 19:26

In Software is sometimes done Rian van der Merwe makes the argument that we need more software that is “done”:

I do wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the design we come up with might not only be done at some point, but might be around for 100 years or more? Would we make it fit into the web environment better, give it a timeless aesthetic, and spend more time considering the consequences of our design decisions?

It’s an interesting question – if we had to get things right the first time, would we do a better job? If our design decisions were set in stone for all time would things be better?

The problem is, we’ve already asked this question and decided that in fact designing things up front and setting it in stone doesn’t work as well as releasing early and often with short feedback cycles so that we can adjust as we go. It’s waterfall vs agile and it turns out agile wins.

That said, there’s a difference between being rushing a sloppy job out the door and doing things well with an iterative cycle to adjust to learning.  An short feedback loop is there to let you learn and improve, not to let you release any old thing and get away with it. We need more software developed by doing the best job possible with the information available, combined with a short feedback cycle to gather more information and continually raise the stakes for what’s possible.

It can be romantic to look back and think that we used to do a better job because things were more permanent, that software used to be done, but it’s just not true:

When Windows 95 came out, it was done. Yes, there were some patches to it, but they were few and far between, and in general quite difficult to come by. But of course, then the Internet and App Stores happened in full force, and suddenly we decided that “Software is never done”. In some sense this is certainly true. There are always bugs to fix, things to improve, more features to add, unused features to remove — and of course, the SaaS model makes it all so easy. But I wonder if we’ve taken this a bit too far.

Windows 95 may have a been done, but Windows was not. Otherwise we’d still be running Windows 95. We’re kidding ourselves if we think that anyone at Microsoft ever thought that Windows 95 would be the last thing they ever released, that the OS would never change in the future.

Even if we consider Windows 95 as a standalone thing that is “done”, would you run it today? Of course not, by modern standards it’s horrible. The same is true of every other piece of unmaintained software I can think of, it may have been good enough or even the best for a long time after it became unmaintained but eventually it falls behind. Eventually it stops being “done” in the sense that it doesn’t need any further work and becomes “done” in the sense that no one uses it anymore.

 

Categories: FLOSS Project Planets

Adrian Sutton: Software is sometimes done

Sun, 2014-09-21 19:26

In Software is sometimes done Rian van der Merwe makes the argument that we need more software that is “done”:

I do wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the design we come up with might not only be done at some point, but might be around for 100 years or more? Would we make it fit into the web environment better, give it a timeless aesthetic, and spend more time considering the consequences of our design decisions?

It’s an interesting question – if we had to get things right the first time, would we do a better job? If our design decisions were set in stone for all time would things be better?

The problem is, we’ve already asked this question and decided that in fact designing things up front and setting it in stone doesn’t work as well as releasing early and often with short feedback cycles so that we can adjust as we go. It’s waterfall vs agile and it turns out agile wins.

That said, there’s a difference between being rushing a sloppy job out the door and doing things well with an iterative cycle to adjust to learning.  An short feedback loop is there to let you learn and improve, not to let you release any old thing and get away with it. We need more software developed by doing the best job possible with the information available, combined with a short feedback cycle to gather more information and continually raise the stakes for what’s possible.

It can be romantic to look back and think that we used to do a better job because things were more permanent, that software used to be done, but it’s just not true:

When Windows 95 came out, it was done. Yes, there were some patches to it, but they were few and far between, and in general quite difficult to come by. But of course, then the Internet and App Stores happened in full force, and suddenly we decided that “Software is never done”. In some sense this is certainly true. There are always bugs to fix, things to improve, more features to add, unused features to remove — and of course, the SaaS model makes it all so easy. But I wonder if we’ve taken this a bit too far.

Windows 95 may have a been done, but Windows was not. Otherwise we’d still be running Windows 95. We’re kidding ourselves if we think that anyone at Microsoft ever thought that Windows 95 would be the last thing they ever released, that the OS would never change in the future.

Even if we consider Windows 95 as a standalone thing that is “done”, would you run it today? Of course not, by modern standards it’s horrible. The same is true of every other piece of unmaintained software I can think of, it may have been good enough or even the best for a long time after it became unmaintained but eventually it falls behind. Eventually it stops being “done” in the sense that it doesn’t need any further work and becomes “done” in the sense that no one uses it anymore.

 

Categories: FLOSS Project Planets

Adrian Sutton: CI Isn’t a To-do List

Sun, 2014-09-21 18:59

When you have automated testing setup with a big display board to provide clear feedback, it’s tempting to try and use it for things it wasn’t intended for. One example of that is as a kind of reminder system – you identify a problem somewhere that can’t be addressed immediately but needs to be handled at some point in the future. It’s tempting to add a test that begins failing after a certain date (or the inverse, whitelisting errors until a certain date). Now the build is green and there’s no risk of you forgetting to address the problem because it will fail again in the future. Perfect right?

The problem is that it sacrifices the ability to easily isolate the cause of a failure. You can no longer revert changes to get back to a working baseline because the current time is a factor in whether your tests pass or not. You can no longer run historical builds through CI which you may need to do as part of supporting clients on older versions.

It also inevitably leads to false failures as the time points are almost always arbitrary and estimated time lines for completing tasks often slip. So the board goes red and the response is to just suppress it again.

Continuous integration isn’t there to remind you to do something – it’s there to tell you if your build is ok to ship to production or not. It doesn’t make sense to say that a build is ok to ship to production now but not ok to ship in a week’s time. If production is going to blow up in the future because of a bug in the code you want to the board to be red now, not when production actually blows up. And if the client is prepared to accept the risk and leave the problem unfixed then it’s not yet a requirement and doesn’t need tests asserting it – just put a card in the backlog for the client to prioritise and play when required.

If you need to remember to do something, either put a task in the backlog or on the current story board to do it or put a reminder in your calendar. Keep CI focussed on telling you about the state of your code right now – if it’s broken it should be red, if it’s not broken it should be green. Not broken until next week should never be an option.

 

Categories: FLOSS Project Planets

Justin Mason: Links for 2014-09-21

Sun, 2014-09-21 18:58
Categories: FLOSS Project Planets

James Duncan: Moonlight video shot with A7s

Sun, 2014-09-21 17:00

How good is the Sony A7s with low light levels? How dark can you go? Carbon Studios was able to make this short by moonlight between the hours of midnight and 2AM. Crazy impressive.

via Petapixel via permalink
Categories: FLOSS Project Planets

Bryan Pendleton: What I'm reading, autumnal equinox edition

Sun, 2014-09-21 12:33

Confucius says: he who attends all-week company conference while battling nasty head cold sleeps 10 hours / night over next weekend.

At any rate, I'm feeling somewhat better now, and am back to surfing the nets.

  • Guide: Writing Testable CodeTo keep our code at Google in the best possible shape we provided our software engineers with these constant reminders. Now, we are happy to share them with the world.
  • Why DO Computers Fail?The obvious question when reading a text this old is just how relevant the information is for the world of computing today. I see no reason to think that the fundamental principles have changed, even though all numbers in the report are way off compared to current technology. For example, in a description of a restart scenario, he cites a time of about 90 minutes from start to a live system. Today, most systems would come up much faster than that. The nature of networking has changed dramatically from 1985 in terms of speed and latencies and robustness. Even so, it is still true that communications links are normally the weakest link in any distributed system.
  • High Performance SSH/SCP - HPN-SSHSCP and the underlying SSH2 protocol implementation in OpenSSH is network performance limited by statically defined internal flow control buffers. These buffers often end up acting as a bottleneck for network throughput of SCP, especially on long and high bandwith network links. Modifying the ssh code to allow the buffers to be defined at run time eliminates this bottleneck. We have created a patch that will remove the bottlenecks in OpenSSH and is fully interoperable with other servers and clients. In addition HPN clients will be able to download faster from non HPN servers, and HPN servers will be able to receive uploads faster from non HPN clients. However, the host receiving the data must have a properly tuned TCP/IP stack. Please refer to this tuning page for more information.
  • Memory Management ReferenceThis is a resource for programmers and computer scientists interested in memory management and garbage collection.
  • Resource management in DockerDocker uses cgroups to group processes running in the container. This allows you to manage the resources of a group of processes, which is very valuable, as you can imagine.
  • What is linux-gate.so.1?From time to time this is a cause of befuddlement and frustration for users as they go searching for a non-existent system file. You can confidently tell users on this futile quest that there's not supposed to be a linux-gate.so.1 file present anywhere on the file system; it's a virtual DSO, a shared object exposed by the kernel at a fixed address in every process' memory
  • I’m leaving MojangI was at home with a bad cold a couple of weeks ago when the internet exploded with hate against me over some kind of EULA situation that I had nothing to do with. I was confused. I didn’t understand. I tweeted this in frustration. Later on, I watched the This is Phil Fish video on YouTube and started to realize I didn’t have the connection to my fans I thought I had. I’ve become a symbol. I don’t want to be a symbol, responsible for something huge that I don’t understand, that I don’t want to work on, that keeps coming back to me. I’m not an entrepreneur. I’m not a CEO. I’m a nerdy computer programmer who likes to have opinions on Twitter.
  • Why Free Marketeers Want To Regulate the Internet it seems odd for a conservative – whether an old-guard big-business Bush-era conservative or a new-guard Paulite libertarian conservative – to support Net Neutrality.

    Except I do Internet for a living, and I am one of the lucky ones who actually knows what Net Neutrality means and what it’s responding to. And, folks, I’m afraid that, while L. Gordon Crovitz and Rich Lowry are great pundits with a clear understanding of how Washington and the economy work, they don’t seem to understand how the Internet works, which has led them to some wrong conclusions.

  • Eleventh Grade Tech TrendsSo while the anecdotes of a sixteen year old, public high school student, from Los Angeles are not representative, and will not help you find the next Facebook, I do think the practice of pausing, asking questions, and listening to other people is a good one that should be practiced much more.
  • How Gangs Took Over PrisonsThis past summer, however, a 32-year-old academic named David Skarbek published The Social Order of the Underworld, his first book, which is the best attempt in a long while to explain the intricate organizational systems that make the gangs so formidable. His focus is the California prison system, which houses the second-largest inmate population in the country
  • Here Comes HabitatThe MADE, a few months ago, quietly began working on reviving the game Habitat for preservation. The period we have thus far completed has mostly been focused on gathering human resources, hardware resources, and assessing the extent to which we can preserve the first Massively Multiplayer game. At this point, we are ready to announce that we feel we have a very good chance of bringing Habitat online, in its original form, for play online with Commodore 64 emulators as the client.
  • iOS 8, thoroughly reviewedIn this review, we'll be talking mostly about features available to all iOS 8 devices, and to hardware that you already have in your hands right now. Several software features in the new operating system are exclusive to the new iPhone 6 and iPhone 6 Plus, and discussion of those features will wait until we review those devices.
  • What every computer programmer should know about floating point, part 1There is an existing article called What Every Computer Scientist Should Know About Floating-Point Arithmetic, but it is very math-heavy and focuses on subtle issues that face data scientists and CPU designers. This article ("What every computer programmer should know...) is aimed at the general population of programmers. I'm focusing on simple and practical results that you can use to build your intuition for how to think about floating-point numbers.
  • Dread Pirate Sunk By Leaky CAPTCHAThe IP address leak we discovered came from the Silk Road user login interface. Upon examining the individual packets of data being sent back from the website, we noticed that the headers of some of the packets reflected a certain IP address not associated with any known Tor node as the source of the packets. This IP address (the “Subject IP Address”) was the only non-Tor source IP address reflected in the traffic we examined
  • NOAA team reveals forgotten ghost ships off Golden GateA team of NOAA researchers today confirmed the discovery just outside San Francisco’s Golden Gate strait of the 1910 shipwreck SS Selja and an unidentified early steam tugboat wreck tagged the “mystery wreck.” The researchers also located the 1863 wreck of the clipper ship Noonday, currently obscured by mud and silt on the ocean floor.

    These and other shipwreck investigations mark the first mission of a two-year project to locate, identify and better understand some of the estimated 300 wrecks in Gulf of the Farallones National Marine Sanctuary, and the adjacent Golden Gate National Recreation Area.

Oh, and yes, the rumors are true: I now use an iPhone.

Categories: FLOSS Project Planets

Matt Raible: Rafting the Green River through Desolation Canyon

Sun, 2014-09-21 11:48

After rafting the Yampa in June, we knew we'd experienced a once-in-a-lifetime kinda trip. We never expected to have two in one summer. When we got an invite to raft Desolation Canyon over Labor Day weekend, we jumped at the opportunity.

The trip started on Jack's birthday: Thursday, August 28th. We drove from Denver to Green River, Utah the night before, and had some adventures along the way. As we were heading down Vail Pass, our trailer started to swing from side to side, almost whiplashing us off the road. We quickly slowed down and didn't go over 65 MPH for the rest of the trip. I figured this was caused by the rear spring spacers we added to the Syncro. The heightened rear caused the raft trailer to be out of balance, and we needed a new hitch to drop it down.

We arrived around 1:30am, popped the top on our camper and went to sleep. The next morning, we woke up and met some of our fellow floaters for the first time. An hour later, were were getting ready to leave and I was inspecting our trailer. That's when I noticed one of the wheels was about to fall off. The bearings were shot and the wheel was barely hanging on.

Luckily, one of the guys we just met had replaced all his trailer's bearings the week before and was on it. He knew exactly what to do and went to work. There was a Napa Auto Parts store a mile away. Two hours and several trips to Napa later, we were back in business and on the road.

We celebrated Jack's 10th birthday while driving to the put in, opening presents and having a good ol' time. We also had some cupcakes to celebrate with everyone once we arrived. Jack was especially pumped for the huckleberries my Mom overnighted.

We launched with five families total, 10 adults and 10 kids. We had five rafts, a duckey, an inner tube and two motors to get us through the flat water. We didn't get on the river until 6pm that first day, and only made it seven miles before dark.

The water was muddy and we made jokes that it should be called the Brown River instead of the Green River. On the upside, it was warm and the kids had a blast frolicking in it. We got to know our travel companions and were happy we purchased a new motor to combat the winds and flatness. Yes, there were many references to motoring as we cruised down the river.

The rest of the week was fairly uneventful. After the first two days, we didn't use the motors much, and there were quite a few rapids. However, there were no Class IVs and the kids only walked for one Class III. The kids seemed to have a great time, inventing new games every night and exploring for hours at every new campsite. My favorite game was the Werewolves vs. the Angry Mob.

The petroglyphs we saw along the way were pretty cool.

Time spent on a river always brings out a few good smiles.

And dress up as a superhero night was simply awesome.

Trish's photo from our last night on the river makes me want do it all again.

2014 will go down in the books as one of our best rafting years. We only made it on the river a few times, but the week-long trips were amazing. Rafting the Arkansas with our Dads was really fun too. I'm proud to be raising river rats and long for the days I can live in our van down by the river.

Categories: FLOSS Project Planets

Justin Mason: Links for 2014-09-19

Fri, 2014-09-19 18:58
Categories: FLOSS Project Planets

Nick Kew: Faintheart

Fri, 2014-09-19 07:13

Wee, sleekit, cow’rin, tim’rous beastie,
O, what a panic’s in thy breastie!

What a letdown, Jock.  Your poet must be spinning in his grave.


Categories: FLOSS Project Planets

Claus Ibsen: 66th Apache Camel release is out - its the 2.14 release

Fri, 2014-09-19 02:26
Today Apache Camel 2.14.0 hit the streets. Its our 66th release (include all patch releases) since the project was created over 7 years ago.

There is a bunch of great stuff in this release, so let me try to distill a list of 10 highlights (in no particular order)


1) Java 8 support
The 2.14.x branch marks the 1st release where we officially support Java 8. We made sure the code compiles and all tests passes on Java 8 also. We also support Java 7.

Now you may ask about all the coolness from Java 8 about lambda's and whatnot. Yeah we are looking into that for the next release to provide examples and a first cut of a Java 8 based DSL.


2) Spring 4 support
The same goes here. We now support Spring 4.x also. There is one migration effort, as Spring 3.x and 4.x is not compatible when using spring testing. So we had to introduce a camel-test-spring3 module for Spring 3.x users, and camel-test-spring is for 4.x users. Also there is a known issue in camel-test-spring about Spring 4.1.x support which we will fix in the next patch release.


3) Rest DSL
This is likely one of the most exciting new features in this release. We now offer a REST styled DSL which can be used with Java or XML. The intention is to allow end users to define REST services using a REST style with verbs such as get, post, delete etc.

Here is a small taste of it in action:

rest("/customers/")    .get("/{id}").to("direct:customerDetail")    .get("/{id}/orders").to("direct:customerOrders")    .post("/neworder").to("direct:customerNewOrder");
The DSL can be used in both Java and XML. As this is the 1st release with the Rest DSL we will of course continue to improve on this, and certainly based on the feedback from the community.


4) Netty 4.x support
We now have support for both Netty 3.x and 4.x. As we take backwards compatibility seriously we decided to leave camel-netty as-is for Netty 3.x users, and port the code to a new camel-netty4 for Netty 4.x users. The same goes for the camel-netty-http and camel-netty-http4 modules.


5) API component
Dhiraj Bodke worked on a great new API component support in camel-core, that makes creating new Camel components for APIs much easier and faster. We use this to integrated with new components such as box, linkedin, google-drive, and salesforce and what else comes in the future. He wrote a great blog about this component and how to use it. So expect many more of these API components in upcoming releases.


6) More JMX MBeans
We now also enlist producers in JMX, and as well have a registry to capture runtime usage of endpoints, which allows you to "see" which endpoints are in use, and as well how endpoints may be shared across routes, e.g. sending to queue A in route 1 and consume from queue A in route 2. All based on dynamic usage such as dynamic patterns like the recipient list.

The aim is to provide better understand how your Camel routes are being used at runtime. We will continue to improve tooling in this area such as hawtio, and the Camel Karaf commands, etc.


7) Codahale metrics
And continued from #6 we also have a new camel-metrics component to integrate with the excellent codahale metrics library. On top of that we also allow to use this to capture Camel routing statistics using codehale. This can then be used with existing codahale tooling and also with hawtio. I wrote a blog about this earlier.

The screenshot below illustrates routing information captured by camel-metrics and displayed by hawtio in the new route metrics tab which supports codahale.

camel-metrics used to capture routing statics which can be displayed in hawtio using the new route metrics tab.

8) Circuit breaker EIP
We introduce a new EIP using the circuit breaker pattern.


9) Swagger integration
We have a new camel-swagger module that in combination with the Rest DSL allows to expose an API documentation of your REST services. This can then be used with existing swagger tooling and web consoles. For example hawtio has a swagger console out of the box, such as shown below

Camel example using the new Rest DSL which offers swagger API documentation, which can be viewed using a swagger console such as offered by hawtio

10) And the usual stuff
We added 15 new components, 1 new EIP, 1 new data format, and 1 new language. And as usual a bunch of bug fixes, improvements and hardening.  And we dropped support for Java 6.


If you want to see some of the new stuff in action, then you can try the new examples. We have the camel-example-servlet-rest-tomcat. This is a plain WAR file which you can run in Apache Tomcat, Jetty, Wildfly, fabric8 or any other web container. Then you can see both the new Rest DSL, Swagger and codehale metrics in action, all in the same application. And for hawtness then try deployed hawtio as well and see what it can do as well.

The same example is also available for Karaf users by the camel-example-servlet-rest-blueprint.



You can find more details about this release in the 2.14 release notes. And if you are upgrading from a previous release, then make sure to read about the changes that may effect you.

You can get this release from Maven Central and download from the Apache Camel website.

Categories: FLOSS Project Planets

Justin Mason: Links for 2014-09-18

Thu, 2014-09-18 18:58
  • 75% of domestic violence victims in US shelters were spied on by their abusers using spyware

    via Mikko

  • Alex Payne — Thoughts On Five Years of Emerging Languages

    One could read the success of Go as an indictment of contemporary PLT, but I prefer to see it as a reminder of just how much language tooling matters. Perhaps even more critical, Go’s lean syntax, selective semantics, and cautiously-chosen feature set demonstrate the importance of a strong editorial voice in a language’s design and evolution. Having co-authored a book on Scala, it’s been painful to see systems programmers in my community express frustration with the ambitious hybrid language. I’ve watched them abandon ship and swim back to the familiar shores of Java, or alternately into the uncharted waters of Clojure, Go, and Rust. A pity, but not entirely surprising if we’re being honest with ourselves. Unlike Go, Scala has struggled with tooling from its inception. More than that, Scala has had a growing editorial problem. Every shop I know that’s been successful with Scala has limited itself to some subset of the language. Meanwhile, in pursuit of enterprise developers, its surface area has expanded in seemingly every direction. The folks behind Scala have, thankfully, taken notice: upcoming releases are promised to focus on simplicity, clarity, and better tooling.

    (tags: scala go coding languages)

Categories: FLOSS Project Planets