[jboss-dev-forums] [Design of POJO Server] - Scanning for resources, annotations, ...

[alesj]

I'm looking at this legacy piece of code

  |    /**
  |     * Scan the current context's classloader to locate any potential sources of Hibernate mapping files.
  |     *
  |     * @throws DeploymentException
  |     */
  |    private void scanForMappings() throws DeploymentException
  |    {
  |       // Won't this cause problems if start() is called from say the console?
  |       // a way around is to locate our DeploymentInfo and grab its ucl attribute
  |       // for use here.
  |       URL[] urls;
  |       ClassLoader cl = Thread.currentThread().getContextClassLoader();
  |       if ( cl instanceof RepositoryClassLoader )
  |       {
  |          urls = ( ( RepositoryClassLoader ) cl ).getClasspath();
  |       }
  |       else if ( cl instanceof URLClassLoader )
  |       {
  |          urls = ( ( URLClassLoader ) cl ).getURLs();
  |       }
  |       else
  |       {
  |          throw new DeploymentException( "Unable to determine urls from classloader [" + cl + "]" );
  |       }
  | 
  |       // Search the urls for each of the classpath entries for any containing
  |       // hibernate mapping files
  |       VirtualFileVisitor visitor = new HibernateMappingVisitor(classpathUrls);
  |       // visit har url if set
  |       if (harUrl != null)
  |          visitURL(harUrl, visitor);
  |       // visit CL urls
  |       for ( int j = 0; j < urls.length; j++ )
  |       {
  |          final URL entry = urls[j];
  |          visitURL(entry, visitor);
  |       }
  |       log.trace("Found mappings: " + classpathUrls);
  |    }
  | 
and I think it's time for us to introduce a uniform way of plugging into deployers to help us with the scanning + caching the results for later usage, before things get out of hand, e.g. dozen new lines of scanning code in every project. :-)

I was able to get around the URLCL issue in Seam, since Pete re-organized the code with more info.
But here I fail to see how to get this thing working w/o breaking existing (user) configuration.
OK, I guess this bean can be made deprecated, but I think it can be a lesson learned - showing how to transform URLCL aware code to do the same with the new VFSCL. Until our uniform way kicks in, of course. ;-)

Not to mention that this code is broken from begining - see the comment. ;-)
And since Adrian just addressed the CL usage to be handled more stricktly, it's another use case example to cover.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122853#4122853

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122853