Skip to main content

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

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

[1] https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/lib/implementation/sun/javaee/glassfish/AutoDeployment.java#L598



Back to the top