Announcement Announcement Module
Collapse
No announcement yet.
Multiple expoded jars in work directory when deploying bundle Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Multiple expoded jars in work directory when deploying bundle

    Hello,

    I have a bundle wrapping a third party component which is a relatively large jar file (jar contains ~10.000 files in ~200 folders).
    Putting this jar into the pickup folder I noticed that

    - deployment takes around 4-5 minutes
    - I found that the jar content is extracted multiple times into folder inside the work directory, namely to

    1) workcom.springsource.platform.deployer<mybundle>.j ar
    2) workcom.springsource.platform.deployerModule<mybun dle>.jar-0
    3) workequinox-configorg.eclipse.osgiundles701undlefile
    which might explain the very long deployment time.

    Is this as expected?
    Do I have to do anything specific in my manifest in order to prevent this?

    Help is very much appreciated.

    Regards,
    Eric

  • #2
    Multiple expoded jars in work directory when deploying bundle

    third party jars usually don't have to be put into pickup - except if you want to manually hot-undeploy / redeploy later on. Instead you can just drop it into S2AP/repository/bundles/usr/ - IMO that should also prevent the multiple times extraction...

    Regards
    Kay

    Comment


    • #3
      Multiple expoded jars in work directory when deploying bundle

      Thanks for the hint.

      However this brings me to another problem:
      if I copy the very same bundle (which works when I put it to the pickup folder) into the /repository/bundles/usr/ folder and restart the engine (startup.bat -clean),then it is not working anymore.

      My feeling is that "import bundle" is not working from a bundle in the pickup to an own bundle copied into the repository, i.e. which is not present in the SpringSource repository. Is this possible?

      Besr regards,
      Eric

      Comment


      • #4
        Multiple expoded jars in work directory when deploying bundle

        Yes, you're right: import-bundle only works for bundles in the repository, not for bundles installed through the pick-up or admin console. There is an older post on the forum from Glyn where he explains the rationale. I don't have the link right now, but I do know that you can simply use import-package instead to work around the problem.

        Comment


        • #5
          Multiple expoded jars in work directory when deploying bundle

          Hmmm... Eric, I'm actually not quite sure I understand your hypothesis correctly.
          Whatever bundle you install into /repository/bundles/usr will be available to all other bundles - that includes, that such a bundle and it's exported packages are available to bundles in your pickup directory. After all, that's the main idea: you can put the "common" or "public" bundles to the /repository folder and can refer to them from within your apps, which typically end up in pickup folder.
          You describe that it "does not work anymore" - what exactly do you expect to happen? Is the bundle supposed to start some action? Does the server not start anymore? Can you paste some log output here?

          What Joris describes is probably this problem: https://issuetracker.springsource.com/browse/PLATFORM-102?focusedCommentId=10457#action_10457 - but I'm not sure if it applies in your case.

          Regards
          Kay

          Comment


          • #6
            Multiple expoded jars in work directory when deploying bundle

            Hello,

            first of all, thanks a lot for the helpful comments.

            Indeed, the problem I tried to describe is what you are refering to.
            (the statement that "it is not working anymore" meant there were class loading problems when starting my web application bundle).

            From the mentioned ticket I understood that with version 1.0 this scenario of using import-bundle described above will work in general, right?
            Using the import-package workaround is indeed possible, but requires more work and is error prone for larger third party jars.

            For us, using pars is at the moment somewhat problematic, because we are facing some problems as we would like to build web modules using only standard JSF / facelets without any generated dispatcher servlets which seems to be not possible. Cf. also
            http://www.springsource.com/beta/applicationplatform/comments.php?DiscussionID=239&page=1#Item_4
            My understanding is that the recommended way to use JSF is along the lines of spring faces which is not really convenient for us.
            Please let me know if I got it wrong.

            Best regards,
            Eric

            Comment


            • #7
              Multiple expoded jars in work directory when deploying bundle

              Hi Eric,

              > For us, using pars is at the moment somewhat problematic, because we are facing some problems as
              > we would like to build web modules using only standard JSF / facelets without any generated
              > dispatcher servlets which seems to be not possible.

              Please note that you can add an "empty" Spring ApplicationContext configuration file to your web module (e.g., META-INF/spring/empty-context.xml), and that will result in a Spring MVC DispatcherServlet configuration which simply is not used by your application. This should not have any negative side effects on your web application; however, if the presence of an unused DispatcherServlet bothers you, you can certainly achieve the same goals using a Shared Services WAR.

              The SpringSource Application Platform supports packaging of any web deployment artifact within a PAR. Thus, you can choose between a Web Module and a Shared Services WAR depending on the specific needs of your application.

              > My understanding is that the recommended way to use JSF is along the lines of spring faces which
              > is not really convenient for us.

              Although Spring Faces is recommended, it is certainly not a requirement for JSF development on the Platform. On the S2AP you are free to use your web framework of choice.

              Regards,

              Sam

              Comment

              Working...
              X