Making Jandex annotation index available to components
by Gunnar Morling
Hi,
---
TL,DR: Hibernate components would like to receive the Jandex index during
deployment. A new method IndexView#close() may help to address concerns
about long-living index view references
---
Different projects from the Hibernate umbrella (e.g. ORM, Validator and
Search) rely heavily on meta-data given via annotations. In order to speed
up annotation retrieval, we are looking into using the Jandex index created
for deployments by the container.
This would require subsystems like JipiJapa or the one for Bean Validation
to pass the IndexView for the deployment to the bootstrapped component. The
change itself should be easy, I hope. But Scott expressed concerns about
components keeping references to the index after the deployment phase has
succeeded. As indexes can be large, this may potentially block a big chunk
of memory for as long as the deployment is running.
Of course we can promise that Hibernate components wouldn't keep such
references ;) But if that's not enough, could this concern be mitigated by
adding a new method IndexView#close()?
This method would free all resources of the index and would be called by
the container after the deployment has finished. Any operation on a closed
index view would throw an exception indicating that the view has been
closed. Then, even if a component accidentally kept a reference to an
IndexView, it wouldn't retain much memory (of course the index view
wouldn't be of much use to the component in that state).
Would that be an acceptable way forward? If so, I could send a pull request
towards Jandex. In a next step WF would have to make use of that new
version and invoke close() on a deployment's index at a suitable time
during the deployment lifecycle and eventually pass the index to ORM et al.
In a subsequent step we may consider to address use cases such as dynamic
reconfiguration which would require to access the index *after* deployment
time. One way for addressing this may be to allow for passing in some kind
of executor which would expect e.g. a Lambda doing work on an IndexView
passed in by the executor. That way components could access the index at
runtime, while not keeping a reference to it themselves and thus allowing
the container to manage the index and e.g. close or re-open it upon
execution. But I think this could be done as a follow-up.
Any thoughts?
Thanks,
--Gunnar
PS: As a side note, Hibernate Validator currently reads annotations lazily
at runtime (when first validating a specific bean type). When using Jandex,
we'd have to change this to eagerly build up all the meta-data for the
types listed in the index passed during bootstrap. A bit of work, but as
said we hope to gain a nice performance improvement from it.
9 years, 1 month
WFLY/WFCORE PRs
by Kabir Khan
Please try to include a link to the Jira in the pull request when opening them. I want to be a good citizen and resolve them when merging, but it is a PITA to have to manually find the Jira issue in the absence of links.
9 years, 1 month
WildFly 10 as Service in RHEL7
by Rogério Luciano Santos
How start wildfly 10 as service in redhat linux 7 ?
In the folder ../bin does not has the folder init.d as wildfly 9.
I did not find the files : wildfly.conf and wildfly-init-redhat
tks
Rogério L Santos
Brazil - SP
9 years, 1 month
Updating components in WildFly
by Gunnar Morling
Hi,
Users of the different Hibernate projects often wish to upgrade their
WildFly installation to the latest releases of Hibernate ORM, Search or
Validator.
For that purpose we began to provide ZIP files containing the newer JARs
and module.xml descriptors, to be unzipped into the server's module
directory. We use separate slot names, so to not overwrite existing modules
but just add newer versions next to them.
But sometimes redefining the default slot actually is desirable. If an
update for instance is just a bugfix release, it's sensible to push this to
the main slot so users can benefit from it without having to explicitly
specify a slot name, suppress any implicit default module and so on.
But as I said we don't want to mess with any existing modules, so I've been
looking into alternatives. One thing I found was to provide the updated
modules in a separate layer, which then overrides the original modules from
the "base" layer, without physically altering them. The user can go back to
the original ones just by removing an entry in layers.conf.
That works nicely, but then I also learned about the patch mechanism. So I
wondered whether that should be the approach for us to follow, e.g. I also
saw that Weld is providing patches for WF. Is this then the officially
recommended way (TM) for upstream projects for shipping easy-to-use updates
of their components for WF?
One thing getting in the way of this is the lack of a Maven plug-in for the
patch-gen tool. This makes patch creation quite unwieldy in an automated
build process. Is there any chance for getting a Maven plug-in for
patch-gen? If there is interest, I'd also be volunteering to provide it, it
shouldn't take too long.
Thanks for any hints,
--Gunnar
9 years, 1 month
