The jaf-api from jakartaee

Problems with MailcapCommandMap

javax.activation.MailcapCommandMap references com.sun.activation.registries.LogSupport and com.sun.activation.registries.MailcapFile. These files are only available to Maven users in old com.sun.activation:javax.activation:1.2.0 dependency, but in turn this dependency contains duplicates of classes available in jakarta.activation:jakarta.activation-api:1.2.1 from the main javax.activation package.

Earlier all those classes were in JDK, but in JDK 11 they were removed, and now there are serious problems when trying to use Java Mail API (which includes registration of non-existent mime type handlers like com.sun.xml.internal.ws.encoding.StringDataContentHandler, which is now available as com.sun.xml.ws.encoding.StringDataContentHandler in jaxws-rt).

All in all, Java Mail API is broken on JDK 11.

Create a native JPMS module descriptor

JAXB API uses activation-api as its dependency and is forced to use it as an automatic module or from classpath because of missing a module-info.java descriptor file.

Add version string to generated javadoc

see jakartaee/specifications#172 (review) for background

Release 2.0.1

2.0.0 misses some fixes: 2.0.0...master

In case of Android it leads to failing builds:

   > Failed to transform jakarta.activation-2.0.0.jar (com.sun.activation:jakarta.activation:2.0.0) to match attributes {artifactType=processed-jar, org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-runtime}.
      > Execution failed for JetifyTransform: /home/tobi/.gradle/caches/modules-2/files-2.1/com.sun.activation/jakarta.activation/2.0.0/f4e7519148dee347c7666f336210deedb8aca09d/jakarta.activation-2.0.0.jar.
         > Failed to transform '/home/tobi/.gradle/caches/modules-2/files-2.1/com.sun.activation/jakarta.activation/2.0.0/f4e7519148dee347c7666f336210deedb8aca09d/jakarta.activation-2.0.0.jar' using Jetifier. Reason: JDOMParseException, message: Error on line 76: Präfix "Xlint" für Element "Xlint:all" ist nicht gebunden.. (Run with --stacktrace for more details.)

It would be great if you can release 2.0.1 with this minor bug fix 💛

Project webpage is down

Describe the bug
The project webpage as mentioned in the Readme: https://eclipse-ee4j.github.io/jaf/ is not working.

rename javax.activation properties to jakarta.activation

As per JakartaEE9ReleasePlanFAQ properties javax.activation.addreverse should be changed to jakarta.activation.addreverse + javax.activation.debug to jakarta.activation.debug.

Build CI/CD pipeline

This task is for creating a basic build CI/CD pipeline for this project on Eclipse infrastructure. More information is here: https://ci.eclipse.org/.

Compatibility certification request for EE4J implementation of Jakarta Activation

Provide standalone implementation independent API jar

Is your feature request related to a problem? Please describe.
Current API jar uses implementation specific classes which makes it difficult for other implementations to reuse existing APIs

Describe the solution you'd like
An API jar with no dependencies on implementation classes is available

Compatibility certification request for EE4J implementation of Jakarta Activation

Release API to OSSRH staging repository

Uptake new Eclipse versions of dependencies (if any). Use GlassFish 5.1 Release Tracker wiki to find components versions to use.
Release to OSSRH staging repository
Update GlassFish 5.1 Release Tracker with released version number.

Deprecatation of PipedInputStream and PipedOutputStream

There is a JDK ticket https://bugs.openjdk.java.net/browse/JDK-8223048 that involves deprecating the PipedInput/Output streams.

JAF is using pipes in: https://github.com/eclipse-ee4j/jaf/blob/2f70d93461be37892f98380467ad127d19e9fa1e/activation/src/main/java/jakarta/activation/DataHandler.java#L233

Need to look to see of there are other areas and re-implement using the recommended workarounds when JDK-8223048 is closed.

Deliver Jakarta Activation Specification Version update for Jakarta EE 9

Is your feature request related to a problem? Please describe.
Jakarta EE 9 is the next major release, with the main focus of moving from the javax namespace to the jakarta namespace.

Describe the solution you'd like
This issue will be used to track the progress of this work effort via the Jakarta EE 9 Project board.

Additional context
Jakarta EE Specification Process
Eclipse Project Handbook
Eclipse Release Record for Jakarta EE 9

ToDo

Prepare Jakarta Activation for Jakarta EE 8 Release

Instructions

Update text files
Generate "boilerplate" specification project
Make a staging release
Generate Stand-alone TCK test results
Submit tests for ballot
Release to Maven Central

See here for detailed instructions.

JDK8: java.lang.ClassCastException: com.sun.activation.registries.MailcapFile cannot be cast to jakarta.activation.MailcapRegistry

Describe the bug
It was reported in mail: eclipse-ee4j/angus-mail#37

Issue is explained here:
eclipse-ee4j/angus-mail#37 (comment)

To Reproduce
Reproducer here with JDK8:
eclipse-ee4j/angus-mail#37 (comment)

Expected behavior
No error should be thrown.

Additional context
To see the ClassCastException you just need to iterate over the list, for example:

	for (MailcapRegistry registry : dbv) {
	    System.out.println("Value: " + registry);
	    if (registry != null) {
	        System.out.println("Class: " + registry.getClass());
	    }
	}

[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.568 s <<< FAILURE! - in com.icegreen.greenmail.imap.commands.ImapProtocolTest
[ERROR] com.icegreen.greenmail.imap.commands.ImapProtocolTest.testUidSearchTextWithCharset  Time elapsed: 0.492 s  <<< ERROR!
java.lang.ClassCastException: com.sun.activation.registries.MailcapFile cannot be cast to jakarta.activation.MailcapRegistry
	at jakarta.activation.MailcapCommandMap.<init>(MailcapCommandMap.java:179)
	at jakarta.activation.CommandMap.getDefaultCommandMap(CommandMap.java:60)
	at jakarta.activation.DataHandler.getCommandMap(DataHandler.java:128)
	at jakarta.activation.DataHandler.getDataContentHandler(DataHandler.java:590)
	at jakarta.activation.DataHandler.writeTo(DataHandler.java:290)
	at jakarta.mail.internet.MimeUtility.getEncoding(MimeUtility.java:316)
	at jakarta.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1580)
	at jakarta.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2265)
	at jakarta.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2225)
	at jakarta.mail.Transport.send(Transport.java:99)
	at com.icegreen.greenmail.util.GreenMailUtil.sendMimeMessage(GreenMailUtil.java:266)
	at com.icegreen.greenmail.util.GreenMailUtil.sendTextEmail(GreenMailUtil.java:256)
	at com.icegreen.greenmail.imap.commands.ImapProtocolTest.beforeEachTest(ImapProtocolTest.java:41)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
	at com.icegreen.greenmail.junit.GreenMailRule$1.evaluate(GreenMailRule.java:63)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456)
	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169)
	at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)

Otherwise the issue is hidden by this other exception:

java.lang.ArrayStoreException
	at java.lang.System.arraycopy(Native Method)
	at java.util.ArrayList.toArray(ArrayList.java:414)
	at jakarta.activation.MailcapCommandMap.<init>(MailcapCommandMap.java:181)
        ...

Drop Applet from the spec

Java SE 9 marked java.applet.Applets for removal with no replacement. Going forward it may make sense to drop mentions about it from the spec document (and eventually from the code as well)

Loading of service provider implementations needs to be done under doPriviledge

Describe the bug
Loading of service provider implementations should be done on a privileged block. It will add the ability to the caller to invoke the API in a different protection domain and don't propagate the permissions check to the application source code.

That will allow the Application Servers to trust on the API code removing the need to add the required permissions by the users.
This can be reproducible with WildFly by deploying a simple servlet that sends an email when the security manager is enabled.

To Reproduce
Deploy a servlet that tries to send an email in WildFly with the security manager enabled:

$ wildfly/bin/standalone.sh -secmgr

@WebServlet(value = "/mail")
public class MailServlet extends HttpServlet {
    @Resource(mappedName = "java:jboss/mail/Default")
    private Session mailSession;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        PrintWriter out = response.getWriter();
        try {
            MimeMessage m = new MimeMessage(mailSession);
            Address from = new InternetAddress("[email protected]");
            Address[] to = new InternetAddress[]{new InternetAddress("[email protected]")};
            m.setFrom(from);
            m.setRecipients(Message.RecipientType.TO, to);
            m.setSubject("Test Mail");
            m.setSentDate(new java.util.Date());
            m.setContent("Mail sent from WildFly", "text/plain");
            Transport.send(m);
            out.println("Mail sent!");
        } catch (jakarta.mail.MessagingException e) {
            e.printStackTrace();
            out.println("Error in Sending Mail: " + e);
        }
    }
}

Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/Users/yborgess/.m2/repository/org/eclipse/angus/angus-activation/1.0.0/angus-activation-1.0.0.jar" "read")" in code source "(vfs:/content/jakarta-mail-tester-1.0-SNAPSHOT.war/WEB-INF/classes &lt;no signer certificates&gt;)" of "ModuleClassLoader for Module "deployment.jakarta-mail-tester-1.0-SNAPSHOT.war" from Service Module Loader")
	at [email protected]//org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:309)
	at [email protected]//org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:201)
	at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
	at [email protected]//org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:374)
	at java.base/java.util.zip.ZipFile.&lt;init&gt;(ZipFile.java:237)
	at java.base/java.util.zip.ZipFile.&lt;init&gt;(ZipFile.java:177)
	at java.base/java.util.jar.JarFile.&lt;init&gt;(JarFile.java:350)
	at java.base/sun.net.www.protocol.jar.URLJarFile.&lt;init&gt;(URLJarFile.java:103)
	at java.base/sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:72)
	at java.base/sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99)
	at java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:125)
	at java.base/sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:155)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.parse(ServiceLoader.java:1165)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1206)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1221)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(ServiceLoader.java:1268)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(ServiceLoader.java:1267)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1270)
	at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300)
	at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385)
	at [email protected]//jakarta.activation.ServiceLoaderUtil.firstByServiceLoader(ServiceLoaderUtil.java:33)
	... 60 more

Expected behavior
I wouldn't expect to have to add permissions to my application to load the Angus activation Jar file.

TCK Challenge: TCK should not require JPMS module-info.class

Challenged Tests:
build.xml
javasoft.sqe.tests.jakarta.activation.Module.UnnamedModule_Test

TCK Version:
Jakarta Activation 2.1.0

Tested Implementation:
Open Liberty

Description:
Per section 13.3 of the EE 10 specification, "there is no requirement around testing of JPMS in API jar signature tests or TCKs." However, there is a test in this TCK (and in truth, the entire automation of this TCK) that is doing exactly that.

Open Liberty does not provide API jars containing a module-info.class and as such is unable to run this TCK as it is currently written. Attempts to do so fail with the following:

[javatest.batch] java.lang.module.FindException: Unable to derive module descriptor for /jakarta/vi/wlp/dev/api/spec/io.openliberty.jakarta.activation.2.1_1.0.70.jar
[javatest.batch] Caused by: java.lang.IllegalArgumentException: io.openliberty.jakarta.activation.2.1.1.0.70: Invalid module name: '2' is not a Java identifier
[javatest.batch] Java Result: 1

If the automation is updated to not require JPMS in the API jar (by removing the module stuff from lines 191 & 192 in build.xml), then the UnnamedModule_Test still fails since it is explicitly testing that the API jar is on the modulepath.

Integrate to GlassFish

Integrate to Eclipse GlassFish
Pass all CTS/TCK tests

#11 must be finished before starting working on this task.

License specification is not clear

Describe the bug

The repository mentions two different licenses: The "Eclipse Distribution License v. 1.0" and the "BSD 3-Clause" license. It is not really clear, which is applicable to the project, EDL, BSD or both.

pom.xml: Both in comment, EDL in metadata
LICENSE.md: BSD
NOTICE.md: both
Source code comments: both

Expected behavior

I should be able to see the correct licence in all those places. As far as I can see, the EDL has no official SPDX identifier, so if one wants to keep the SPDX-conformant headers and the license is, in fact, EDL, a new identifier should be requested

Compatibility certification request for Eclipse Angus/Activation 1.0.0

Jakarta EE 8 TCK job

To test Jakarta EE 8 compatibility we need to create a Jenkins job on project's Cloud Jenkins instance formally testing the API against the relevant TCK and as needed, relevant CTS subset tests.

For projects that do not already have automated testing, there is provided parameterized Jenkins job that can be invoked to perform these tests. User provides a link to an Eclipse GlassFish test build and sets the test sub-set parameters:

For CTS -- https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-certification/
For Stand-alone TCKs -- https://ci.eclipse.org/jakartaee-tck/job/standalonetck-certification/

Additional instructions and guidance for using and directly running TCKs is available on this wiki. Also in the jakartaee-tck project repository.

Release CI/CD pipeline

We need to create a release CI/CD pipeline for this project.

Use these documents as a reference:

Change Maven coordinates

All current API libraries shipped must be distributed to Maven Central under a sub-package of the jakarta groupId. Before the first release Maven coordinates of this project must be changed as it's described here.

jakarta.activation-api 1.2.2 can't be used as OSGi bundle under JDK8

Describe the bug
jakarta.activation/jakarta.activation-api/1.2.2 contains this OSGi header:

Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=9.0))"

To Reproduce
Steps to reproduce the behavior:

Run Karaf under JDK8 install -s mvn:jakarta.activation/jakarta.activation-api/1.2.2
See error:

karaf@root()> install -s mvn:jakarta.activation/jakarta.activation-api/1.2.2
Bundle ID: 144
Error executing command: Error installing bundles:
	Unable to start bundle mvn:jakarta.activation/jakarta.activation-api/1.2.2: org.osgi.framework.BundleException: Unable to resolve jakarta.activation-api [144](R 144.0): missing requirement [jakarta.activation-api [144](R 144.0)] osgi.ee; (&(osgi.ee=JavaSE)(version=9.0)) Unresolved requirements: [[jakarta.activation-api [144](R 144.0)] osgi.ee; (&(osgi.ee=JavaSE)(version=9.0))]

Expected behavior
jakarta.activation/jakarta.activation-api/1.2.2 is JPMS module, but the code itself doesn't require JDK9+. So this jar/bundle should be compatible with JDK8.

What about the term JavaBeans?

Is the term "JavaBeans" OK in this context?

Two artifacts declare the same module name "jakarta.activation" – this does not work.

Both activation and activation-api declare their module name as jakarta.activation:

This does not work, and results in various silent (having a Maven project on Jenkins fails silently, because Jenkins does not detect the misdisagnosed "JVM crash" as a build failure) and not so silent (IntelliJ, GitLab CI) ways.

The problem has been verified on 1.x (via Automatic-Module-Names in MANIFEST.MF), but likely also exists on 2.x (via module-info.java).

Use OSGi service loader mediator instead of osgi resource locator

When separating the api and the implementation, the service loader was introduced. This perfectly well suited mechanism is known to have problems in OSGi environments.

To overcome this, 4d84d6b added the hk2osgi service locator, which requires lots of special coding.

The problem has actually successfully been addressed before by http://docs.osgi.org/specification/osgi.enterprise/7.0.0/service.loader.html with the reference implementation (with an easier to read description) SPI Fly. What it boils down to is that instead of having to maintain the complicated code, you can simply use the service locator after adding some statements to MANIFEST.MF.

While these is not a runtime bug, because you can use Jakarta activation in an OSGi environment (once you have found out that you need to include the hk2 jar), I think it is a bug with respect to the design.

Move implementation out from the API repository

To make sure that APIs are really independent, implementation needs to be moved to its own repository.

Suggested new names for the implementation (feel free to suggest other names):

Eclipse Activation
BS-Act
ActBS
???

I intend to create new project proposal for the implementation during the first week of June 2021.

Tasks to complete the 2.0.0 release

The specification project team needs to complete the following to finalize the activation 2.0.0 relase:

promotes api staging release promotes the specification api jars to maven central. An example release job script can be found here https://wiki.eclipse.org/MavenReleaseScript.
go through the merged jakarta.ee specification website page to verify all the links are valid.
approve the compatibility request.
The compatible implementation project/vendor MUST send an email to [email protected] for approval of the compatible implementation for trademark usage.
merge any final release branch as appropriate for the branch management for the project.

NoClassDefFoundError: com/sun/activation/registries/LogSupport

com/sun/activation/registries is part of the source in GIT but is not present in the maven repository for version 2.0.0 so I'm getting the following error:

java.lang.NoClassDefFoundError: com/sun/activation/registries/LogSupport
	at jakarta.activation.MimetypesFileTypeMap.<init>(MimetypesFileTypeMap.java:100)
	at jakarta.activation.MimetypesFileTypeMap.<init>(MimetypesFileTypeMap.java:271)

Runnig in Eclipse Eclipse IDE for Enterprise Java Developers 2020-09, Java OpenJDK 11 and Apache Tomcat 9.0 with the following maven configuration:

<dependency>
  <groupId>jakarta.activation</groupId>
  <artifactId>jakarta.activation-api</artifactId>
  <version>2.0.0</version>
</dependency>

In https://github.com/eclipse-ee4j/jaf/tree/master/activation/src/main/java/com/sun/activation/registries it is annotated "Move APIs to the jakarta.* package for the 2.0 release."

JDK 9 set as minimal JavaSE in OSGi env

Describe the bug
2.0.0-rc1 contains Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=9.0))" header in manifest which effectively means that under OSGi, JDK 9+ is required

To Reproduce
see rc1.jar/META-INF/MANIFEST.MF

Expected behavior
manifest header is either Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" or none. First option is preferred.

Additional context
caused by using old felix-bundle-plugin; can be fixed either by updating the plugin to 4.2.1 (generates correct Require-Capability header) or by adding

<_noee>true</_noee>

to plugin configuration (does not generate Require-Capability header at all)

Do not include jakarta.activation-api in jakarta.activation

This issue will probably be closed, because this would be a breaking change, but I still want to discuss it:

Currently, the artifact com.sun.activation:jakarta.activation:jar includes the entirety of jakarta.activation:jakarta.activation-api, instead of just depending on it.

This leads to the unfortunate situation that the dependency graph of our application (after updating to jakarta.mail) contains both com.sun.activation:jakarta.activation:1.2.1 (new dependency of jakarta mail) and javax.activation:javax.activation-api:1.2.0 (dependency of several other libraries).

If jakarta.activation would instead depend on jakarta.activation-api, the build system (Gradle) could automatically upgrade the old dependencies of the other libraries to jakarta.activation-api:1.2.1. (Of course, Gradle needs to know that the module jakarta.activation:jakarta.activation-api is a replacement for javax.activation:javax.activation-api, but this is easily done with Gradle). But unfortunately, "activation" doesn't declare any relationship to "activation-api", so this is a messy thing to resolve manually.

Most (all?) other javax/jakarta projects do it better: For example, jaxb-runtime declares a dependency to jaxb-api instead of including it.

Android compilation failure due to possible badly formed compiler args in pom.xml

Describe the bug
When attempting to compile my Android app with the Jakarta Activation Maven Central component below my build fails because of invalid XML defined in the pom.xml

To Reproduce
Steps to reproduce the behaviour:

Add the Jakarta Activation component to an Android application by adding the line below to the dependencies section of app/build.gradle

dependencies {
    implementation 'com.sun.activation:jakarta.activation:2.0.0-RC3'
}

Try and compile the app
See the compilation error

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':exampleapp:kaptGenerateStubsDebugKotlin'.
> Could not resolve all artifacts for configuration ':exampleapp:debugCompileClasspath'.
   > Failed to transform jakarta.activation-2.0.0-RC3.jar (com.sun.activation:jakarta.activation:2.0.0-RC3) to match attributes {artifactType=android-classes-jar, org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-api}.
      > Execution failed for JetifyTransform: /Users/warwick/.gradle/caches/modules-2/files-2.1/com.sun.activation/jakarta.activation/2.0.0-RC3/fb066ef8205a8d4b4ca7c18eafc920a1e00383dd/jakarta.activation-2.0.0-RC3.jar.
         > Failed to transform '/Users/warwick/.gradle/caches/modules-2/files-2.1/com.sun.activation/jakarta.activation/2.0.0-RC3/fb066ef8205a8d4b4ca7c18eafc920a1e00383dd/jakarta.activation-2.0.0-RC3.jar' using Jetifier. Reason: JDOMParseException, message: Error on line 76: The prefix "Xlint" for element "Xlint:all" is not bound.. (Run with --stacktrace for more details.)
           Suggestions:
            - Check out existing issues at https://issuetracker.google.com/issues?q=componentid:460323&s=modified_time:desc, it's possible that this issue has already been filed there.
            - If this issue has not been filed, please report it at https://issuetracker.google.com/issues/new?component=460323 (run with --stacktrace and provide a stack trace if possible).

Expected behavior
The app build correctly.

Smartphone (please complete the following information):

Device: Emulator running Android 11
OS: Android 11

Additional context

I believe the problem is caused by the way the Xlint arguments are defined in the activation/pom.xml file. They don't appear to be valid XML to me, but I am not an experienced maven user.

	    <plugin>
		<artifactId>maven-compiler-plugin</artifactId>
		<executions>
		    <execution>
			<id>default-compile</id>
			<configuration>
			    <!--
				ignore some of the errors that are
				too hard to fix for now
			    -->
			    <compilerArguments>
				<Xlint:all/>
				<Xlint:-rawtypes/>
				<Xlint:-unchecked/>
				<Xlint:-finally/>
			    </compilerArguments>
			    <showWarnings>true</showWarnings>
			</configuration>
		    </execution>
		</executions>
	    </plugin>

By contrast this is how these options are defined in the Jakarta Mail mail/pom.xml which appears to me to be valid XML.

	    <plugin>
		<artifactId>maven-compiler-plugin</artifactId>
		<configuration>
		    <compilerArgs>
			<arg>-Xlint</arg>
			<arg>-Xlint:-options</arg>
			<arg>-Xlint:-path</arg>
			<!--<arg>-Werror</arg>-->
		    </compilerArgs>
		    <showDeprecation>true</showDeprecation>
		    <showWarnings>true</showWarnings>
		</configuration>
	    </plugin>

package-list and element-list are missing on the root of the Javadoc

I would like to link the documentation for Java Activation Framework with the Javadoc of my own library project, just for convenience reasons.

Usually, you do this with Javadoc's -link option and the URL for the root of the target Javadoc documentation; in this case, I assume it is https://eclipse-ee4j.github.io/jaf/docs/api/jakarta.activation/. But in order to work, it is required that this folder contains a package-list and/or an element-list file; they are generated by Javadoc together with the HTML and contain the names of the packages and modules that are documented.

I assume that the file(s) will just not be copied when the Javadoc is published. This may be intentional, although it would not be funny if so …

Update EFSL for Specifications and Javadoc

Per the discussions on the Spec Committee and Platform Dev mailing lists, it's been discovered that many of the Javadoc and Spec references to the EFSL need updating. Please reference the following required updates and keep them in mind as your Spec Project is updating the files for Jakarta EE 9.

Note: Some Spec Projects have already started or even completed these updates. If so, just kindly return/close this Issue. Thanks!

Required EFSL updates for Javadoc

For javadoc, the EFSL.html located in src/main/javadoc/doc-files should be modified as follows:

the <<url to this license>> needs to be replaced with efsl.php link[1]
the [title and URI of the Eclipse Foundation specification document] needs to be replaced with the Specification Name and URL (Reference [2] for an example.)
The javadoc footer copyright year needs to be updated to 2018, 2020 as defined in the pom.xml

Required EFSL updates for Specifications

For specification, the license-efsl.adoc located in src/main/asciidoc should be modified as follows:

the <<url to this license>> needs to be replaced with efsl.php link[1]
the [title and URI of the Eclipse Foundation specification document] needs to be replaced with the Specification Name and URL (Reference [2] for an example.)

[1] https://www.eclipse.org/legal/efsl.php
[2] https://jakarta.ee/specifications/enterprise-beans/4.0/

Redundant <p> at end of paragraph

This issue relates to https://bugs.openjdk.java.net/browse/JDK-8184218

In jaxws/src/java.activation/share/classes/javax/activation/CommandInfo.java
there is a redundant

at the end of line 115. This shows up as a warning (the only warning) reported by tidy in the generated docs for the java.activation module.

 * <p> 
 * If the bean does NOT implement the CommandObject interface, 
 * this method will check if it implements the 
 * java.io.Externalizable interface. If it does, the bean's 
 * readExternal method will be called if an InputStream 
 * can be acquired from the DataHandler.<p>

It would be good to remove the extra

and have the java.activation module with a clean bill of documentation health.

Add jakarta.activation.spi to the spec

with independent API jar, new SPI has been added. This needs to be reflected in the spec document

TCK Challenge: TCK should not require JPMS module-info.class

Challenged Tests:
build.xml
javasoft.sqe.tests.jakarta.activation.Module.UnnamedModule_Test

TCK Version:
Jakarta Activation 2.1.0

Tested Implementation:
Open Liberty

Description:
Per section 13.3 of the EE 10 specification, "there is no requirement around testing of JPMS in API jar signature tests or TCKs." However, there is a test in this TCK (and in truth, the entire automation of this TCK) that is doing exactly that.

Open Liberty does not provide API jars containing a module-info.class and as such is unable to run this TCK as it is currently written. Attempts to do so fail with the following:

[javatest.batch] java.lang.module.FindException: Unable to derive module descriptor for /jakarta/vi/wlp/dev/api/spec/io.openliberty.jakarta.activation.2.1_1.0.70.jar
[javatest.batch] Caused by: java.lang.IllegalArgumentException: io.openliberty.jakarta.activation.2.1.1.0.70: Invalid module name: '2' is not a Java identifier
[javatest.batch] Java Result: 1

If the automation is updated to not require JPMS in the API jar (by removing the module stuff from lines 191 & 192 in build.xml), then the UnnamedModule_Test still fails since it is explicitly testing that the API jar is on the modulepath.

Update Scope Statement for Jakarta Beans Activation Framework Project

Update the scope statement for the project: https://projects.eclipse.org/projects/ee4j.jakartaee-platform/governance

See https://docs.google.com/spreadsheets/d/1FPLjo_DJDOQngVtdrYgaDk98d9NBG-0ODgdmOG3LOsI/edit?usp=sharing for examples.

MailcapCommandMap requires accessDeclaredMembers when Security Manager is enabled

Describe the bug

As part of this commit MailcapCommandMap:620 was modified and now the invoker application requires accessDeclaredMembers permission when running under the SecurityManager. This permission is now required because the class that represents the mime type data content handler is being loaded by using:

cl.getDeclaredConstructor().newInstance()

Which will require the accessDeclaredMembers permission to load any available constructor regardless of the constructor's access level. However, this piece of code is only dealing with public constructors because the new instance is executed immediately without taking into account the constructor visibility.

To avoid breaking existing applications that are being moved to Jakarta 10, MailcapCommandMap:620 can be replaced with
cl.getConstructor().newInstance(); and get the same result without requiring this additional permission.

To Reproduce
Deploy a servlet that sends an email with the security manager enabled:

$ wildfly/bin/standalone.sh -secmgr

@WebServlet(value = "/mail")
public class MailServlet extends HttpServlet {
    @Resource(mappedName = "java:jboss/mail/Default")
    private Session mailSession;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        PrintWriter out = response.getWriter();
        try {
            MimeMessage m = new MimeMessage(mailSession);
            Address from = new InternetAddress("[email protected]");
            Address[] to = new InternetAddress[]{new InternetAddress("[email protected]")};
            m.setFrom(from);
            m.setRecipients(Message.RecipientType.TO, to);
            m.setSubject("Test Mail");
            m.setSentDate(new java.util.Date());
            m.setContent("Mail sent from WildFly", "text/plain");
            Transport.send(m);
            out.println("Mail sent!");
        } catch (jakarta.mail.MessagingException e) {
            e.printStackTrace();
            out.println("Error in Sending Mail: " + e);
        }
    }
}

The following is the error trace of the issue:

14:01:43,837 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jakarta-mail-tester-1.0-SNAPSHOT/mail: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/jakarta-mail-tester-1.0-SNAPSHOT.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.jakarta-mail-tester-1.0-SNAPSHOT.war" from Service Module Loader")
	at [email protected]//org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:309)
	at [email protected]//org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:201)
	at java.base/java.lang.Class.checkMemberAccess(Class.java:2847)
	at java.base/java.lang.Class.getDeclaredConstructor(Class.java:2549)
	at [email protected]//jakarta.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:620)
	at [email protected]//jakarta.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:573)
	at [email protected]//jakarta.activation.DataHandler.getDataContentHandler(DataHandler.java:591)
	at [email protected]//jakarta.activation.DataHandler.writeTo(DataHandler.java:290)
	at [email protected]//jakarta.mail.internet.MimeUtility.getEncoding(MimeUtility.java:316)
	at [email protected]//jakarta.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1580)
	at [email protected]//jakarta.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2265)
	at [email protected]//jakarta.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2225)
	at [email protected]//jakarta.mail.Transport.send(Transport.java:99)
	at deployment.jakarta-mail-tester-1.0-SNAPSHOT.war//wildfly.demo.MailServlet.doGet(MailServlet.java:44)
	at [email protected]//jakarta.servlet.http.HttpServlet.service(HttpServlet.java:527)
	at [email protected]//jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614)
	at [email protected]//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
	at [email protected]//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at [email protected]//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
	at [email protected]//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at [email protected]//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$1(ElytronRunAsHandler.java:68)
	at [email protected]//org.wildfly.security.auth.server.FlexibleIdentityAssociation.runAsFunctionEx(FlexibleIdentityAssociation.java:103)
	at [email protected]//org.wildfly.security.auth.server.Scoped.runAsFunctionEx(Scoped.java:161)
	at [email protected]//org.wildfly.security.auth.server.Scoped.runAs(Scoped.java:73)
	at [email protected]//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:67)
	at [email protected]//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
	at [email protected]//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:117)
	at [email protected]//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at [email protected]//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at [email protected]//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at [email protected]//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at [email protected]//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at org.wildfly.security.elytron-web.undertow-server-servlet@3.0.0.Final//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
	at [email protected]//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at [email protected]//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at [email protected]//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at [email protected]//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
	at [email protected]//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
	at [email protected]//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:275)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:134)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:131)
	at [email protected]//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at [email protected]//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1435)
	at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1435)
	at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1435)
	at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1435)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:255)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:106)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:103)
	at [email protected]//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
	at [email protected]//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:859)
	at [email protected]//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
	at [email protected]//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
	at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
	at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
	at [email protected]//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1282)
	at java.base/java.lang.Thread.run(Thread.java:829)

Expected behavior
I wouldn't expect to have to add this permission to load an expected class that will handle the mime type.

Change project name to Jakarta Activation

Background information:
https://waynebeaton.wordpress.com/2019/04/04/renaming-java-ee-specifications-for-jakarta-ee/

Checklist:

GitHub
README file
CONTRIBUTING file
Eclipse Project under https://projects.eclipse.org/projects/ee4j

Convert "Eclipse Project for JAF" into a specification project

In order to prepare this project to engage in specification work, we need to convert it into a specification project as defined by the Eclipse Foundation Specification Process (EFSP). As part of this work, we will change the project name per #20 and the scope per #19 .

We'll use this issue to capture the work that needs to be done as part of this effort.

Resolve #20
Resolve #19
Successful complete a restructuring review
Designate the project as a specification project of the Jakarta EE Working Group
Change project name to
Change project scope

This assumes that the project team chooses to use a single repository for both the specification document and the existing API. Webmaster can create a separate spec repository if the project team prefers that.

Compatibility certification request for Eclipse Angus/Activation 1.1.0

API artifact contains unresolvable osgi imports

In a Tycho based project, jakarta.activation-api artifact cannot be used as a compile time dependency due to:

Cannot resolve project dependencies:
  Software being installed: mavenproject4 1.0.0.qualifier
  Missing requirement: jakarta.activation-api 1.2.1 requires 'java.package; com.sun.activation.registries 0.0.0' but it could not be found
  Cannot satisfy dependency: mavenproject4 1.0.0.qualifier depends on: java.package; javax.activation [1.2.0,2.0.0)

workaround is to extend system bundle/reexport required package from jdk or use com.sun.activation:jakarta.activation artifact instead

sample project showing the problem: activationOsgi.zip

Update CONTRIBUTING.md for Specification Project's repositories

Create/Update CONTRIBUTING files

Per input from the Eclipse EMO, each Specification Project needs to ensure that a CONTRIBUTING.md or CONTRIBUTING.adoc file exists in each specification-related repository maintained by Specification Projects.
In addition, the CONTRIBUTING.md or CONTRIBUTING.adoc file needs to include the following text:

## Eclipse Development Process

This Eclipse Foundation open project is governed by the Eclipse Foundation
Development Process and operates under the terms of the Eclipse IP Policy.

The Jakarta EE Specification Committee has adopted the Jakarta EE Specification
Process (JESP) in accordance with the Eclipse Foundation Specification Process
v1.2 (EFSP) to ensure that the specification process is complied with by all
Jakarta EE specification projects.

* https://eclipse.org/projects/dev_process
* https://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf
* https://jakarta.ee/about/jesp/
* https://www.eclipse.org/legal/efsp_non_assert.php

Please do this at your earliest convenience.
Thank you!

-- EE4J PMC ([email protected])

Compatibility certification request for EE4J implementation of Jakarta Activation 2.0.1

Start a Release Review

Passing Release Review is a required step before making a first public release. Deadline for passing the review is Nov 30th, 2018. Release review takes some time to complete, so it makes sense initiating it as soon as possible.

Start Release Review
Update Release Review Tracker

Additional information:

Final steps for Jakarta Activation 2.1

The specification project team needs to complete the following to finalize the Jakarta Activation 2.1 release:

promotes api staging release promotes the specification api jars to maven central. An example release job script can be found here https://wiki.eclipse.org/MavenReleaseScript.
go through the merged jakarta.ee specification website page to verify all the links are valid.
approve the compatibility request.
The compatible implementation project/vendor MUST send an email to [email protected] for approval of the compatible implementation for trademark usage.
merge any final release branch as appropriate for the branch management for the project.

missing 2.0.0 release

It looks like with commit f21458d the version was updated to 2.0.0 but no version 2.0.0 has been tagged in git, or was released on GitHub.

Other final releases of eclipse-ee4j projects (e.g. saaj-api 2.0.0) are starting to depend on changes that look like they would be part of this "missing" 2.0.0 release, namely the renamed packages / import paths (javax.activation → jakarta.activation).

Are issues still blocking the "official" 2.0.0 release, or was this an oversight?

jakartaee / jaf-api Goto Github PK

jaf-api's Introduction

Jakarta Activation

License

Contributing

Links

jaf-api's People

Contributors

Stargazers

Watchers

Forkers

jaf-api's Issues

Instructions

See https://docs.google.com/spreadsheets/d/1FPLjo_DJDOQngVtdrYgaDk98d9NBG-0ODgdmOG3LOsI/edit?usp=sharing for examples.

Recommend Projects

Recommend Topics

Recommend Org