Date   

Re: RunLevel Service with optional concurrency

hv@...
 

Yes, that makes sense. I'm already using my own Executor (for other reasons), but as you said - it is unaware of what specifically it is supposed to be executing.

hk2-360 added. Thanks!


Re: RunLevel Service with optional concurrency

jwells131313@...
 

Actually after thinking about it for a second there is no way to figure out from the Runnable passed in which service is going to be executed with it.  This may call for a small mini-feature whereby the Runnable passed to the executors also implement some other interface from which the user can get some sort of indication of which RunLevel service is about to be started.  One issue with even such an interface as that is that not all RunLevel services are started via the executor, as they may also be started by dependency map.  Basically if B depends on A and the RunLevelService decides to start B then it will find the dependency A and start it as well without going through the executor.  So that's not quite the correct solution for that.

So this may need more thought, so perhaps you should enter in an enhancement request!


Re: RunLevel Service with optional concurrency

jwells131313@...
 

There is no feature like this however the building blocks are there for you to provide your own feature like this by using the setExecutor method of the RunLevelController service.  By using your own Executor you can ensure that certain jobs go to certain thread-pools or do whatever priority scheme you have in mind.

Hope this helps and is what you were asking for!


RunLevel Service with optional concurrency

hv@...
 

I'm using the HK2 RunLevel Service (https://javaee.github.io/hk2/runlevel.html) in fully-threaded mode. Sometimes I'd like to start a service with a higher concurrency, ideally indicated through an annotation parameter, e.g. @RunLevel(value = 3, concurrency = 5). The jobs should run within the threadpool of the runlevel controller. I'm not sure if there would be a clash with the default @Singleton scope of runlevel services though.

What do you think? Is this a popular request? Worthy of a feature request?

Thanks,
Henning


Re: Stable version recommendation

jwells131313@...
 

The -bxx releases go through the same amount of testing as do the non -bxx versions.  They should be considered to be stable.

We normally only have a non -bxx release when there will be some major non-backwards compatible API change or if we need to possibly keep a branch stable for a JDK version.

That being said it *has* been a long time since a non -bxx release so it may be time to do it just to checkpoint a more permanent branch.

I'll discuss it with the team today.


Stable version recommendation

hv@...
 

Hello,

probably a stupid question, but would you kindly explain your release strategy? Are the `-bxx` versions intended for "beta" testing only, or are they stable versions ready for production use? I've been using 2.4.0 for a long time now, waiting for the next stable release. Much appreciated!

Cheers, Henning


HK2 has been relocated on Github

romain.grecourt@...
 
Edited

Hello,

We've just moved the HK2 repositories to the new JavaEE organization on Github.

The repositories can now be found at :
 - github.com/javaee/hk2
 - github.com/javaee/hk2-extra

The previous organization is now a placeholder with a link to https://github.com/javaee/hk2

Note that this move will impact you only if you had direct clones of the HK2 repository.
Existing forks should not be impacted.

A new website is also available at https://javaee.github.io/hk2
The java.net redirect should come soon.

Thanks,
Romain


Re: Automatic configuration

Luca Vercelli
 

Thank you, this is exactly what I needed.

Luca


Il 06/06/2017 13:58, jwells131313@... ha scritto:
The *usual* way to do automatic service registration is this:

1.  Put @Service on all classes you want to create as a service (put @Contract on all interfaces or classes that should be advertised)
2.  Use the inhabitant generator during build
3.  Use the populate method of a Populator which you can get from the DynamicConfigurationService

The DynamicConfigurationService is available in every hk2 registry (unless it has been explicitly removed, giving rise to a read-only hk2 registry).

If the above steps are not what you are looking for you can use the other method on Populator to do whatever you want for automatic service registration.

In particular the hk2 testing facility hk2-junitrunner scans all classes in a package.  You can see the code around lines 414 in HK2Runner.java.  The HK2Runner example is going directly to the DynamicConfiguration returned from the DynamicConfigurationService rather than using the Populator but the basic idea is the same.

If you are using the inhabitant generator method during build instead you can do it all in one line with createAndPopulateServiceLocator.

I hope this helps.


Mail priva di virus. www.avast.com


Re: Automatic configuration

jwells131313@...
 

The *usual* way to do automatic service registration is this:

1.  Put @Service on all classes you want to create as a service (put @Contract on all interfaces or classes that should be advertised)
2.  Use the inhabitant generator during build
3.  Use the populate method of a Populator which you can get from the DynamicConfigurationService

The DynamicConfigurationService is available in every hk2 registry (unless it has been explicitly removed, giving rise to a read-only hk2 registry).

If the above steps are not what you are looking for you can use the other method on Populator to do whatever you want for automatic service registration.

In particular the hk2 testing facility hk2-junitrunner scans all classes in a package.  You can see the code around lines 414 in HK2Runner.java.  The HK2Runner example is going directly to the DynamicConfiguration returned from the DynamicConfigurationService rather than using the Populator but the basic idea is the same.

If you are using the inhabitant generator method during build instead you can do it all in one line with createAndPopulateServiceLocator.

I hope this helps.


Automatic configuration

Luca Vercelli
 

Dear group,

I would like to tell hk2 something like this:
"Every class must bind to itself, if not differently specified"
Or
"Every class in a particular package must bind to itself"
Is this possible, out of the box? I was able to obtain the second result using the Reflections framework, however it is slow. I think Glassfish uses the first approach.
Regards

Luca