From robert at marcanoonline.com  Thu Jan 15 09:17:26 2015
From: robert at marcanoonline.com (Robert Marcano)
Date: Thu, 15 Jan 2015 09:47:26 -0430
Subject: [weld-dev] jandex not used on JNLP applications (Windows)
Message-ID: <54B7CBF6.8000306@marcanoonline.com>

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

From jharting at redhat.com  Fri Jan 16 02:57:11 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 16 Jan 2015 08:57:11 +0100
Subject: [weld-dev] jandex not used on JNLP applications (Windows)
In-Reply-To: <54B7CBF6.8000306@marcanoonline.com>
References: <54B7CBF6.8000306@marcanoonline.com>
Message-ID: <54B8C457.6080904@redhat.com>

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


From robert at marcanoonline.com  Fri Jan 16 08:35:38 2015
From: robert at marcanoonline.com (Robert Marcano)
Date: Fri, 16 Jan 2015 09:05:38 -0430
Subject: [weld-dev] jandex not used on JNLP applications (Windows)
In-Reply-To: <54B8C457.6080904@redhat.com>
References: <54B7CBF6.8000306@marcanoonline.com> <54B8C457.6080904@redhat.com>
Message-ID: <54B913AA.4030807@marcanoonline.com>

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


From jharting at redhat.com  Fri Jan 16 10:35:47 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 16 Jan 2015 16:35:47 +0100
Subject: [weld-dev] jandex not used on JNLP applications (Windows)
In-Reply-To: <54B913AA.4030807@marcanoonline.com>
References: <54B7CBF6.8000306@marcanoonline.com> <54B8C457.6080904@redhat.com>
	<54B913AA.4030807@marcanoonline.com>
Message-ID: <54B92FD3.90306@redhat.com>


On 01/16/2015 02:35 PM, Robert Marcano wrote:
> 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?
Removing the 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
Just wondering: Did you try IcedTea without Jandex?
>
> 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.
Correct, we need to scan and verify everything at once.
>
> 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?
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?
>
>
>>
>> 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
>>
>


From robert at marcanoonline.com  Fri Jan 16 11:25:47 2015
From: robert at marcanoonline.com (Robert Marcano)
Date: Fri, 16 Jan 2015 11:55:47 -0430
Subject: [weld-dev] jandex not used on JNLP applications (Windows)
In-Reply-To: <54B92FD3.90306@redhat.com>
References: <54B7CBF6.8000306@marcanoonline.com> <54B8C457.6080904@redhat.com>
	<54B913AA.4030807@marcanoonline.com> <54B92FD3.90306@redhat.com>
Message-ID: <54B93B8B.9070608@marcanoonline.com>

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
>>>
>>
>


From jharting at redhat.com  Tue Jan 20 09:27:08 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Tue, 20 Jan 2015 15:27:08 +0100
Subject: [weld-dev] Weld 2.2.9.Final
Message-ID: <54BE65BC.4000608@redhat.com>

https://developer.jboss.org/thread/251740

From robert at marcanoonline.com  Thu Jan 22 08:35:27 2015
From: robert at marcanoonline.com (Robert Marcano)
Date: Thu, 22 Jan 2015 09:05:27 -0430
Subject: [weld-dev] JPA injection points validations
Message-ID: <54C0FC9F.6000004@marcanoonline.com>

I have noticed that all *InjectionServices javadoc say that those 
implementations should do the required injection point validations. for 
example JpaInjectionServices

"Register a persistence context injection point. The implementation 
validates the injection point ..."

But for some reason if a JpaInjectionServices implementation is 
registered, an internal validation is triggered

"WELD-001517: The type of the resource producer field 
[[BackedAnnotatedField] @PersistenceContext private 
com.example.TestBean.session] does not match the resource type interface 
javax.persistence.EntityManager" See [1]

This field class is an Hibernate session, Wildfly support injecting that 
using @PersistentContext [2], but this validations is blocking me to do 
the same in a mock test environment I am coding. I am not sure how 
Wildfly inject it with Weld or if they skip Weld injecting JPA instances 
because of this. Why this validation is harcoded on Weld, when for 
example EjbInjectionServices doesn't force any predefined validation?

Shouldn't it be removed and leave that validation to the 
JpaInjectionServices implementation as the javadoc say it is its 
responsibility?.


[1] 
https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/injection/ResourceInjectionFactory.java#L306
[2] 
https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-InjectionofHibernateSessionandSessionFactoryInjectionofHibernateSessionandSessionFactory

From jharting at redhat.com  Thu Jan 22 10:22:36 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 22 Jan 2015 16:22:36 +0100
Subject: [weld-dev] JPA injection points validations
In-Reply-To: <54C0FC9F.6000004@marcanoonline.com>
References: <54C0FC9F.6000004@marcanoonline.com>
Message-ID: <54C115BC.1080905@redhat.com>

Validation *is* done by *InjectionServices. However, the 
JpaInjectionServices SPI is built with the following assumption of types:

@PersistenceContext -> EntityManager
@PersistenceUnit -> EntityManagerFactory

which seems as a reasonable assumption given that e.g. 
@PersistenceContext Javadoc says that:

"Expresses a dependency on a container-managed *EntityManager*"

All the other validation is left for the service implementation. For the 
other *InjectionServices, no validation (even the type) is performed by 
Weld.

HTH,

Jozef

On 01/22/2015 02:35 PM, Robert Marcano wrote:
> I have noticed that all *InjectionServices javadoc say that those
> implementations should do the required injection point validations. for
> example JpaInjectionServices
>
> "Register a persistence context injection point. The implementation
> validates the injection point ..."
>
> But for some reason if a JpaInjectionServices implementation is
> registered, an internal validation is triggered
>
> "WELD-001517: The type of the resource producer field
> [[BackedAnnotatedField] @PersistenceContext private
> com.example.TestBean.session] does not match the resource type interface
> javax.persistence.EntityManager" See [1]
>
> This field class is an Hibernate session, Wildfly support injecting that
> using @PersistentContext [2], but this validations is blocking me to do
> the same in a mock test environment I am coding. I am not sure how
> Wildfly inject it with Weld or if they skip Weld injecting JPA instances
> because of this. Why this validation is harcoded on Weld, when for
> example EjbInjectionServices doesn't force any predefined validation?
>
> Shouldn't it be removed and leave that validation to the
> JpaInjectionServices implementation as the javadoc say it is its
> responsibility?.
>
>
> [1]
> https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/injection/ResourceInjectionFactory.java#L306
> [2]
> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-InjectionofHibernateSessionandSessionFactoryInjectionofHibernateSessionandSessionFactory
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev


From smarlow at redhat.com  Thu Jan 22 10:37:39 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 22 Jan 2015 10:37:39 -0500
Subject: [weld-dev] JPA injection points validations
In-Reply-To: <54C0FC9F.6000004@marcanoonline.com>
References: <54C0FC9F.6000004@marcanoonline.com>
Message-ID: <54C11943.1030903@redhat.com>

Do you really want the Hibernate session?  Keep in mind that it is 
managed by the EE container and will be closed when the transaction 
completes or the component invocation ends.

You can also call 
entityManagerFactory.unwrap(org.hibernate.SessionFactory.class) to get 
the session factory or entityManager.unwrap(org.hibernate.session.class 
to get the session.

On 01/22/2015 08:35 AM, Robert Marcano wrote:
> I have noticed that all *InjectionServices javadoc say that those
> implementations should do the required injection point validations. for
> example JpaInjectionServices
>
> "Register a persistence context injection point. The implementation
> validates the injection point ..."
>
> But for some reason if a JpaInjectionServices implementation is
> registered, an internal validation is triggered
>
> "WELD-001517: The type of the resource producer field
> [[BackedAnnotatedField] @PersistenceContext private
> com.example.TestBean.session] does not match the resource type interface
> javax.persistence.EntityManager" See [1]
>
> This field class is an Hibernate session, Wildfly support injecting that
> using @PersistentContext [2], but this validations is blocking me to do
> the same in a mock test environment I am coding. I am not sure how
> Wildfly inject it with Weld or if they skip Weld injecting JPA instances
> because of this. Why this validation is harcoded on Weld, when for
> example EjbInjectionServices doesn't force any predefined validation?
>
> Shouldn't it be removed and leave that validation to the
> JpaInjectionServices implementation as the javadoc say it is its
> responsibility?.
>
>
> [1]
> https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/injection/ResourceInjectionFactory.java#L306
> [2]
> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-InjectionofHibernateSessionandSessionFactoryInjectionofHibernateSessionandSessionFactory
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>

From robert at marcanoonline.com  Thu Jan 22 10:59:30 2015
From: robert at marcanoonline.com (Robert Marcano)
Date: Thu, 22 Jan 2015 11:29:30 -0430
Subject: [weld-dev] JPA injection points validations
In-Reply-To: <54C115BC.1080905@redhat.com>
References: <54C0FC9F.6000004@marcanoonline.com> <54C115BC.1080905@redhat.com>
Message-ID: <54C11E62.2030208@marcanoonline.com>

I haven't found a way to override Weld detection of the @Persistence* 
annotations, or add a new one, I may be wrong but probably Wildfly just 
doesn't delegate to Weld for @Persistence*

On 01/22/2015 10:52 AM, Jozef Hartinger wrote:
> Validation *is* done by *InjectionServices. However, the
> JpaInjectionServices SPI is built with the following assumption of types:
>
> @PersistenceContext -> EntityManager
> @PersistenceUnit -> EntityManagerFactory
>
> which seems as a reasonable assumption given that e.g.
> @PersistenceContext Javadoc says that:
>
> "Expresses a dependency on a container-managed *EntityManager*"
>
> All the other validation is left for the service implementation. For the
> other *InjectionServices, no validation (even the type) is performed by
> Weld.
>
> HTH,
>
> Jozef
>
> On 01/22/2015 02:35 PM, Robert Marcano wrote:
>> I have noticed that all *InjectionServices javadoc say that those
>> implementations should do the required injection point validations. for
>> example JpaInjectionServices
>>
>> "Register a persistence context injection point. The implementation
>> validates the injection point ..."
>>
>> But for some reason if a JpaInjectionServices implementation is
>> registered, an internal validation is triggered
>>
>> "WELD-001517: The type of the resource producer field
>> [[BackedAnnotatedField] @PersistenceContext private
>> com.example.TestBean.session] does not match the resource type interface
>> javax.persistence.EntityManager" See [1]
>>
>> This field class is an Hibernate session, Wildfly support injecting that
>> using @PersistentContext [2], but this validations is blocking me to do
>> the same in a mock test environment I am coding. I am not sure how
>> Wildfly inject it with Weld or if they skip Weld injecting JPA instances
>> because of this. Why this validation is harcoded on Weld, when for
>> example EjbInjectionServices doesn't force any predefined validation?
>>
>> Shouldn't it be removed and leave that validation to the
>> JpaInjectionServices implementation as the javadoc say it is its
>> responsibility?.
>>
>>
>> [1]
>> https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/injection/ResourceInjectionFactory.java#L306
>>
>> [2]
>> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-InjectionofHibernateSessionandSessionFactoryInjectionofHibernateSessionandSessionFactory
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>


From jharting at redhat.com  Thu Jan 22 11:04:58 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 22 Jan 2015 17:04:58 +0100
Subject: [weld-dev] JPA injection points validations
In-Reply-To: <54C11E62.2030208@marcanoonline.com>
References: <54C0FC9F.6000004@marcanoonline.com> <54C115BC.1080905@redhat.com>
	<54C11E62.2030208@marcanoonline.com>
Message-ID: <54C11FAA.8040200@redhat.com>

Depends on the component type. Resource injection for some components is 
managed by Weld while for others (e.g. session beans) it is not.

On 01/22/2015 04:59 PM, Robert Marcano wrote:
> I haven't found a way to override Weld detection of the @Persistence* 
> annotations, or add a new one, I may be wrong but probably Wildfly 
> just doesn't delegate to Weld for @Persistence*
>
> On 01/22/2015 10:52 AM, Jozef Hartinger wrote:
>> Validation *is* done by *InjectionServices. However, the
>> JpaInjectionServices SPI is built with the following assumption of 
>> types:
>>
>> @PersistenceContext -> EntityManager
>> @PersistenceUnit -> EntityManagerFactory
>>
>> which seems as a reasonable assumption given that e.g.
>> @PersistenceContext Javadoc says that:
>>
>> "Expresses a dependency on a container-managed *EntityManager*"
>>
>> All the other validation is left for the service implementation. For the
>> other *InjectionServices, no validation (even the type) is performed by
>> Weld.
>>
>> HTH,
>>
>> Jozef
>>
>> On 01/22/2015 02:35 PM, Robert Marcano wrote:
>>> I have noticed that all *InjectionServices javadoc say that those
>>> implementations should do the required injection point validations. for
>>> example JpaInjectionServices
>>>
>>> "Register a persistence context injection point. The implementation
>>> validates the injection point ..."
>>>
>>> But for some reason if a JpaInjectionServices implementation is
>>> registered, an internal validation is triggered
>>>
>>> "WELD-001517: The type of the resource producer field
>>> [[BackedAnnotatedField] @PersistenceContext private
>>> com.example.TestBean.session] does not match the resource type 
>>> interface
>>> javax.persistence.EntityManager" See [1]
>>>
>>> This field class is an Hibernate session, Wildfly support injecting 
>>> that
>>> using @PersistentContext [2], but this validations is blocking me to do
>>> the same in a mock test environment I am coding. I am not sure how
>>> Wildfly inject it with Weld or if they skip Weld injecting JPA 
>>> instances
>>> because of this. Why this validation is harcoded on Weld, when for
>>> example EjbInjectionServices doesn't force any predefined validation?
>>>
>>> Shouldn't it be removed and leave that validation to the
>>> JpaInjectionServices implementation as the javadoc say it is its
>>> responsibility?.
>>>
>>>
>>> [1]
>>> https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/injection/ResourceInjectionFactory.java#L306 
>>>
>>>
>>> [2]
>>> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-InjectionofHibernateSessionandSessionFactoryInjectionofHibernateSessionandSessionFactory 
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>


From robert at marcanoonline.com  Thu Jan 22 11:05:05 2015
From: robert at marcanoonline.com (Robert Marcano)
Date: Thu, 22 Jan 2015 11:35:05 -0430
Subject: [weld-dev] JPA injection points validations
In-Reply-To: <54C11943.1030903@redhat.com>
References: <54C0FC9F.6000004@marcanoonline.com> <54C11943.1030903@redhat.com>
Message-ID: <54C11FB1.4040008@marcanoonline.com>

On 01/22/2015 11:07 AM, Scott Marlow wrote:
> Do you really want the Hibernate session?  Keep in mind that it is
> managed by the EE container and will be closed when the transaction
> completes or the component invocation ends.

Yes, our codebase don't use JPA APIs, always the Hibernate API, and we 
use the Session with the JTA transaction. We are using many Hibernate 
features not supported by JPA so it doesn't make sense (for us) to mix 
both and make changes when we need to use one of those features.

>
> You can also call
> entityManagerFactory.unwrap(org.hibernate.SessionFactory.class) to get
> the session factory or entityManager.unwrap(org.hibernate.session.class
> to get the session.

I know, I wanted to avoid to make changes to every method that uses the 
session on the existing big codebase. Probably I can change 
@PersistenceContext with an @Inject and use a producer method to inject 
the Session and everyone is happy with a minimal annotation change :)

>
> On 01/22/2015 08:35 AM, Robert Marcano wrote:
>> I have noticed that all *InjectionServices javadoc say that those
>> implementations should do the required injection point validations. for
>> example JpaInjectionServices
>>
>> "Register a persistence context injection point. The implementation
>> validates the injection point ..."
>>
>> But for some reason if a JpaInjectionServices implementation is
>> registered, an internal validation is triggered
>>
>> "WELD-001517: The type of the resource producer field
>> [[BackedAnnotatedField] @PersistenceContext private
>> com.example.TestBean.session] does not match the resource type interface
>> javax.persistence.EntityManager" See [1]
>>
>> This field class is an Hibernate session, Wildfly support injecting that
>> using @PersistentContext [2], but this validations is blocking me to do
>> the same in a mock test environment I am coding. I am not sure how
>> Wildfly inject it with Weld or if they skip Weld injecting JPA instances
>> because of this. Why this validation is harcoded on Weld, when for
>> example EjbInjectionServices doesn't force any predefined validation?
>>
>> Shouldn't it be removed and leave that validation to the
>> JpaInjectionServices implementation as the javadoc say it is its
>> responsibility?.
>>
>>
>> [1]
>> https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/injection/ResourceInjectionFactory.java#L306
>>
>> [2]
>> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-InjectionofHibernateSessionandSessionFactoryInjectionofHibernateSessionandSessionFactory
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>


From smarlow at redhat.com  Thu Jan 22 11:13:04 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 22 Jan 2015 11:13:04 -0500
Subject: [weld-dev] JPA injection points validations
In-Reply-To: <54C11E62.2030208@marcanoonline.com>
References: <54C0FC9F.6000004@marcanoonline.com> <54C115BC.1080905@redhat.com>
	<54C11E62.2030208@marcanoonline.com>
Message-ID: <54C12190.608@redhat.com>

On 01/22/2015 10:59 AM, Robert Marcano wrote:
> I haven't found a way to override Weld detection of the @Persistence*
> annotations, or add a new one, I may be wrong but probably Wildfly just
> doesn't delegate to Weld for @Persistence*

Yes, I think your right.  Related WildFly code is at:
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/processor/JPAAnnotationProcessor.java
+
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/injectors/PersistenceContextInjectionSource.java

>
> On 01/22/2015 10:52 AM, Jozef Hartinger wrote:
>> Validation *is* done by *InjectionServices. However, the
>> JpaInjectionServices SPI is built with the following assumption of types:
>>
>> @PersistenceContext -> EntityManager
>> @PersistenceUnit -> EntityManagerFactory
>>
>> which seems as a reasonable assumption given that e.g.
>> @PersistenceContext Javadoc says that:
>>
>> "Expresses a dependency on a container-managed *EntityManager*"
>>
>> All the other validation is left for the service implementation. For the
>> other *InjectionServices, no validation (even the type) is performed by
>> Weld.
>>
>> HTH,
>>
>> Jozef
>>
>> On 01/22/2015 02:35 PM, Robert Marcano wrote:
>>> I have noticed that all *InjectionServices javadoc say that those
>>> implementations should do the required injection point validations. for
>>> example JpaInjectionServices
>>>
>>> "Register a persistence context injection point. The implementation
>>> validates the injection point ..."
>>>
>>> But for some reason if a JpaInjectionServices implementation is
>>> registered, an internal validation is triggered
>>>
>>> "WELD-001517: The type of the resource producer field
>>> [[BackedAnnotatedField] @PersistenceContext private
>>> com.example.TestBean.session] does not match the resource type interface
>>> javax.persistence.EntityManager" See [1]
>>>
>>> This field class is an Hibernate session, Wildfly support injecting that
>>> using @PersistentContext [2], but this validations is blocking me to do
>>> the same in a mock test environment I am coding. I am not sure how
>>> Wildfly inject it with Weld or if they skip Weld injecting JPA instances
>>> because of this. Why this validation is harcoded on Weld, when for
>>> example EjbInjectionServices doesn't force any predefined validation?
>>>
>>> Shouldn't it be removed and leave that validation to the
>>> JpaInjectionServices implementation as the javadoc say it is its
>>> responsibility?.
>>>
>>>
>>> [1]
>>> https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/injection/ResourceInjectionFactory.java#L306
>>>
>>> [2]
>>> https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-InjectionofHibernateSessionandSessionFactoryInjectionofHibernateSessionandSessionFactory
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>