where are @Parameters loaded from when bootstrapping in SE environment?

20 views Asked by At

There is this example in docs:

import jakarta.inject.Singleton;

@Singleton
public class HelloWorld
{
   public void printHello(@Observes ContainerInitialized event, @Parameters List<String> parameters) {
       System.out.println("Hello " + parameters.get(0));
   }
}

works, but pollutes stdout via shutdown hook:

Weld SE container STATIC_INSTANCE shut down by shutdown hook

Well, it's true, but I don't want that, but I don't want to disable shutdown hook just to avoid this message. So this is no-go.

Then there is this:

import org.jboss.weld.environment.se.Weld;

public static void main(String[] args) {
   Weld weld = new Weld();
   WeldContainer container = weld.initialize();
   container.select(MyApplicationBean.class).get().callBusinessMethod();
   container.shutdown();
}

seems that it does very the same stuff, and if we remove the shutdown, it will even also polute the stdout. So it's almost the same. ONLY it does not register @Parameters List parameters. Where are these coming from? Why are they picked and registered from org.jboss.weld.environment.se.StartMain#PARAMETERS when using when using org.jboss.weld.environment.se.StartMain?

(I'm probably missing something basics (I didn't use weld for many many years), but I want to try weld for simple task where it might be better than spring-core)

1

There are 1 answers

0
Martin Mucha On

IDE did not help me navigate the sources, but grepping works. So StartMain declares public static field (not cool, not overally consistent design) which is accessed by ParametersFactory, which is registered as extension by org.jboss.weld.environment.se.Weld. So this is how it works. Kinda feels like encapsulation design failure, as all of this could have been trivially hidden by one overloaded constructor of Weld class, as it's improbable, that you will need commad-line parameters from elsewhere than main method and initialize weld elsewhere than on immediate app start.