1 2 Previous Next 15 Replies Latest reply on Dec 2, 2006 12:47 PM by Anil Saldanha

    Cleaned up security project

    Scott Stark Master

      I cleaned up the security project by dropping all jbossbuild stuff and setting the pom versioin to 2.0.0.snaphost. I also simplified the group id to just jboss. I also updated some of the out of date jboss dependencies, and dropped a number of jars from the eclipse project classpath. We still need to cleanup the jbossas jars as we are pulling too many of these into the security project.

        • 1. Re: Cleaned up security project
          Anil Saldanha Master

          Some dependencies like XB have not really updated the maven artifacts.

          I cannot build because I am pulling in

          jboss/jbossxb/jbossxb/1.0.1.TEST


          which defines a dependency on
          <dependency>
           <groupId>jboss.common.core</groupId>
           <artifactId>jboss-common-core</artifactId>
           <version>1.0.1.TEST</version>
           <scope>compile</scope>
          </dependency>
          

          which does not exist.

          What should be done here?

          Maybe XB should do a maven update.

          • 2. Re: Cleaned up security project
            Scott Stark Master

            There is no 1.0.1.TEST jboss-common-core so this dependency is wrong. There are two jbossxbs: one with a group id of jboss.jbossxb and another with a group id of jboss. We need to cleanup the maven repository and adopt a common group id convention of just jboss.

            My security trunk is building, but it must be due to having built jbossxb and populating the local repository. We need a valid jbossxb release to the maven repo. I'll create a jira issue in jbossxb to get this done.

            • 3. Re: Cleaned up security project
              Anil Saldanha Master

              For the time being, I changed the pom for xb for 1.0.1.TEST to use

               <dependency>
               <groupId>jboss</groupId>
               <artifactId>jboss-common-core</artifactId>
               <version>2.0.2.GA</version>
               <scope>compile</scope>
               </dependency>
              


              Once xb creates a formal maven release, we can update it.

              • 4. Re: Cleaned up security project
                Scott Stark Master

                Actually I can find some jboss common 1.0.1.TEST artifacts under here for example:

                http://repository.jboss.com/maven2/jboss/logging/jboss-logging-spi/1.0.1.TEST/

                but I can't believe these are valid. The maven repo is just garbage right now.

                • 5. Re: Cleaned up security project
                  Anil Saldanha Master

                  Not totally. All the xxx.xxx.TEST maven stuff is what Ruel did for POC.

                  So those projects need to have a formal maven release into the repo and all the xxx.TEST stuff thrown away.

                  • 6. Re: Cleaned up security project
                    Scott Stark Master

                    Another dependency that still needs to be cleaned up are these jbossas references:

                     <dependency>
                     <groupId>jboss</groupId>
                     <artifactId>jboss-j2ee</artifactId>
                     <version>SNAPSHOT</version>
                     </dependency>
                     <dependency>
                     <groupId>jboss</groupId>
                     <artifactId>jboss-j2se</artifactId>
                     <version>5.0-SNAPSHOT</version>
                     </dependency>
                     <dependency>
                     <groupId>jboss</groupId>
                     <artifactId>jboss-system</artifactId>
                     <version>5.0-SNAPSHOT</version>
                     </dependency>
                     <dependency>
                     <groupId>jboss</groupId>
                     <artifactId>jboss-transaction</artifactId>
                     <version>5.0-SNAPSHOT</version>
                     </dependency>
                     <dependency>
                     <groupId>jboss</groupId>
                     <artifactId>jboss</artifactId>
                     <version>5.0-SNAPSHOT</version>
                     </dependency>
                     <dependency>
                     <groupId>jboss</groupId>
                     <artifactId>jnpserver</artifactId>
                     <version>5.0-SNAPSHOT</version>
                     </dependency>
                     <dependency>
                     <groupId>jboss</groupId>
                     <artifactId>jboss-mbeans</artifactId>
                     <version>5.0-SNAPSHOT</version>
                     </dependency>
                    


                    Some should just be removed and the security project refactored to remove the dependency. Others need the jbossas project to be splitup.


                    • 7. Re: Cleaned up security project
                      Scott Stark Master

                       

                      "anil.saldhana@jboss.com" wrote:
                      Not totally. All the xxx.xxx.TEST maven stuff is what Ruel did for POC.

                      So those projects need to have a formal maven release into the repo and all the xxx.TEST stuff thrown away.


                      Yes. jbossxb has no valid maven release so I'll see what I can do about that today.

                      • 8. Re: Cleaned up security project
                        Scott Stark Master

                        Check that you can build trunk with the latest pom.xml. It has been updated to refer to the jbossxb-1.0.0.CR8 release which I created from the jbossxb-1.0.0.CR7 tag and just fixed the maven dependencies.

                        • 9. Re: Cleaned up security project
                          Anil Saldanha Master

                          I can build the trunk.

                          I am going to be creating the sub projects in security along the lines of common. This will also make the dependencies matrix much clearer.

                          Thanks for doing the xb release as well as the research on maven publish to repositories(we need that)

                          • 10. Re: Cleaned up security project
                            Anil Saldanha Master

                            As part of http://jira.jboss.com/jira/browse/SECURITY-25, I created sub projects under security (security-spi, security-jboss-sx and security-optional) along the lines of the "common" project.

                            The optional sub project is currently empty.

                            I was not able to remove the aforementioned dependencies unless we start moving the low priority code into the optional subproject.

                            When I removed the class "org.jboss.security.auth.login.LoginConfigInterceptor", I was able to get the MBeans dependency out
                            


                            Do you remember why Dimitris wrote this interceptor?

                            • 11. Re: Cleaned up security project
                              Scott Stark Master

                              The jboss-transaction dependency is due to a simple utility class that really should be in the common or some j2ee util.

                              The LoginConfigInterceptor was a prototype to look at being able to introduce security configs by finding a login-config.xml in the deployment. Its obsolete for jboss5 and the vdf, and should in fact be a security config deployer in jbossas, not in the security project.

                              • 12. Re: Cleaned up security project
                                Anil Saldanha Master

                                 

                                "scott.stark@jboss.org" wrote:
                                The jboss-transaction dependency is due to a simple utility class that really should be in the common or some j2ee util.

                                The LoginConfigInterceptor was a prototype to look at being able to introduce security configs by finding a login-config.xml in the deployment. Its obsolete for jboss5 and the vdf, and should in fact be a security config deployer in jbossas, not in the security project.


                                The jboss-transaction dependency is due to DatabaseServerLoginModule. I already removed the LoginConfigInterceptor.

                                By the way, do you think it is worthwhile to basically list some of the classes with some of the doubtful dependencies, such that you can comment on where in jbas, it can be refactored?

                                • 13. Re: Cleaned up security project
                                  Scott Stark Master

                                  We need to list all the code pulling in the jbossas dependencies and then either rewrite it to avoid it, move it, or provide a legitimate jbossas spi jar. So yes, let's do that.

                                  • 14. Re: Cleaned up security project
                                    Anil Saldanha Master

                                    Some more:

                                    <artifactId>jboss-system</artifactId>
                                    
                                    All the ServiceMBeanSupport extended MBean services are affected
                                    


                                    Looks like jboss-system has a dependency on jboss-j2se, because removal of jboss-j2se makes ServiceMBeanSupport unhappy due to dependence on org.jboss.mx.util.JBossNotificationBroadcasterSupport

                                    <artifactId>jnpserver</artifactId>
                                    
                                    All the naming provide context factories choke (org.jboss.security.jndi)
                                    


                                    I do not think we need jboss.jar. so that can be removed.

                                    1 2 Previous Next