Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] More changes needed to compile after merging pruning of Jakarta Deployment change...

Thanks Scott. This would complete pruning the Jakarta Deployment changes with successful builds.


On 05/06/20 11:02 pm, Scott Marlow wrote:
The Platform TCK compilation failure due to org.glassfish.deployment.client is now resolved. :)

Scott

On Thu, Jun 4, 2020 at 7:53 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
https://github.com/eclipse-ee4j/jakartaee-tck/pull/306 removes the reference to org.glassfish.deployment.client classes, which I think will be fine, as the org.glassfish.deployment.client no longer can be called.  

If we do see any unexpected (appclient) deployment issues with missing EJB stub classes (on GlassFish 6), we should look deeper at the S1AS scripting.

Scott

On Thu, Jun 4, 2020 at 3:58 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
Hi,

The Platform TCK com.sun.ts.lib.implementation.sun.javaee.glassfish.AutoDeployment class no longer compiles, which makes sense as it depends on the (removed) GlassFish Deployment client.  

I don't think this is due to merging the change to remove Jakarta Deployment support, unless I missed something. I think it is more that I missed that com.sun.ts.lib.implementation.sun.javaee.glassfish.AutoDeployment references the (now removed) GlassFish Jakarta Deployment classes when running in Full Platform mode.  

There was discussion before of continuing to work with GlassFish as if running in Web Profile mode.  So, we can try doing that by updating com.sun.ts.lib.implementation.sun.javaee.glassfish.AutoDeployment to not reference the org.glassfish.deployment.client.* classes, however, I am concerned about possible side effects of what will not be setup for TCK testing.

AutoDeployment.java [1] shows the code that can 
 that we would modify to not use the org.glassfish.deployment.client.ServerConnectionIdentifier + org.glassfish.deployment.client.DeploymentFacility classes.  

Perhaps we do not need the AutoDeployment.java [1] getClientPath() code since we removed the EJB interoperability tests already, but I'm not really sure.

Also, there is a comment at the bottom of the [1] (private) getClientPath() that explains that we no longer need to return the jar file with the EJB stubs, so that may be unused code now.  It sure looks like unused code to me but I'm not sure of what the GlassFish deployment client might of been doing previously, that definitely will not happen anymore. 

Scott




_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

Back to the top