Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Loader constraint violation in bundles with different versions Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Hi Costin,

    thanks a lot for your reply. Sorry for the late answer...

    Originally posted by Costin Leau View Post
    It took so long to reply since I've had issues with the project that you sent (the platform didn't contain the proper jars but jetty and javax.servlet). Anyway, I started the bundles on just the Equinox platform outside Eclipse.
    This is weird since I checked it before and I can easily import the whole things and run the examples easily within Eclipse 3.4...

    Originally posted by Costin Leau View Post
    The problem that I described can be exhibited by just adding a System out inside the Solution activator as follows:
    Yes, this is true. Does this mean that Spring dm is a bit more "aggresive" by doing the injection? I mean that the "getter methods" will be executed directly within the startup phase?

    Originally posted by Costin Leau View Post
    ...
    becomes

    Code:
    public interface PricingService {
    
        public String getPrice();
    
    }
    Again you can configure the implementation directly inside the Pricing activator and just publish the object through the Pricing interface.

    Lastly, note that this is not a Spring DM or OSGi problem per se - it's a generic versioning problem : you are forcing two versions of the same class inside the same space. As I've pointed out if you are using the uses clause, the bundle can't start due to this conflict. By removing the uses clause, you are not telling the platform about the bundle constrains so the bundle does start but the problem still remains as shown above.
    Thanks a lot for your explanation. Yes, I don't need to export the two methods within the Pricing interface and I can still inject the dependency into the PricingImpl class with Spring... Now the examples work correctly!

    Cheers,
    Lofi

    BTW. Don't forget to close the bug given on the top of this discussion

    Comment


    • #17
      Yes, this is true. Does this mean that Spring dm is a bit more "aggresive" by doing the injection? I mean that the "getter methods" will be executed directly within the startup phase?
      As I've explained earlier, the 'greedy' class analysis is caused by using proxying since the weaving process literally has to introspect the target class.

      BTW. Don't forget to close the bug given on the top of this discussion
      Already did that a few days ago.

      Cheers,

      Comment


      • #18
        Another way to get this linkage error is to have a lib on your bundle's classpath containing the same class (package + class name) than one of your runtime bundles.

        Comment

        Working...
        X