jxpfw changelog
This changelog replaces the old docs\project\changelog.xml file.

Release 3.2.5
This release is all about changes made to the tag library.
The general idea is to create smaller byte code.
Some technical changes were made to achieve this.
Some tags for example now implement the BodyTag interface but
skip the body. This turned out to create smaller byte code.

We also noted that when you extract a form into a separate JSP page,
it is advantageous to be able to drop the jxpfw:bean tag.
Normally you are not able to do so since a jxpfw:form tag needs to be nested
within a jxpfw:bean tag. To prevent this problem the jxpfw:form tag now
supports a beanName attribute. When this attribute is used, the jxpfw:bean tag
can be dropped.

The last major change regards the getBeanTag() method. It has been replaced
with a method named getBean(), that directly returns the AbstractJSPBean.

Release 3.2.4
org.jxpfw.jsp.AbstractJSPBean
The org.jxpfw.locale cookie is now httponly.
So, this cookie can't be handled by javascript.

Release 3.2.3
This release is mostly about changing site information and solving check style
problems.

Release 3.2.2

org.jxpfw.jsp.tag.form.FormaTag
The generated preventDoubleSubmit(...) method compared a submitCount that could
be NaN.
This caused pages to freeze since clicking whatever button caused detection of
a double submit even though the page was not actually submitted twice.

pom.xml
Removed the weblogic-full-client dependency as it is not generally available.
As a result WebLogicUtil had to be changed which should not be a problem as it
is hardly used and josef has a better alternative.

org.jxpfw.jsp.AbstractJSPBean
org.jxpfw.jsp.tag.form.FormTag
Changed the csrf token from an Integer to an array of 32 bytes.
This should be more secure.
The implementation depends upon the SecureRandom class.
When SecureRandom does not support the correct algorithm, a fall-back scenario
is used that uses Integers as before with the difference that they are internally
represented as Strings.

org.jxpfw.util.AbstractLocalizedConstants
org.jxpfw.util.LocalizedConstant
Are now type safe.
The latter file now contains an equals and hashCode method. 

org.jxpfw.jsp.AbstractJSPBean
When finding a bean, the current request and session are set on the found bean.
Previously the request was set and the session was fetched from this request.
On numerous occasions this resulted in a NullPointerException from within the
initSession method.
This fix should prevent this from happening.
It is unclear if the problem is caused by WebLogic and that they should fix it.
Either way this fix makes the code safer than it was before and it should not
be removed, even after WebLogic patches the problem.

org.jxpfw.jsp.tag.format.SplitPageTag
When a request parameter named "popup" is present, it is passed on when a page
link is clicked.
This should prevent you from getting the message:
"Session already active", when using the SplitPageTag in a popup window.  


Release 3.2.1

Upgraded to Log4J/2

Release 3.2.0

This trunk release was created to switch to j2ee7 and jdk 1.8.
A branch named j2ee6 has been created to continue working with j2ee7.

AbstractJSPBean
The findBean(...) method now repeats the find 10 times before bailing out.
This should solve issues in pages using frames where one bean is loaded before
the other.
A new method findBeanNoWait(...) with the old behavior has been added.
Use this latter method if you are simply testing a bean for its presence for
example.

SelectTag now has an extra attribute, applicable to mandatory fields.
It is named "forceSelection" and adds an extra option at the top of the list.
Browsers select the first option by default, so this is the option that is
submitted when the user does not change the selection.
Your setter should check for this option being committed and respond with a
property exception.
The text of the option that is added can be overwritten by appending
"ForceSelection" to the name of your property. See SelectTag for details.

Without this attribute the first option is submitted without the user having
actively selected this first option.

org.jxpfw.jsp.tag.format.ResourceBundleLabelTag
A new tag that is a combination of a ResourceBundle- and Label tag.
Use this tag when in places where you can't use the standard Label tag.
For example when you have a column of mandatory input items and you only have
a single label in the top row. Since you can't use a PropertyTag here, use the
ResourceBundleLabelTag instead.
Simple usage:
<jxpfw:labelb key="resourceBundleKey" mandatory="true"/>
This would render the following html:
<span class="label mandatory">Label text</span>

org.jxpfw.jsp.tag.form.TextTag
Now supports the autocomplete attribute.

org.jxpfw.jsp.tag.form.AbstractInputTag
The style attribute (representing the html class attribute) is now respected.
This influences all 

org.jxpfw.jsp.AbstractJSPBean
Corrected an error in the addPropertyException methods.
The error caused exceptions to always appear at the top of the page instead of
behind the field.

org.jxpfw.jsp.tag.form.LabelTag
The html attribute was added at an incorrect place (just after the text).
It is now added just before the closing > of the span.

org.jxpfw.jsp.tag.form.SelectTag
The changes made to the SelectTag, described below are rolled back.
When the user did not make a selection and submits the page, no setter was
called. This causes validation to fail. In the previous version, a setter was
called (with the value of the first select item).
So to make a long story short: it broke backwards compatibility.
A version of this code has bean stored so when after code using jxpfw has been
changed, we can move to this version of the SelectTag. 

org.jxpfw.jsp.tag.form.SelectTag
In a previous release (3.1.10) the SelectTag was enhanced with a guard against
missing values in the backing collection. This only worked for combo boxes when
they were read-only.
This release brings a more generic solution.
When the user has not made a selection yet, the user is hinted to make a
selection. technically I chose to add a disabled option that is the selected
option. This way the user sees the hint at the top of the select, but the user
can't select it (since it is disabled) and it won't be submitted!
The same option is also shown when the backing bean does contain a non-null
value but that value does not appear in the backing collection.
Multiple selects where all values are missing from the backing collection, will
also show the same hint.
It doesn't matter anymore whether the SelectTag is read-only or not.
Naturally it should not happen that a backing value is not present in the
backing collection but at least jxpfw will properly guard against this error
now.
To change the standard text that appears add "Select" to the name of your
property as a key to the resource bundle.


Release 3.1.12

org.jxpfw.jsp.AbstractJSPBean
A redirect does not use the encoding of the request anymore.
Instead it uses UTF-8 as this is a W3C recommendation.

org.jxpfw.jsp.JSPUtil
The encodeUrl method now only takes a single parameter.
Previously it would also accept an encoding but the W3C recommends using UTF-8.

org.jxpfw.jsp.QueryString
Now properly encodes the query string parameters (both name and values).
Added a encodeUrl method to encode Query string parameters.
Removed the toString method that accepted an encoding.


Release 3.1.11

org.jxpfw.ejb.ObjectIDDispenser
Has been removed form jxpfw. Use org.josef.jpa.ObjectIdDispenser instead.

org.jxpfw.ejb.SequentialIDGenerator
Has been removed form jxpfw. Use org.josef.jpa.SequentialIdGenerator instead.

org.jxpfw.ejb.SequentialIDGeneratorException
Has been removed form jxpfw. Use org.josef.jpa.SequentialIdGeneratorException
instead.

Release 3.1.10

org.jxpfw.jsp.tag.form.SelectTag
Now guards against a combo box having a value that is not present in the
underlying collection. When this happens and the combo box is readonly and
mandatory, the optional option is added to the beginning of the list.
This fix was originally part of 3.1.9 but has been reverted.

Release 3.1.9

org.jxpfw.ejb.SequenceVO
Was moved to a test package in Josef.

Release 3.1.8

org.jxpfw.dmc.CodeDescriptionCallback
org.jxpfw.dmc.Column
org.jxpfw.dmc.ConstraintType
org.jxpfw.dmc.ConstraintVO (moved to Constraint)
org.jxpfw.dmc.Database
org.jxpfw.dmc.JDBCTypes (Josef CType)
org.jxpfw.dmc.NoSingleRowResultSetException
org.jxpfw.dmc.OracleDatabase
org.jxpfw.dmc.ResultSetRow
org.jxpfw.dmc.ResultSetRowCallBackInterface
org.jxpfw.dmc.ResultSetRowInterface
org.jxpfw.dmc.SqlParameter (Josef StoredProcedureParameter)
org.jxpfw.dmc.SqlParameterType (Josef StoredProcedureParameterType)
org.jxpfw.dmc.Table

Moved these classes from jxpfw to Josef (unless they were already present in Josef).

ogr.jxpfw.dmc.DMCUtil
Has been replaced with Josef's SqlStatementUtil or JdbcUtil. 
 
Release 3.1.7

org.jxpfw.jsp.tag.form.AbstractInputTag
Now creates the proper class attribute. For an input of type text that is
numeric and readonly for example, the following class attribute is created:
"text numeric readonly". To be backwards compatible, the old class attribute, that
consists of a single class name is also added. The actual result for the
example pictured above would thus be: "inputTextReadonlyNumeric".
Note: The inputTextNormal is "translated" to "text" and not to "text normal"
since normal is the norm and can be styled by selecting "text"anyway.
This is in line with the way the class attribute is generated for labels. 

org.jxpfw.jps.AbstractJSPBean
Now removes a key from the session before it is added.
We experienced a problem where putting a key in the session, did not actually
store the new key. By removing the key first we assure that the new key is
stored.

Release 3.1.6

org.jxpfw.util.Version
Dropped this class since the target jar contains the pom.xml file which in turn
contains the version information.

org.jxpfw.util.AbstractComparator
Dropped all the compare.... methods in favor of the generic compare method in
CComparator of Josef.

Release 3.1.5

org.jxpfw.util.Message
Moved Message to Josef.

org.jxpfw.util.CArguments
org.jxpfw.util.ArgumentsHandler
Moved to Josef.

Release 3.1.4

org.jxpfw.util.CodeDescriptionComparartor
Removed this class. In a previous version all references were already dropped.
Now this class has been removed entirely.
As a substitute use CodeDescription's static methods to create a comparator. 

Release 3.1.3

org.jxpfw.util.Message
The constructor with 4 parameters called the getMessage method on the
CResourceBundle, incorrectly. This caused incorrect message substitution. 

CodeDescriptionComparator
Removed all references to this class, except for the CodeDescriptionComparator
itself. In a (near) future release, this class will be dropped in favor of the
MultiFieldComparator.

This release was created to be compatible with the 3.0.25 version of Josef.
Particularly changes to CResourceBundle.

Removed org.jxpfw.util.CResourceBundle.

Release 3.1.2
Removed org.jxpfw.util.CDebug.
Removed org.jxpfw.util.UniqueLongGenerator.

Release 3.1.0/3.1.1
This release is about removing the Formatter class in favor of Josef's
Formatter. This caused other changes as well. The Formatter in Josef for
example throws its own InvalidArgumentException so I decided to remove
InvalidArgumentException and InvalidStateException as well.
Here is the complete list of files that were dropped:
org.jxpfw.util.Formatter
Formatter...properties
org.jxpfw.util.InvalidArgumentException
org.jxpfw.util.InvalidStateException
org.jxpfw.util.AbstractLocalizedException
org.jxpfw.util.AbstractLocalizedRuntimeException

org.jxpfw.jsp.AbstractJSPBean
Fixed the null content type problem reported by Sander.

Release 3.0.22
org.jxpfw.jsp.AbstractJSPBean
Now handles an existing cookie with an empty value.
Previously this resulted in a NPE.

Release 3.0.21

The 3.0.21 release is a security update.
Maarten implemented a file upload that guards against a csrf attack.
We know now that this version contains an error (null content type) that makes
this version unusable.
You have to switch to at least 3.1.0-SNAPSHOT for a fix.

org.jxpfw.jsp.tag.form.FormTag
The form tag now supports an enctype attribute.
This attribute should only be used for file uploads and should then be:
multipart/form-data
So if you are using javascript to change the enctype attribute or using the
html='enctype="multipart/form-data"' construction, you should change this.
 
Release 3.0.20

org.jxpfw.dmcDMCUtil

Added an encode method that should encode values to prevent SQL injection.

This method is used throughout to escape String values.
Some methods are inherently unsafe and this has been documented.
Particularly the creation of where clauses.
The rule of thumb is: USe SQL binding instead of dynamically created SQL
statements.

org.jxpfw.util.Formatter
Added parseDateTime method that accepts a custom pattern.

org.jxpfw.util.AbstractLocalizedConstants
Now implements Localizable.
This should make it easier to drop common classes from jxpfw in favor of Josef.
In the process the version of Josef has changed to support the new
(to jxpfw at least) Localizable interface.

Release 3.0.19
TreeTag now properly encodes its output.

Release 3.0.18
Using the time zone offset was a flaw as it does not take daylight savings time
into account. Letting the browser determine the time zone instead of the offset
should solve this problem.

Release 3.0.17

This release is all about time zones!!!!

org.jxpfw.jsp.AbstractJSPBean
Now supports a time zone.
You can get the time zone by: getTimeZone().
To set the time zone you should have a cookie named timeZoneOffset containing
the raw time zone offset to GMT+00:00.
To get the offset from within a browser and set it as a cookie, use the
following example:

When present, jxpfw will pick up the cookie and create a time zone from the
offset value. An offset of -60 will be converted to the time zone GMT+01:00. 

org.jxpfw.util.Formatter
Formatting and parsing Dates which include time info, now always uses a time
zone. When not explicitly set using setTimeZone(), the default time zone is
used.
Note that for formatting and parsing simple dates, no time zone is used
explicitly.

Corrected an error in the formatDateTime method that accepts a pattern.
It now actually uses the pattern and uses the time zone.

Release 3.0.16
org.jxpfw.jsp.tag.*
Verified output of jxpfw tags using the W3C Validator.
The csrf field for example was incorrectly generated with a close element.
Script tags incorrectly used language instead of type="text/javascript".
The general idea is that unless you are using checkbox arrays in your page or
textareas, jxpfw does NOT output invalid html.
 

Release 3.0.15

Release 3.0.14
org.jxpfw.jsp.AbstractJSPBean
Getting the session from a request object resulted in spurious NullPointer-
Exceptions. This exception is now caught and a warning message is logged.
So instead of a stacktrace, process flow simply continues, solving problems
in cases where the session is not accessed from the current request.
When the session is accesed however a stacktrace will still occur.

Release 3.0.13
No major changes were made in this release.

Release 3.0.12
org.jxpfw.jsp.tag.form.FormTag
The hidden field used to guard against a csrf attack is moved from the end of
the form to the beginning of the form. Reportedly, users could submit the form
without the hidden field being rendered.

Release 3.0.11
org.jxpfw.jsp.AbstractJSPBean
When under a csrf attack the returned status is 401 instead of 403.
Previously an application server would detect the 403 and redirect to the login page.

Release 3.0.10
org.jxpfw.jsp.AbstractJSPBean
Solved the problem where a multi-part request (file upload) caused a CSRF attack message.

Release 3.0.9
Not to be used.

Release 3.0.8
org.jxpfw.jsp.AbstractJSPBean
Corrected the error that processEveryPass() was never called!

Release 3.0.7
org.jxpfw.util.Formatter_en_GB.properties was added to support UK date
formatting.

org.jxpfw.jsp.AbstractJSPBean
org.jxpfw.jsp.tag.form.FormTag
Guarded against CSRF (Cross Site Request Forgery) attacks.
An illegal request will result in HTTP status 403 (FORBIDDEN).

Release 3.0.6

Maven
Switched to newer version of the compiler plugin.
Switched from WebLogic 10.3 to WebLogic 12c.

Tag library
All html tags now support a runtime expression for the id attribute.

Release 3.0.5

org.jxpfw.jsp.tag.GenericExceptionsTag
Messages are now quoted where appropriate.
This solves some security issues as discovered by executing penetration tests.


Release 3.0.4

org.jxpfw.jsp.tag.form.AbstractInputTag
When an input tag used a value attribute, it was not encoded, as
discovered by penetration tests. The input tags without a value attribute,
which is normally the case, were save.

org.jxpfw.util.Formatter
Now supports time zones.
When a time zone is set on the formatter, this time zone will automatically be
used to parse/format Dates/DateTimes.

org.jxpfw.jsp.tag.GenericExceptionsTag
Now properly handles quotes in a stack trace. Previously clicking the error
image would not show a stack trace when the trace contained quotes.


Release 3.0.3

org.jxpfw.jsp.tag.form.LabelTag
Now supports tooltips. Just add Tooltip to the name of your property as the key
in the resource bundle.

Release 3.0.2

org.jxpfw.jsp.tag.form.SelectTag
The select tag did not take a value attribute into account. The value
attribute wasn't actually even supported, but could be specified since its
super class accepted the value attribute. This has been changed so the value
attribute is actively supported. It has been tested with single select items
only. Indexed properties might work but a multiple select item will certainly
fail. Now the value attribute is actively supported, you can have a property
without a getter/setter as requested by Kees de Waard. 

org.jxpfw.jsp.*
Lots of test files have been moved from this project to jxpfw-demo-web.

Release 3.0.1
in org.jxpfw.jsp.AbstractJSPBean, the call to setRequest, now gets the session
and stores a reference to this session. This reference is returned when you
execute getSession(). This prevents initSession NullPointerExceptions from
occurring.

Release 3.0.0

This is the first official release of jxpfw that uses JDK 1.7 and J2EE6.
This release was made to work in conjunction with a J2EE6 container like
WebLogic 12. In general an Http request is only valid during the execution of
the servlet. Using the request "out-of-scope" resulted into a
NullPointerException on initSession. This was solved by changing the findBean
method so the found bean gets the current request.

Other norable changes involve serialization. WebLogic release notes describe
that they had many class loading problems that were solved using
serialization. As a result we got spurious serialization exceptions. They have
been solved by chainging the AbstractJSPBean and related classes.