JBossDeveloper

Ales, why should I add it to bootstrap?

I mean, can't I just scan the lib dirs as part of the first weld deployment instead of doing it on bootstrap? What are the advantages of doing otherwise?

Exactly for the reason you have a 2nd question. :-)

Another question: once I determine that a specific jar in lib has the META-INF/beans.xml file, what is the cleanest way of retrieving the corresponding lib ClassLoader?

Adding some "listener" service at bootstrap would mean we could somehow

add a mechanism that would, for every lib added to cl domain, check if there is some beans.xml.

I can look into it what would be the best way to do this.

Unless you wanna do it yourself.

I'll add a fix sometime this week. I plan on reviving the unique name JNDI binder for this.

Message was edited by: Marius Bogoevici. was "next week" which is an unusual portmanteau for "next days, this week".

I can look into it what would be the best way to do this.

Unless you wanna do it yourself.

Thanks! You can go ahead. :-)

OK, I have a few things ready, but now I need to know what do you need to make this work.

Currently I have this in place:

public synchronized Set<BeanDeploymentArchive> getLibraries() throws Exception
   {
      if (libs == null || checked.get() == false)
      {
         List<VirtualFile> excludedFiles = null;

         Map<Module, Set<URL>> modules = provider.getMatchingModules();
         for (Map.Entry<Module, Set<URL>> entry : modules.entrySet())
         {
            Set<URL> urls = entry.getValue();
            if (excludedUrls != null && excludedFiles == null)
            {
               excludedFiles = new ArrayList<VirtualFile>();
               for (URL eu : excludedUrls)
                  excludedFiles.add(VFS.getChild(eu));
            }
            Set<VirtualFile> files = new HashSet<VirtualFile>();
            for (URL u : urls)
            {
               VirtualFile vf = VFS.getChild(u);
               boolean include = true;
               if (excludedFiles != null)
               {
                  for (VirtualFile ef : excludedFiles)
                  {
                     if (vf.getParentFileList().contains(ef))
                     {
                        include = false;
                        break;
                     }
                  }
               }
               if (include)
                  files.add(vf);
            }
            if (files.isEmpty() == false)
            {
               ClassLoader cl = ClassLoading.getClassLoaderForModule(entry.getKey());
               // is this module already installed; past CL stage -- should be
               if (cl != null)
               {
                  // TODO  <----- your input needed here                   
               }
            }
         }
         checked.set(true);
      }
      return libs;
   }

I can now return a set of matching modules, which have beans.xml as part of its resources.

This is mostly aimed at system deployments, though it can serve all deployments.

(it will be disabled once get past PS' DEPLOYERS phase)

Each module is mapped to beans.xml' owners; e.g. some-cdi-lib.jar.

Will this info be enough for you?

Or at which example / use case / code should I look for more info?

Given most of this classes above is package protected, I'll refactor those and write a method that does this internally as part of the API. I'll post back when I'm done.

No need for this, as I can simply move this service into that package.

And if there is really a need, I can hide its impl details later on.

Roughly speaking, this is how we would fill in the gaps of the TODO mark you added in your getLibraries method:

OK, refactored things a bit, I now have this:

                  // create an ArchiveInfo with the ClassLoader
                  ArchiveInfo archiveInfo = new ArchiveInfo(cl);
                  // finally create the Archive
                  Archive archive = ArchiveFactory.createArchive(archiveInfo, new ArrayList<EjbDescriptor<?>>());   
                  // ... and the corresponding BDA
                  ServiceRegistry serviceRegistry = new SimpleServiceRegistry();
                  // TODO: fill in serviceRegistry? With which services?
   
                  libs.add(archive.createBeanDeploymentArchive(serviceRegistry));

                  // the env
                  WeldDiscoveryEnvironment environment = archiveInfo.getEnvironment();
                  // fill in the Weld classes
                  // the WBDiscoveryVisitor from ArchiveDiscoveryDeployer... 
                  ResourceVisitor visitor = environment.visitor();   
                  Module module = entry.getKey();
                  
                  for (VirtualFile child : files)
                  {
                     URL beansXmlURL = child.getChild(provider.getResourceName()).toURL();   
                     environment.addWeldXmlURL(beansXmlURL);
   
                     module.visit(visitor, ClassFilter.INSTANCE, null, child.toURL());   
                  }

It all compiles. :-)

The other piece of code that we are missing is the part that invokes this, right? At some point we need to fill in the DefaultDomain Classpath (take a look at ClasspathFactory for more details) with the lib BDAs created by your getLibraries method. As we agreed before, this should be done ideally at the first weld deployment. So, I would simply add a piece of code to ClasspathFactory that calls getLibraries, unless you prefer this call to be performed somewhere else.

OK, I still need to think about this one a bit.

I think that the best way to check everything is working ok is adding a Weld jar to jboss lib prior to start up and make sure that a BDA is being created for it. Other than that, I don't have any use cases :-).

Yup, I'll create a simple test for this -- probably (until we do have a *real* CDI lib present) I'll have to create a new server config for it.

- we need also a mechanism to scan for libs referenced from manifest files, creating BDAs for any lib that contains META-INF/beans.xml

How is this different from what we're already doing?

Or, I think we're already covering this use case. Or not?

- the library scanning that Ales is working on

Let me know when you're done, as I'm mostly done, but I have a few changes to your code,

to make this integration easier / nicer.