Community
Participate
Working Groups
Build Identifier: WTP 3.2 When the runtime target is changed on an EJB project with the JPA facet in an adopting product, two classpath containers are set on the project (i.e. the new runtime's classpath container, and the old runtime's classpath container still remains) From what I understand about the facet framework, when runtime targets are changed on a project, it iterates over the facets asking each one to detach itself in order to remove the classpath container. Since the JPA facet does not have a runtime changed listener/handler, the framework assumes that the classpath container cannot be removed since it still sees the JPA facet "owning" the classpath container (who didn't take any action). I'm attaching a patch implementing a runtime changed listener that solves this problem and hopefully will explain the problem further. Note that the EJB facet has a similar listener too. Can this be considered for WTP 3.2.1 please? Reproducible: Always
Created attachment 172348 [details] Patch to add a runtime changed listener to the JPA facet
Konstantin, does this patch look right, or is this something that should be handled within the library provider framework? Or are we not utilizing the library provider framework correctly within this context?
The facet should call into the library provider framework upon runtime change as the available libraries could be different in the new context, but the attached patch isn't the right way to do this. The attached patch is correct for facets that use the basic ClasspathHelper API (like the module facets), but for facets that use the library provider framework, the body of the listener needs to be different. It should look more like the version change action. You will need to create LibraryInstallDelegate and run it to let it do it's thing.
Created attachment 172687 [details] patch Unfortunately, I don't really have any runtime definitions that provide libraries for JPA, so I can't test this patch out. I don't have a way to set up a runtime library provider. Konstantin, is this pretty much what you're talking about? Len, does this solve your problem?
That looks about right.
Leonard, can you verify that the patch addresses your problem? I'd like to have something released soon.
(In reply to comment #6) > Leonard, can you verify that the patch addresses your problem? I'd like to > have something released soon. Hi Paul, I just tried the patch and it doesn't seem to work. In debugging, it does get into your new listener, but the following call returns null for the working copy so nothing is done: IFacetedProjectWorkingCopy fpwc = facetedProjectEvent.getWorkingCopy();
Created attachment 172915 [details] updated patch Ah, hadn't tested the situation where the faceted project wasn't actually being changed. Can you try the updated patch?
(In reply to comment #8) > Created an attachment (id=172915) [details] > updated patch > Ah, hadn't tested the situation where the faceted project wasn't actually being > changed. > Can you try the updated patch? OK that seems to work just fine. Thanks.
Committed to head. Please reopen if there are further issues.
