| Hi, I've been trying in the last couple of days now to setup weld to work with an embedded undertow, and resteasy; And came across several issues / insights which I'd like to share. #1 - WeldServletLifecycle Is this class intended to provide a "CDI 2" setup? #2 - WeldServletLifecycle#initialize
- This method JavaDoc signature is off. The method either throws an error, or returns true.
- The createDeployment method will create a deployment for Weld with an inconsistent behaviour, meaning, it will only work properly, if a beans.xml file is present, even though this file is optional accroding to the specs.
#3 - When configuring an embedded setup the docs states that "resteasy.injector.factory" isn't needed with v3 container, which isn't quite right.
When using an embedded setup such as this one, the docs can be misleading.
Perhaps the docs can be made clear that this isn't the case with embedded setup? #4 - Gotcha
- If a beans.xml file isn't found, then a base folder cannot be established for the possible beans candidates.
This happens in several workflows (running the code via Gradle / Intellij), and they are both focused (from what I could tell around AbstractDiscoveryStrategy.java#93)
The only thing that made Weld to properly work, is to use this gradle source set setup: sourceSets {
main { output.resourcesDir = 'build/out' output.classesDir = 'build/out' } } Looking at AbstractDiscoveryStrategy.java#L119-L139 it appears that as long as there were no beans.xml found (since WebAppBeanArchiveScanner is used), line 138 will never get called.
If however a property existed which stated the package to scan for beans candidate (as opposed to relying on beans.xml to establish that) it could have been used by FileSystemBeanArchiveHandler for example. If any of this isn't clear, please let me know. P.S there is a repo I setup illustrating my implementation of the stack mentioned here. |
