The Apache Commons Project has released Commons Email 1.0,
an open source e-mail library "built on
top of the Java Mail API, which it aims to simplify."
Oracle has submitted JSR-301, Portlet Bridge Specification for JavaServer Faces to the Java Community Process. According to the JSR,
Currently, there are a number of JSF Portlet Bridge implementations including a number that have been open sourced. These implementations vary in style and substance to such as degree as to neither provide consistent interoperability across bridge implementations nor to provide interoperability across JSR portlet containers. I.e. the same JSF artifact can run differently in different bridge implementations and/or the same JSF artifact can run differently in the same bridge implementation running on a different portlet containers. This reduces the effectiveness of developing portlets using JSF technology as there are different rules to learn for different environments.
The purpose of this specification is to standardize the behavior of these bridge implementations to ensure true interoperability for JSF artifacts. The specification will focus on defining behavior related to three areas:
- 1. Coexistence: the specification will define rules ensuring a portlet bridge's implementation doesn't subvert concurrently executing non-portlet based JSF artifacts within the same web application, i.e. servlet/http based JSF artifacts. In addition, the specification will define rules ensuring a portlet bridge's implementation doesn't subvert JSF (controller) extensions that are running in the environment.
- 2. Correctness: there are differences between the portlet model and the JSF model. This specification will define the correct transformations between them.
- 3. Extensions: there are some portlet features for which there are no corresponding JSF concepts. This is increasingly true in the ongoing consideration of the next revision of Java Portlet Specification (JSR 286). For example, how do portlet events map to the JSF execution lifecyle? This specification will define how these extensions behave and are treated in the JSF environment.
The Apache Commons Project has released Commons Email 1.0,
an open source e-mail library "built on
top of the Java Mail API, which it aims to simplify."
Sun has posted the second maintenance review change log for JSR 160: JMX Remote API 1.0 . Three changes, are proposed:
6343209: Specify how SubjectDelegationPermission works for ConnectorServer creators.
The creator of a JMXConnectorServer no longer needs to have all the permissions that connection created by the connector server will use. It can have a SubjectDelegationPermission for each remotely-authenticated identity instead. This simplifies deployment in security-conscious environments.
5021246: Spec for RMI connector should say code downloading used if applicable.
The RMI connector will use code downloading as specified in the article Dynamic code downloading using Java RMI if applicable. The Reference Implementation has always behaved this way, and the specification has been updated to reflect that.
6375696: CORBA tie classes for JMX Remote API should be in javax.management.remote.rmi
For compliance with the OMG's "IDL to Java Language Mapping Specification", the CORBA "tie classes" for the remote objects javax.management.remote.rmi.RMIServerImpl and javax.management.remote.rmi.RMIConnectionImpl should be in the javax.management.remote.rmi package.
Comments are due by August 14.
Sun has also posted the fourth maintenance review change log for JSR 3: Java Management Extensions (JMX) Specification . Proposed changes include:
- Remove javax.management.timer.TimerAlarmClockNotification
- Better support for schema evolution in CompositeData and CompositeType
- OpenType should not declare public static array ALLOWED_CLASSNAMES
- CompositeDataView.toCompositeData should have CompositeType parameter
- DescriptorKey has inconsistent meta-annotations
- ModelMBeanConstructorInfo says certain fields invalid, but doesn't check
- MLet support for native libraries is underspecified and should be optional
- Clarify how DescriptorKey used in an MBean interface is handled
- Clarify behaviour when null Descriptor parameter to MBeanInfo etc
- Better specify type strings in MXBean descriptors
- Added conventional metricType Descriptor field
- Specify that // is reserved in ObjectName domains
- JMX implementations should be allowed to make permission checks even if no SecurityManager
- @javax.management.PropertyNames becomes @java.beans.ConstructorProperties
Comments are due by August 14.