WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
4 days, 20 hours
JPA injection points validations
by Robert Marcano
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/wel...
[2]
https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPARefere...
10 years, 11 months
jandex not used on JNLP applications (Windows)
by 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/jav...
10 years, 12 months
