Bugzilla – Full Text Bug Listing
| Summary: | Persistence units from lazy bundles are not re-registered after bundle restart | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] Gemini.JPA | Reporter: | Krum Tsvetkov <krum.tsvetkov> | ||||
| Component: | Core | Assignee: | Michael Keith <michael.keith> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eduard.bartsch | ||||
| Version: | 1.0.0 | Flags: | michael.keith:
iplog+
|
||||
| Target Milestone: | 1.0.0 RC2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Thanks for filing the bug, Krum. Looks like the STOPPING event handling did not get changed to properly handle bundle stopping. The problem with not handling the LAZY_ACTIVATION event is that the STARTING event does not get fired until the first class load occurs, and this would typically happen when a client looks up and uses the service. Problem is that the register would need to have already happened in order for clients to access the service and cause a class to be loaded (and thereby cause the STARTING event to be fired), so you have a chicken and egg problem. The solution to me seemed to just do the registration in the LAZY_ACTIVATION event. There might be other solutions to the problem, but that seemed like the best one to me. Fix checked into RC2. |
Created attachment 193388 [details] Remove a stopping lazy bundle from the lazyBundles collection I faced the following problem: - I have a persistence unit bundle with the "Bundle-ActivationPolicy: lazy" header in the manifest - Sometimes after the OSGi framework starts (equinox) I had the problem that there is no EntityManagerFactoryBuilder registered for the unit. Sometimes everything worked fine. I figured out that if the bundle is first activated lazily (p.u. is then registered) and restarted afterwards (e.g. by a refreshPackages call somewhere in the system), then I don't get the registration of the p.unit after the restart, because the bundle doesn't go through LAZY_ACTIVATION again. If I have properly debuged the coding, then the reason for the problem is that when STOPPING event is processed in PersistenceBundleExtender the lazy bundle is not removed from the field "lazyBundles". I will attach a patch which just remvoes the stopping bundle from lazyBundles. For me this solves the problem. But I was wondering why the LAZY_ACTIVATION event is at all tackled separately. After it there is anyway also a STARTING event fired for the same bundle. To me it seems that the LAZY_ACTIVATION handling can be fully removed... If you also think so, I could test it and send another patch.