Announcement Announcement Module
Collapse
No announcement yet.
Jar Jar: no can get there from here. Or, schemas for Spring Sec. overwritten in Jar Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jar Jar: no can get there from here. Or, schemas for Spring Sec. overwritten in Jar

    I have written a prototype Swing app which uses classes from:

    Spring core (beans, DAO, etc.)
    Spring RCP
    Spring Security
    Spring LDAP

    I use Spring Security and LDAP within a module I wrote for auth. and interfacing with an LDAP dir. (in our case, Active Dir), to get info about a user (in this particular case, to parse some info from the user info in the dir to know which office the user belongs to - our AD instance has enough info to deduce this).

    This all works fine from the IDE (I use NetBeans GUI builder to help layout some of the UI).

    It works okay from the command line with the app jar along with a 'lib' folder that contains supporting jars (Spring, Apache Commons, etc.).

    But when I build to a standalone jar (with ANT), one that contains all of the supporting classes, one jar to rule them all (no other files needed), then I ran into problems.

    The problem (as I understand it) is twofold:


    1) You cannot (yet) use jars that are embedded inside other jars. I am not even sure how to do that in ANT - *if* you can do that in ANT. I understand that there is a JSR out there for the future (called JAM?) that may resolve this, but I did a quick google of the issue, and could not find any solutions. So a standalone jar essentially involves unpackaging all jars and putting their contents into the one jar.

    No jar jars (pun intended).

    2) The main problem is that, as you probably know, the various Spring projects define the XSD schemas and namespace handler mappings in two files in the META-INF folder of the jars.

    For each Spring jar these files, 'spring.schemas' and 'spring.handlers', are the same names and same location. So the last jar to be packaged overwrites any previous files. This doesn't cause a problem if you only use core Spring projects AND use the all encompassing 'Spring.jar', except for the fact that you may experience bloat and inefficiency if you only wanted a small subset of the core projects.

    However, if you want to use another non-core project, say Spring Security, with Spring core, and you reference the core XSD (say beans) and the Security XSD, then you can't because one will overwrite the other because the files are in the same relative path to the root and named the same. In my case, the core overwrites the Security mappings and when I run the app it complains that it can't find the namespace handler for security because Spring doesn't see it in the mappings.

    Solutions?

    I don't want to manually add the Security mappings to the core - that seems like a crude and fragile solution. I suppose the various Spring projects could be added to the core, or better yet, maybe the files could be named relative to the project so they don't get overwritten? Or they could be located in a different place? Something else? Just throwing out ideas off the top of my head without looking at how these are resolved. Maybe I should look at a custom resolver? I seem to recall something about those - or am I barking up the wrong tree?

    In short is there something easy I am missing here? I did a search on the forums and got a few hits on similar problems, but nothing specific with regards to this particular problem.

    Or can I not get there from here?

    Thanks.

  • #2
    From what I gather, the 'fat-jar' plugin for Eclipse, may help Eclipse users, but not Netbean users. I read that it has a special classloader (one-jar?) that can facilitate jars in jars, but I didn't dig any further for two reasons:

    1) I think this should be resolved in Spring projects. We shouldn't require major workarounds to get the separate projects to work together in this environment.

    2) THis solution leaves NB users out in the cold for now. I personally prefer Eclipse, but I am currently giving NB a shake down for various reasons and would like to resolve this there too (other people in my dev team use NB).

    Comment


    • #3
      I don't understand why you're doing what you're doing, or why you think Spring should "fix" something. I don't think unwrapping and consolidating into a single "fat" JAR is a typical deployment scenario.

      That said, I suppose you could do some pre- or post-processing to concatenate the 2 files you mentioned... That's all I can think of.

      Comment


      • #4
        Originally posted by pmularien View Post
        I don't understand why you're doing what you're doing, or why you think Spring should "fix" something. I don't think unwrapping and consolidating into a single "fat" JAR is a typical deployment scenario.

        That said, I suppose you could do some pre- or post-processing to concatenate the 2 files you mentioned... That's all I can think of.
        I disagree. Single jar java apps are *very* common. Maybe not in some dev environments, but for small command line apps (for example, we write a lot of little file processing apps that are standalone jars deployed as such) and desktop Swing/SWT apps, it is a common deployment scenario.

        If there is some way to embed jars within jars, into a standalone app without a custom classloader (and have the embedded jar classes work), please let me know and I will give it a try. Otherwise the fact that Spring schemas for the various projects get overwritten in the typical ANT building of a 'fat' jar, makes this a problem for anyone who wants a 'fat' jar using non-core Spring projects.

        I don't think a dev team should need to use a custom classloader, or write custom pre/post build processes to deploy Spring in such a scenario.

        *That* is why I think this is a Spring problem - indeed, I think it is core to how Spring works - the use of beans configured via XML which in turn depends on XSDs/namespaces.

        I can understand the schema/handler mappings being put in a standard location with a standard file name, I am just saying that in the not uncommon scenario it causes a problem. If there is some other solution that is straight-forward and not a kludge, I am all for hearing about it. Which is why I asked here - surely I am not the only dev to have run into this problem.

        Comment


        • #5
          can't you try like merging the schema infoamtion in one file and unjar the last jar and put that there and jar again and use it....

          Is it a crazy idea... i don't know what i ma sugeesting is right or wrong.

          Can someone try this.

          Comment


          • #6
            Originally posted by completeajay View Post
            can't you try like merging the schema infoamtion in one file and unjar the last jar and put that there and jar again and use it....

            Is it a crazy idea... i don't know what i ma sugeesting is right or wrong.

            Can someone try this.

            Yes, certainly you can merge the mappings manually in one way or another and it would work. But that is kludgey in that it is not robust for even just a single dev. The problem is that this works until you need to update one or more of the Spring jars and then you need to remember that the mappings have to be merged (or checked for merging).

            It gets even better with more than one dev where you have to then all work from the same Spring jars (not always possible, sometimes you need different version - like for one project for a JasperServer integration, I need to use Acegi, not Spring Security because JS always uses old versions of frameworks), and other coordination issues, not to mention automated builds and creating 'fat' jars that are as skinny as possible (only use the jars they really need), not to mention getting into Jar hell with two different versions of the same Jar.

            What I am asking for is whether I am missing some simple and easy solution for this problem. I often am guilty of this which is why I ask for help in public forums.

            It sounds to me like there isn't a straight forward solution (for me) with the current structure of Spring jars. I just wanted to be sure.

            Thanks everybody.

            Comment

            Working...
            X