1 2 Previous Next 15 Replies Latest reply on Dec 2, 2006 12:47 PM by anil.saldhana

    Cleaned up security project

    starksm64

      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.saldhana

          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
            starksm64

            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.saldhana

              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
                starksm64

                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.saldhana

                  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
                    starksm64

                    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
                      starksm64

                       

                      "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
                        starksm64

                        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.saldhana

                          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.saldhana

                            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
                              starksm64

                              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.saldhana

                                 

                                "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
                                  starksm64

                                  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.saldhana

                                    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