Payara Server 4.1.1.154
Release Highlights
This release brings us back in line with GlassFish 4.1.1, with the benefit of all our additional fixes and enhancements from our previous releases, as well as a few more. Of particular interest in this release:
- Up to date with GlassFish 4.1.1.
- Removal of the dependency on .NET Framework 3.5, allowing Payara to be used with .NET Framework 4.
- The payaradomain domain will now use an embedded Derby database for its default datasources (domain1 is unchanged to retain drop-in replacement viability).
- You can now set DISABLED as a JMS Broker type, allowing you to disable the OpenMQ Broker.
- Setting size-based log rotation to 0 will now turn it off.
In line with our naming strategy, our version number has also been extended for this release to reflect the fact that we are up to date with GlassFish 4.1.1.
Updated Modules
This section details the modules that have been updated since the last release (4.1.153).
- Mojarra 2.2.12
- Webservices 2.3.2-b608
- JAXB 2.2.12-b141219.1637
- JAXB-API 2.2.13-b141020.1521
- Weld 2.2.16.Final
- Tyrus 1.11
- JBatch 1.0.1-b09
- Grizzly 2.3.23
- HK2 2.4.0-b32
- Jersey 2.22
- Hazelcast 3.5.2
Enhancements
This section details the issues marked as enhancements that have been implemented for this release.
- 414/PAYARA-389 - Disable size based log rotation when set to zero
- 421/PAYARA-447 – Add some simple asadmin commands
- 425 - Make Instance Descriptor null safe when zero applications deployed
- 429/PAYARA-387 - Make the default DerbyPool use Derby Embedded
- 439/PAYARA-427 - Allow DISABLED as a JMS Broker type.
- 440 - Allow MDB to specify the resource adapter to use in the Activation Config
- 457/PAYARA-409 – Remove Update Center
- 463/PAYARA-369 - Payara product names are not correct in the console. Should be Payara Server
- 467/PAYARA-457 - classloader work
- 475/PAYARA-347 - Converter autoApply does not work for primitive types
- 479/PAYARA-453 - Windows service wrapper depends on .NET Framework 3.5
Fixed Issues
This section details the issues marked as bugs that have been fixed for this release.
Payara Fixes
This section details the fixes implemented by the Payara team or community.
- 270 - Support rolling updates
- 300 - Bean identifier index inconsistency after Hot re-deployment from NetBeans
- 327 - Tyrus send partial message more than buffer size will cause exception in catalina OutputBuffer
- 350 - Using AJP when downloading of large streaming data results in the errors "OutOfMemoryError: Java heap space" and "503 Service Temporarily Unavailable"
- 371 - Creating an HTTP listener with security enabled using web admin console doesn't work
- 377 - JAX-RS integration with EJB Technology doesn't work
- 385/PAYARA-444/GLASSFISH-21371 - Alternate descriptors not persisted in remote deployments
- 395 - IllegalArgumentException when starting a payara micro on Windows via cli with --rootDir or --domainConfig
- 409/PAYARA-266 - Unable to add or remove java debug option using asadmin
- 410/PAYARA-349 - Batch configuration requires data source on DAS
- 411/PAYARA-372 - JMS broker issues when broker port is already in use
- 412/PAYARA-373 - REST interface to create auth-realm fails
- 415/PAYARA-405 – It is possible to set invalid ejb container thread pool settings
- 418/PAYARA-415 - Can not inject PayaraMicroRuntime CDI bean when deploying a war on the PayaraMicro command line
- 420 - Changed the way to load payara-bootstrap.properties.
- 423 - Payara Micro name not passed through to the instance descriptor
- 427/PAYARA-322 - enable-secure-admin-principal adds principal multiple times
- 433/PAYARA-452 - Clustered / Versioned applications cannot be enabled on individual cluster instances
- 458/PAYARA-466 - File deleted after successfuly deployed with web gui local file dialog
- 460/PAYARA-459 - ${com.sun.aas.hostName} not resolved correctly in JVM options
- 465/PAYARA-448 - Could not load class javax.rmi.CORBA.EnumDesc
- 472/PAYARA-454 - NPE thrown by JMS Ping if no Default JMS Host is configured on the DAS
- 485/PAYARA-388 - Server log displays webappClassLoader severe warnings on shutdown
- PAYARA-370 - Fixes confusing typo in the admin console
- GLASSFISH-21007 - HTTP Upgrade handler init called twice when access log is turned on
Upstream Fixes
This section details the fixes brought in from the GlassFish upstream.
- GLASSFISH-21009 - The behavior of --timeout-seconds is not in line with the document
- GLASSFISH-21172 - javax.transaction.RollbackException from @Transactional bean has no cause set
- GLASSFISH-21381 - war with web service not deploying correctly
- GLASSFISH-21391 - Disable SSLv3 by default in config module
- GLASSFISH-21426 - Application deployment fails when DataSourceDefinition annotation is used within an EJB inside a war.
- fix enforcer version of the javadoc-jdk8+ profile activation
- fixed redundant null check caught by findbugs for an earlier commit
- In case of JDK 9, java.logging loading sun.util.logging.resources.logging resource bundle and java.logging module is used as the cache key with null class loader.So we are adding a null check
- As per servlet spec 3.1, when Request.setCharacterEncoding(String enc) is called, the call should be a no-op if request input parameters have already been read or if getReader() has been called. However, at present, check is there only in case of use of reader and no check if parameter has been read by a different method call (e.g by calling getParameter()). This seems to be a regression introduced during Grizzly 2.0 integration in revision 46674. Changes have been made to check if parameters have been processed/read too. character encoding will not be set if either parameters have been reader or reader is being used.
- EjbDescriptor abstract class implements JndiNameEnvironment and WritableJndiNameEnvironment. For some of these methods, though there is a generic implementation (For example via CommonResourceDescriptor), these methods still needs to be implemented in a specific way within EjbDescriptor abstract class to get the expected behavior whenever these methods are invoked in EjbDescriptor's context. To ensure the same, a new unit test is being introduced within source workspace, namely EjbDescriptorInheritedMethodImplementationTest,which basically ensures following two things: All methods defined in JndiNameEnvironment and WritableJndiNameEnvironment have a direct implementation within EjbDescriptor abstract class and all these methods are marked final in EjbDescriptor to ensure that sub-classes of EjbDescriptor don't override these methods accidentally, possibly causing unexpected behavior.
- fix web container issue filed in Grizzly
Known Issues
Known issues can be seen on our GitHub issues page here: https://github.com/payara/Payara/issues