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

[Robert Marcano]

On 01/16/2015 11:05 AM, Jozef Hartinger wrote:
>
> On 01/16/2015 02:35 PM, Robert Marcano wrote:
>>
>> I get this exception when initializing the Weld container, looks like
>> probably related of why JandexIndexBeanArchiveHandler get http urls
>> under IcedTea NetX
> Just wondering: Did you try IcedTea without Jandex?

Yes, but I found the problem, DefaultBeanArchiveScanner is using com.sun 
APIs in order to get the cached JAR path, 
com.sun.jnlp.JNLPClassLoader#getCacheFile(URL). Since NetX does not 
implement that method the mapping from http[s] URL to local file is not 
done, this is why the archive handler was getting the remote URL.

Doing reflection, but using icedtea-web code structure, with this way of 
getting the path works:

> if (jnlpClClass.getName().equals("net.sourceforge.jnlp.runtime.JNLPClassLoader")) {
>     // Try to get field net.sourceforge.jnlp.runtime.JNLPClassLoader#tracker from icedtea-web 1.5
>     Field f = jnlpClassLoader.getClass().getDeclaredField("tracker");
>     f.setAccessible(true);
>     Object tracker = f.get(jnlpClassLoader);
>     // Try to call net.sourceforge.jnlp.cache.ResourceTracker#getCacheFile(URL)
>     Method m = tracker.getClass().getMethod("getCacheFile", URL.class);
>     File jarFile = (File) m.invoke(tracker, new URL(path));
>     return jarFile.getPath();
> } else {
 >     // ... current code
 > }

Too bad that it is not only a public method call, there is an access to 
a private field (tracker).

The icedtea-web 1.5 branch repository history show this field and method 
call to have been stable at least since 2010 when the icedtea-web 1.5 
repository was created, and master haven't changed. I can bet to use 
this patch on my deployments since there is already usage of reflection 
to get the URL on closed source WebStart, it this too hacky for beint 
committed to Weld?

...

>> 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?
> That's very suspicious. Assuming there are no @EJB injection points in
> your application this service should not be called at all. Wasn't it
> EjbServices instead?
>>
>>

True, I added a test @EJB injection, isn't EjbInjectionServices the one 
I should implement in order to inject my remote EJB interfaces? or 
should I implements EJBServices instead?

I used it because of the warning on the documentation:

EJBInjectionServices.resolveEjb(InjectionPoint ij), which allows @EJB 
injection point to be resolved without prior registration was deprecated 
in Weld 2 and should no longer be used. An injection point should be 
registered properly using 
EjbInjectionServices.registerEjbInjectionPoint(InjectionPoint 
injectionPoint) instead.


>>>
>>> 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>>
>