Community
Participate
Working Groups
I have to sheepishly admit that I think I caused a regression in the patch I proposed in bug 309030. Namely, when you have a web+JPA+OSGi project, persistence.xml is correctly created in the bundle root, but JPA does not look for persistence.xml there. As a result, you have an error immediately after creating the project, and the only way to fix it is to move the persistence.xml from META-INF/persistence.xml to WEB-INF/classes/META-INF/persistence.xml - where it fails to load within an OSGi runtime.
Created attachment 175008 [details] Proposed patch Simple fix - when the project is a web+JPA+OSGi, do not use the special case for JEE web projects.
Does this incorporate the latest patch from bug 309030? I notice the patch asks if the bundle root is null, but does that also take into account that the bundle root being null might mean that the project *is* the bundle root?
Hi Paul, Thanks for the quick response. No, I did not take into account the latest changes on bug 309030, just what is released to 3.2.1. The reason for this is that I'm worried the patch might have made things worse in 3.2.1 for this scenario, and I wanted to fix that outside the scope of other changes. FWIW, I've found two more references to projectHasWebFacet(): JptCorePlugin.getJarDeploymentRootPathName() and AbstractJarFileRef.resolveDeploymentJarFilePath() I am assuming these two places would need the exact same one line change as the patch (just adding "&& AbstractJpaProject.getBundleRoot(project) == null"), but I don't know Dali well enough to either trigger a failure without the change, or confirm if these changes are unnecessary.
I'm not sure I understand how this is a regression. Can you attach a project that worked in 2.3 that no longer works? Can you also detail a bit how jars are loaded with OSGi? Perhaps have some jar references that are intended to work in the example project?
> Can you attach a project that worked in 2.3 that no longer works? Actually no, and that's part of the problem. The location that persistence.xml is created in has changed to the correct location, but that highlights the problem. Here's the regression my patch caused: In 2.3 there was no direct bundle root support, so consumers had to map the source folder to "." (i.e. classes go directly into the root of the bundle). Although this was limiting, persistence.xml was created in /src and picked up from there - it looks odd during development, but goes to the right place on export. In 2.3.1, a consumer can either decide to leave their project in the same configuration, or map the source folder differently. This works great for normal JPA + OSGi projects - persistence.xml is now created in the bundle root (even though that could now be a separate folder), and gets picked up from there. However, in a web bundle the bundle root (WebContent) is different from /src. As a result of the change, persistence.xml is now created in the WebContent folder (the bundle root, the correct place at runtime), but it is not yet being found there by Dali, so now you've got an error immediately after creating the project. The only workaround is to manually copy the META-INF folder back into src/.
So the regression is that for wabs the persistence.xml is created in a different place that is not picked up by Dali? The old slightly improper location from 2.3 worked?
In addition, I want to make sure I understand the jar loading use cases. Where exactly should jars be at runtime for wabs?
> So the regression is that for wabs the persistence.xml is created in a > different place that is not picked up by Dali? The old slightly improper > location from 2.3 worked? The regression is that in 2.3 the persistence.xml was created in the wrong location, but Dali found it there. In 2.3.1 it is created in the correct location, but Dali doesn't recognize it in this case. I've verified that the file is loaded into the model correctly from this location (i.e. the rest of the change "works", and hence why it works without the web facet), it just isn't recognized when within a wab. And since this is the correct location from an OSGi perspective, it'll work fine at runtime even though nothing is recognized in the tools. > In addition, I want to make sure I understand the jar loading use cases. > Where exactly should jars be at runtime for wabs? Not sure I understand the question, but in OSGi you can have jars within your bundle as long as you use the Bundle-Classpath manifest attribute to add them to the bundle's classpath. The first two plugins I checked in my WTP build (javax.xml.rpc, javax.xml.soap) are examples of this, albeit unjarred ones. In a wab you'd probably leave jars in the traditional JEE web location (WEB-INF/lib) and just add a Bundle-Classpath entry to point to them.
What if we backed out the change to bug 309030? We would be fine with that as a solution and it seems a little less risky than adding more patches at this point in 2.3.1. What if other things are broken as a result of that patch as well? Then we could come up with a better solution for 2.3.2
Can someone "draw me a picture" and define the desired web project layout and file positions? :)
I should add that when I'm talking about jar loading, I'm talking about jar references in the persistence.xml. When I have a reference to "foo.jar", where is OSGi going to load that jar from?
Karen - That's certainly an option, as is declaring OSGi+JPA+Web unsupported until 2.3.2. Personally, I think this is a minor change and I don't think OSGi+JPA was very useable without the previous fix, but either way this has to be something that you and the team are comfortable with. Shaun - Will try to attach a screenshot or project after my next meeting. Paul - I keep getting collisions when saving, so I'll try to respond later too! :)
Created attachment 175085 [details] Screencap of OSGi+JPA+Web project Shaun - FYI, here's an example of what an OSGi+JPA+Web project should look like. Note persistence.xml is in the META-INF folder along with the bundle manifest, not in a second META-INF folder with the classes. Without 309030, persistence.xml is neither created under WebContent (the PDE bundle root in this case) nor recognized if it is moved there. With 309030 it is created in the correct place, but can't be found when it's in a web project (note empty JPA Content tree node).
Created attachment 175323 [details] What works, and what doesn't I thought it might help if I tried to summarize what works and what doesn't with 3.2, so attached is a spreadsheet that tries to do that. As you can see, there are several problems with 3.2, most of which were solved with bug 309030. The remaining issue that this bug tries to solve is in the Web case.
Targeting to 2.3.2 for now.
Marking this as a wholly owned subsidiary of bug 309030.
Agreed, and confirmed by current patch attached to 309030. Closing. *** This bug has been marked as a duplicate of bug 309030 ***
