Re: [weld-dev] Jandex

[Emily Jiang]

Thank you Martin for the info! I saw this statement in Weld release page:

Weld is now capable of using
bytecode-scanning utilities, such as the Jandex tool, to speed up deployment. This is especially notable in extra
large deployments (e.g. 5000+ classes) where we observed up to 20% faster
deployment.

I guess this particularly related to provide ClassFileServices service in Weld integration. Is this figure for the dynamic generating index files or index files were pregenerated? I guess if generating the index files on the fly, it might be slower than prepackaged scenarios. Do you know whether the performance difference is noticeable?

Thanks EmilyEmily JiangWebSphere Application Server, MicroProfile Development Lead


Phone: 44-1962-816278

E-mail: emiji...@uk.ibm.comTwitter: @emilyfhjiang

IBM United Kingdom Limited 
Registered in England and Wales with number 741598 
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU-weld-dev-boun...@lists.jboss.org wrote: -To: Emily Jiang , weld-dev@lists.jboss.orgFrom: Martin Kouba Sent by: weld-dev-boun...@lists.jboss.orgDate: 11/16/2017 04:19PMSubject: Re: [weld-dev] JandexHi Emily,AFAIK WildFly makes use of existing Jandex indexes and if not present a new one is build on the fly (for deployment and external modules) but the generated indexes are not persisted.But in WildFly not only Weld leverages the indexes - all other annotation-based technologies should use them too.MartinDne 15.11.2017 v 14:47 Emily Jiang napsal(a):> Hi Martin/Matej,> For using Jandex to improve bootstrap performance of CDI application, do > you know any application server (e.g. Wildfly) normally requires the > index files to be generated before hand or it can generate on the fly > and then persist it? Do you know whether there is much performance gain > to generate the index files on the fly and then persist it when compared > with not doing it at all (by passing jandex)?> Thanks> Emily> > Emily Jiang> > WebSphere Application Server, MicroProfile Development Lead> Phone: 44-1962-816278> E-mail: emiji...@uk.ibm.com > Twitter: @emilyfhjiang> IBM United Kingdom Limited> Registered in England and Wales with number 741598> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU> Unless stated otherwise above:> IBM United Kingdom Limited - Registered in England and Wales with number > 741598.> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU> > > > ___> weld-dev mailing list> weld-dev@lists.jboss.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U=sLJnARaFsXVHvYjOf0czOZ0itOZijjUXXNMpnP1j0h0=SBhF8e2Ck0XKoYRnv3UQaHjegnrwjbYvMq3Nc5fbkKI=> ___weld-dev mailing listweld-dev@lists.jboss.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U=sLJnARaFsXVHvYjOf0czOZ0itOZijjUXXNMpnP1j0h0=SBhF8e2Ck0XKoYRnv3UQaHjegnrwjbYvMq3Nc5fbkKI=Unless stated otherwise above:IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Jandex

[Martin Kouba]

Hi Emily,

AFAIK WildFly makes use of existing Jandex indexes and if not present a 
new one is build on the fly (for deployment and external modules) but 
the generated indexes are not persisted.

But in WildFly not only Weld leverages the indexes - all other 
annotation-based technologies should use them too.

Martin

Dne 15.11.2017 v 14:47 Emily Jiang napsal(a):
> Hi Martin/Matej,
> For using Jandex to improve bootstrap performance of CDI application, do 
> you know any application server (e.g. Wildfly) normally requires the 
> index files to be generated before hand or it can generate on the fly 
> and then persist it? Do you know whether there is much performance gain 
> to generate the index files on the fly and then persist it when compared 
> with not doing it at all (by passing jandex)?
> Thanks
> Emily
> 
> Emily Jiang
> 
> WebSphere Application Server, MicroProfile Development Lead
> Phone: 44-1962-816278
> E-mail: emiji...@uk.ibm.com 
> Twitter: @emilyfhjiang
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Jandex

[Emily Jiang]

 
Hi Martin/Matej,
 
For using Jandex to improve bootstrap performance of CDI application, do you know any application server (e.g. Wildfly) normally requires the index files to be generated before hand or it can generate on the fly and then persist it? Do you know whether there is much performance gain to generate the index files on the fly and then persist it when compared with not doing it at all (by passing jandex)?
ThanksEmilyEmily JiangWebSphere Application Server, MicroProfile Development Lead
Phone: 44-1962-816278
E-mail: emiji...@uk.ibm.comTwitter: @emilyfhjiang
IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AUUnless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] jandex not used on JNLP applications (Windows)

[Robert Marcano]

On 01/16/2015 03:27 AM, Jozef Hartinger wrote:
 Hi Robert,

 the change sounds good to me.

The first one or removing entirely the jar extension check?

 As for IcedTea we never got Weld running
 with it. Last time we tried we got blocked by
 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1733 If you can
 help us with IcedTea support that would be very appreciated.

Sure. I am starting to see what to do with IcedTea. That bug doesn't 
trigger here, our JNLP file is parsed perfectly.

I get this exception when initializing the Weld container, looks like 
probably related of why JandexIndexBeanArchiveHandler get http urls 
under IcedTea NetX

java.util.NoSuchElementException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1431)
at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
at 
org.jboss.weld.environment.deployment.WeldDeployment.loadBeanDeploymentArchive(WeldDeployment.java:55)
at 
org.jboss.weld.util.DeploymentStructures.getOrCreateBeanDeployment(DeploymentStructures.java:37)
at 
org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:73)
at 
org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:349)
at 
org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:149)



 Btw did you get better performance with Jandex index?

Yes I managed to trim 2 seconds of loading time. I resorted to do the 
Weld initialization explicitly instead of launching the applications 
using the Weld provided launcher, that way I can open the login window 
in parallel to the container initialization that way that time is hidden 
meanwhile the user is typing the credentials. I am using only a few 
beans for testing the technology on a big application, I only enabled it 
on a relatively medium archive, with only a few beans and using 
bean-discovery-mode=annotated instead of allowing it to search the 
entire archive. I still think 2 seconds is too much for such a small 
amount of beans, afraid if could take longer when used fully, too bad 
Weld can't do more incrementally, probably because it need to knows 
everything before resolving an injection point.

Using jandex without pregenerated indexed was slower, I didn't look why, 
I didn't found any saved external index file either, so I think it was 
generating the index everytime, probably because of the file/directory 
confusion too.

I added a simple test for a EjbInjectionServices and notice that it is 
called at initialization time, Is there a reason this too had to be done 
at initialization instead of lazily the first time the injection point 
is found?



 Jozef

 On 01/15/2015 03:17 PM, Robert Marcano wrote:
 Greetings, I am new to using Weld on an Java SE environment, trying to
 optimized the container initialization, I got help on the developer IRC
 channel telling me to add jandex as a dependency. I found that jandex
 indexes could be embedded on jars so I did that. for some reason I got
 worse times after adding the dependency. The problem is that Oracle
 WebStart implementation doesn't store cached Jar files with the jar
 extension anymore.

 JandexIndexBeanArchiveHandler is looking for path with the .jar ending
 to detect if it is a Jar or directory path [1]. Changing that line to:

 if (urlPath.toLowerCase().endsWith(.jar) || new
 File(urlPath).isFile())
 This solve the problem and now the embedded jandex indexes are used (log
 confirmed) on Oracle WebStart implementation. I am not sure about just
 using:

 if (new File(urlPath).isFile())
 I think that checking for the .jar ending is redundant, opinions before
 submitting a patch?

 Note: I still have a problem with IcedTea NetX where
 JandexIndexBeanArchiveHandler get the http url of the jar file, it
 doesn't get a path to the local cached file. Any guide of where I should
 look at on Weld source code is welcome.


 [1]
 https://github.com/weld/core/blob/master/environments/common/src/main/java/org/jboss/weld/environment/deployment/discovery/jandex/JandexIndexBeanArchiveHandler.java#L122

 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev


___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] jandex not used on JNLP applications (Windows)

[Jozef Hartinger]

Hi Robert,

the change sounds good to me. As for IcedTea we never got Weld running 
with it. Last time we tried we got blocked by 
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1733 If you can 
help us with IcedTea support that would be very appreciated.

Btw did you get better performance with Jandex index?

Jozef

On 01/15/2015 03:17 PM, Robert Marcano wrote:
 Greetings, I am new to using Weld on an Java SE environment, trying to
 optimized the container initialization, I got help on the developer IRC
 channel telling me to add jandex as a dependency. I found that jandex
 indexes could be embedded on jars so I did that. for some reason I got
 worse times after adding the dependency. The problem is that Oracle
 WebStart implementation doesn't store cached Jar files with the jar
 extension anymore.

 JandexIndexBeanArchiveHandler is looking for path with the .jar ending
 to detect if it is a Jar or directory path [1]. Changing that line to:

 if (urlPath.toLowerCase().endsWith(.jar) || new File(urlPath).isFile())
 This solve the problem and now the embedded jandex indexes are used (log
 confirmed) on Oracle WebStart implementation. I am not sure about just
 using:

 if (new File(urlPath).isFile())
 I think that checking for the .jar ending is redundant, opinions before
 submitting a patch?

 Note: I still have a problem with IcedTea NetX where
 JandexIndexBeanArchiveHandler get the http url of the jar file, it
 doesn't get a path to the local cached file. Any guide of where I should
 look at on Weld source code is welcome.


 [1]
 https://github.com/weld/core/blob/master/environments/common/src/main/java/org/jboss/weld/environment/deployment/discovery/jandex/JandexIndexBeanArchiveHandler.java#L122
 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev

___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] jandex not used on JNLP applications (Windows)

[Robert Marcano]

Greetings, I am new to using Weld on an Java SE environment, trying to 
optimized the container initialization, I got help on the developer IRC 
channel telling me to add jandex as a dependency. I found that jandex 
indexes could be embedded on jars so I did that. for some reason I got 
worse times after adding the dependency. The problem is that Oracle 
WebStart implementation doesn't store cached Jar files with the jar 
extension anymore.

JandexIndexBeanArchiveHandler is looking for path with the .jar ending 
to detect if it is a Jar or directory path [1]. Changing that line to:

 if (urlPath.toLowerCase().endsWith(.jar) || new File(urlPath).isFile())

This solve the problem and now the embedded jandex indexes are used (log 
confirmed) on Oracle WebStart implementation. I am not sure about just 
using:

 if (new File(urlPath).isFile())

I think that checking for the .jar ending is redundant, opinions before 
submitting a patch?

Note: I still have a problem with IcedTea NetX where 
JandexIndexBeanArchiveHandler get the http url of the jar file, it 
doesn't get a path to the local cached file. Any guide of where I should 
look at on Weld source code is welcome.


[1] 
https://github.com/weld/core/blob/master/environments/common/src/main/java/org/jboss/weld/environment/deployment/discovery/jandex/JandexIndexBeanArchiveHandler.java#L122
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev