Entries tagged "software"
Software, in terms of this blog, is articles involving released software
(as opposed to projects in development or techiques for developing).
Found 25 entries
tagged with "software", displaying most recent 5 entries.
Lucee on Jetty bundles the Jetty server with the Lucee CFML engine,
cleanly configured using the home/base functionality in Jetty 9, and extensively documented.
The main aim is to provide a Lucee package that is a simple unzip-and-run to get
started, whilst providing a fully functional and capable web server, and also
making it clear how everything works to allow it to be adapted as needed.
This first release is v0.5 because I don't consider it sufficiently complete yet
- it all works fine, but doesn't yet contain everything I feel it should - for
example, HTTPS has not been configured and documented, and whilst Jetty itself
does support HTTPS and there's nothing stopping anyone consulting the Jetty docs
and setting it up, this project is about reducing that work.
So for development use it's fine, if you don't need HTTPS or are willing to
configure it yourself, go ahead - otherwise I hope to get what I consider a
complete v1.0 ready as soon as time permits, but didn't want to delay releasing
what I've done so far.
Downloads are available from the Lucee on Jetty project page; there's a
documentation wiki at GitHub, and the template for building bundles in
the GitHub repo .
As ever, I welcome any feedback or questions you might have - please use the
Lucee is the best CFML engine.
Nine years ago I began a blog article with a similar claim, and set out to
explain why Railo was at that time the best CFML engine. Well the simplest proof
of Lucee taking the crown is that Lucee is a fork of Railo by its original
creator, Michael Offner.
The thing that made Railo great and that Lucee will be taking further is in
being a CFML engine written for developers. That is to say, with features added
through developers saying "I need feature X to do my job better" - and
specifically not via vague ideas decided on by product managers getting
feedback from non-technical clients who say "we need to do mobile" and then
having a bunch of disconnected non-programmers come up with a horrendously buggy
and useless mess called cfclient. Eugh!
Good programmers already know what tools they need to achieve certain tasks,
and if those tools don't exist or aren't good enough, they need the ability to
create/improve them - that is what Micha gave us with Railo, and Lucee promises
to take this further - to make it even easier for the developer community to
adapt it to their needs.
Bering a fork, Lucee continues the versioning from Railo, launching tonight with
Lucee 4.5 available already, and an excellent Lucee 5 just around the corner.
Why Not Railo?
Many will be wondering why fork Railo, instead of working on what was there, and
the best way to answer that is simply to refer to what Brad Wood has already
written on the Railo mailing list: https://groups.google.com/forum/#!msg/railo/B_1S3WzVPXY/hlIeZDE1u98J
To re-iterate the key points: this is the original Railo developer, taking the
Railo source code, and refreshing the project. Don't mistake for division what
is actually an inclusive evolution, and importantly: a sign of exciting things
With the next release, Lucee will bring incredible flexibility to CFML and JVM
developers through a couple of key technologies.
OSGi is a modular platform for the JVM which allows only
the necessary libraries to be loaded. So if, for example, you don't use
Hibernate, it doesn't get included and wont add any overhead. Railo was already
lightweight, and Lucee with OSGi will take this even further.
"Scripting for the Java Platform" is a standard for embedding different languages
on the JVM, and what this means is being able to use Lucee to write CFML in far
more places than before. A good example is Ant build scripts - doing certain
things with Ant can be awkward and convoluted and Lucee 5 will allow embedding
CFML which makes those same tasks trivial.
Together these bring some great opportunies, and this is only the beginning...
I've tried to avoid simply parrotting what others have already written, so to
get further details on Lucee's launch and future you should definitely check out
Mark Drew's blog post,
Adam Cameron's blog post,
the thread started by Igal on the Railo list,
and of course the official Lucee website: lucee.org.
The release candidate for the next version of QueryParam Scanner is
available on GitHub.
So what's changed?
Well it now runs on FW/1 rather than Fusebox, and the UI has a new
theme - the previous gold/beige is gone, and in its place is a theme based on a
"new" logo which I've actually had sitting around for several years. There's CSS
used that will require a modern browser - FF4 and IE9 both work, but no
guarantees for anything older.
Functionality-wise there's a couple of fixes: an error is now thrown when a
directory doesn't exist (previous behaviour was to return 0 matches in 0 files),
and the IDs returned in data structures are now content-based hashes (previously
they were ever-changing UUIDs). Oh, and the IDs are now displayed with the HTML
results, in preparation for future functionality that'll potentially use them.
A new experimental (i.e. buggy) feature has been added to seperate the query
code into SELECT/FROM/WHERE/etc parts, when returning data structures. This may
help with post-processing the data, but has known flaws so use with care.
(The existing ORDER BY functionality has also been marked as experimental to
similarly indicate that it's not perfect.)
There's a minor change in that relative paths are officially not supported -
the UI always stated absolute paths or mappings were required, but there was
ugly code in place to try and make relative paths work too - that code has been
removed. If you used relative paths before, you need to resolve them before
passing to qpscanner.
Changed: Switched to FW/1 and removed unnecessary files.
Changed: New logo and front-end UI.
Removed: Dropped unofficial relative path support.
Added: Experimental ability to separate query code into segments
Fixed: IDs now use content-based SHA hashes, not random UUIDs.
Fixed: Throw error when path does not exist, instead of zero results.
Supports: ColdFusion 9/10 and Railo 3.3/4.0/4.1
That's it for now. There are several new features planned to make qpscanner
faster, more flexible and more useful, but you'll have to wait for a future
release for those.
As ever, if you have any feedback, feature requests, or find any bugs, then
please go ahead and get in touch via the GitHub issue tracker.
Earlier this week I promoted the release candidate for 0.7.5 of QueryParam Scanner
to full release.
For anyone unaware, QueryParam Scanner is a simple tool for identifying
unparameterised variables in CFML queries (which may indicate a potential SQL
This version has a handful of bug fixes and code cleanups, resulting in faster
more accurate scanning than previous versions, plus the addition of JSON output
format, giving a more lightweight option if used in scripted processes.
For further details on these, see the previous RC article; other than
a couple of trivial fixes and a new readme, nothing has changed since that.
To download the latest version, you can either clone the git repo, or
grab it as a zip archive from the GitHub tags page.
For any feedback, problems, or questions, please use the issue tracker.
I have just pushed an update of QueryParam Scanner to GitHub, containing
This update is on the rc0.7.5 branch, and it'd be nice if people could
take it for a spin and make sure there are no issues with it. (There is a
zip download for anyone without git.)
The visible changes which you might notice are:
- Added JSON output format, giving an alternative to XML for anyone using
qpscanner in a scripted process.
- Added variable for number of potential risk files, and improved related
wording in HTML output.
- Fixed bug where identical queries were causing incorrect line numbers.
- Fixed bug where query names were not being detected.
- Fixed bug where blank lines were incorrectly removed.
However, there are also significant under-the-hood changes. I removed my
obsolete "Java Regex Utils" library (replacing it with the object part of
cfRegex), and made a number of little code clean-ups.
A result of these changes is that qpscanner rc0.7.5 appears to be almost twice
as fast as previous versions.
If you have any feedback, please feel free to contact me via GitHub,
and similarly if you find any bugs then please raise them on the issue tracker.