chimera: Fix duplicate key supression

The postgresql driver for chimera has logic to avoid duplicate key
errors in postgresql while still throwing the SQLException on the
client side.

Unfortunately, the error code used is inconsistent with the error
code used in other logic that supresses the duplicate key error.

This patch resolves the problem: I checked the other places the
modified methods are called, and code that doesn't rely on the
isDuplicateKeyError just checks whther the error code starts with
'23'. This will still work after the change.

Target: trunk
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6999/
(cherry picked from commit ee903925e9ea4513b3c553847ad120f62dab5ab3)

Conflicts:
	modules/chimera/src/main/java/org/dcache/chimera/PgSQLFsSqlDriver.java

(cherry picked from commit 5c37c7a19149d36855be1d949b0e91a4585fca2d)
Merge pull request #565 from gbehrmann/fix/2.6/rb6999

Fix/2.6/rb6999
httpd: Fix a couple of bugs

Target: trunk
Require-notes: no
Require-book: no
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/7002/
(cherry picked from commit b6fd9b5180902583b0e59fba97d3266ecf01cb53)

Conflicts:
	modules/dcache/src/main/java/org/dcache/cells/UniversalSpringCell.java
Merge pull request #574 from gbehrmann/fix/2.6/rb7002

Fix/2.6/rb7002
[maven-release-plugin] prepare release 2.6.27
[maven-release-plugin] prepare for next development iteration
pom: update jglobus library

a bugfix build of jglobus:

Changelog for v2.0.6-rc5.d..v2.0.6-rc6.d
    * [7429aa2] gridftp: Propagate FTP failure reply in client
    * [d734763] fix handling of DN with comma as per rfc1779

Ticket: #8285
Ticket: #8312
Acked-by: Paul Millar
Target: master, 2.9, 2.8, 2.7, 2.6
Require-book: no
Require-notes: yes
(cherry picked from commit 005b7bf391f599b596aadd21982e35e82e64471f)
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Merge pull request #588 from kofemann/new-gjlobus-2.6

New gjlobus 2.6
info-provider: fix works-by-accent bug when importing dCache config

The info-provider uses XML Entities to import dCache configuration.
The xmllint documentation, a used to work around a limitation in
Xerces, describes how a command-line option is required for it to
honour such Entity imports; however, earlier versions of xmllint did
not enforce this restriction and the info-provider worked despite
mistakenly omitting this option.

Mitigation against CVE-2014-0191 was achieved by fixing xmllint, so
enforcing the documented behaviour.  This change broke info-provider
with the following error being displayed:

/usr/share/dcache/info-provider/glue-both.xml:35: parser error : Entity 'dcache.paths.etc' not defined

This patch adds the option to tell xmllint to honour Entity imports.

Target: master
Patch: http://rb.dcache.org/r/7018/
Acked-by: Tigran Mkrtchyan
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Request: 2.2
Merge pull request #595 from paulmillar/fix/2.6/info-provider-xmllint

Fix/2.6/info provider xmllint
xrootd: Backport xrootd door and mover from dCache 2.9

Target: 2.6
Require-notes: yes
Require-book: no
Merge pull request #591 from gbehrmann/feature/2.6/xrootd

Feature/2.6/xrootd
[maven-release-plugin] prepare release 2.6.28
[maven-release-plugin] prepare for next development iteration
dcap: ensure that we remove session on DoorTransferFinishedMessage

does not fix, but ensure that we do cleanup in case of:

java.lang.NullPointerException: null
        at diskCacheV111.doors.DCapDoorInterpreterV3$SessionHandler.sendReply(DCapDoorInterpreterV3.java:963) ~[dcach
e-dcap-2.8.4.jar:2.8.4]
        at diskCacheV111.doors.DCapDoorInterpreterV3$IoHandler.doorTransferArrived(DCapDoorInterpreterV3.java:2398) ~
[dcache-dcap-2.8.4.jar:2.8.4]
        at diskCacheV111.doors.DCapDoorInterpreterV3.messageArrived(DCapDoorInterpreterV3.java:2695) ~[dcache-dcap-2.
8.4.jar:2.8.4]
        at diskCacheV111.doors.DCapDoor.messageArrived(DCapDoor.java:354) ~[dcache-dcap-2.8.4.jar:2.8.4]
        at dmg.cells.nucleus.CellAdapter.messageArrived(CellAdapter.java:994) ~[cells-2.8.4.jar:2.8.4]
        at dmg.cells.nucleus.CellNucleus$DeliverMessageTask.innerRun(CellNucleus.java:1070) ~[cells-2.8.4.jar:2.8.4]
        at dmg.cells.nucleus.CellNucleus$AbstractNucleusTask.run(CellNucleus.java:975) ~[cells-2.8.4.jar:2.8.4]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_55]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_55]
        at dmg.cells.nucleus.CellNucleus$1.run(CellNucleus.java:687) [cells-2.8.4.jar:2.8.4]
        at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]
21 May 2014 04:42:04 (DCap-dcache-door-cms19-<unknown>-57629) [] Uncaught exception in thread DCap-dcache-door-cms19-
<unknown>-57629-0

kills active transfers page with accumulated transfers

Acked-by: Paul Millar
Target: master, 2.8, 2.9, 2.7, 2.6
Require-book: no
Require-notes: no
(cherry picked from commit 2f2badb6a9ceb931d4522dac2355ad30f86e8faa)
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Merge pull request #600 from kofemann/fix-dcap-dos-2.6

dcap: ensure that we remove session on DoorTransferFinishedMessage
scripts: allow java8 runtime

Acked-by: Paul Millar
Target: master, 2.9, 2.8, 2.7, 2.6
Require-book: no
Require-notes: no
(cherry picked from commit 4a838d240102db12eaa1d0fc035155e1b22495eb)
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
xrootd: Upgrade to xrootd4j 1.3.3

Fixes IPv6 compatibility for kXR_locate request.

Target: trunk
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: https://rb.dcache.org/r/7034/
(cherry picked from commit 5b90dd5dc99a21db7de45160f07a459bbd4889c3)

Conflicts:
	pom.xml
dcache-webadmin: fix login redirect bug which misleadingly results in Access Denied Page

The following sequence of actions results in an Access Denied Page:

1.  Click on a bookmarked webadmin page (\*\*\* but see Testing below).
2.  On the user panel (below the DCache Bird at far right top),
    click login.
3.  Fill in user/password in login page, and click login.

The problem, which actually exists since Wicket 1.5, is that
the return URL used by Wicket to redirect from the intercept
page actually contains, as its query part, the subcomponent
of the page that generated the intercept request.

The problem is benign because returning to the home page
after the Access Denied Page appears shows that the user
is properly logged in.

In order to maintain correct redirection after intercept,
the only choice seems to be to override the exception-handling
pattern which Wicket uses to control the destination,
and to then force the reset of the target response page.

This is enabled by exposing the previously unexposed constructor
for the BasePage which allows PageParameters to be passed in,
and determining the bookmarked page class from the first
parameter.  If none is set, it then defaults to the home
page, as before.  In order to redirect with to an intercept
page, the RestartResponseAtInterceptPageException thrown
for this purpose should thus be constructed with the log in
page class and page parameters.

At present I cannot determine if there are any preferred
workarounds for this.  The problem presented at this link:

http://apache-wicket.1842946.n4.nabble.com/RestartResponseAtInterceptPageException-problem-in-1-5-td4255020.html

is precisely the one at issue here, but the suggestion
made by the developer is irrelevant.

This bug has actually been present since we migrated from
1.4 to 1.5, but has gone undiscovered until now (or at
least unreported).  Jan's and Tanja's code undoubtedly worked
correctly in the pre-1.5 context in which it was originally
written.

Target: 2.6
Committed: 39c2c0ebc16d97c1446c11c4a7a77c0d4862228f
Acked-by: Tigran
Patch: http://rb.dcache.org/r/6987
Bug: http://rt.dcache.org/Ticket/Display.html?id=8266
Require-book: no
Require-notes: yes

RELEASE NOTES:  Fixes a bug where clicking the login link from the
dCache bird panel on webadmin pages and then signing in via the
login page brings up an Access Denied Page (but which nonetheless
results in the user being properly logged after having
navigated to the home page).

TESTING:

***It is best to use a non-admin page to test this.
The reason is that currently, multiple gids are not
supported for administration access, and unless the
user cert is directly mapped to the admin user, navigating
to an admin page results in an automatic sign-in
via the cert; the user then is required to log out
and log in as admin, so the final response page in
this case is actually the log in page. The problem
of multiple gids will need to be addressed in the future.

After application of this patch, the Access Denied page
no longer appears and the user is redirected back to the
original page after login.
Merge pull request #605 from kofemann/j7-2.6

scripts: allow java8 runtime