Not sure what the licensing is on:
dependency
groupIdjavax.json/groupId
artifactIdjavax.json-api/artifactId
version1.0/version
/dependency
dependency
groupIdorg.glassfish/groupId
artifactIdjavax.json/artifactId
version1.0.4/version
/dependency
Andy.
On 04/06/2014
I was reading Romain's email about the situation being worse as
re-certification would be required as the interfaces will have changed. I
read that as meaning that each time the interfaces changed a costly
re-certification process would be required.
Can something not be JEE-6 and JEE-7 compliant
in one link: https://wiki.apache.org/incubator/Fleece
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-06-04 16:06 GMT+02:00 Andy Gumbrecht agumbre...@tomitribe.com:
Not
No you can only be EE 6 or EE 7 at a time. But tomee+ can be anything
;). That said upgrades will come very soon. We should just take care
to not upgrade everything at the same time ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn:
Ok
that's cause you initiate the action from lib bean so it uses lib
bean manager which doesn't know webapp beans which are referenced in
the jsf listener. Said otherwise deltaspike jsf should be in the
webapp I think.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog:
One of the null injection problems in our main app had to do with the fact
that we are using Quartz directly and as expected injection won't work in a
Quartz managed thread. We were able to workaround that by doing a JNDI lookup
of our EJB in java:global
Digressing a little bit, when we
You should annotate your REST endpoint to be something, e..g
@Stateless or @RequestScoped
On Wed, Jun 4, 2014 at 11:40 AM, Vamsee Lakamsani
vam...@yahoo.com.invalid wrote:
One of the null injection problems in our main app had to do with the fact
that we are using Quartz directly and as
I have a resource defined like this in tomee.xml and it works fine from TomEE
Resource id=“myDS type=javax.sql.DataSource
factory-name=createJDBCDataSource
class-name=“my.CustomDataSourceFactory
auth=Application
singleton = true
/Resource
Now, I want to test this in
@John: this is not mandatory
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-06-04 17:42 GMT+02:00 John D. Ament john.d.am...@gmail.com:
You should annotate your REST
myDs = new://Resource?type=DataSourceclass-name=factory-name=...
myDs.auth=Application
as properties should work
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
Getting close. It is calling my factory when I use the syntax you suggested but
the .auth (and a few more properties I have) are not getting through. When I
look in the debugger when running the unit test, I just see the two standard
ones (ServiceId and transactionManager). I see all of them
can you reproduce it in a sample you can share?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-06-04 18:39 GMT+02:00 Vamsee Lakamsani vam...@yahoo.com.invalid:
Getting
The extra properties for the data source is working. It was a typo on my part.
The MyBatis CDI problem went away after I added an empty beans.xml to
src/main/resource/META-INF! I had it under src/main/webapp/WEB-INF but
understandably the embedded container runs from a Junit test does not look
Thanks for giving it a shot Romain.
I've been down this road before regarding codi and ears/skinny wars and I
know best practice is to keep these libraries within each war.
I just find it strange when things work.and then suddenly does'nt
I'll just see what Gerhard Petracek has to say about
You can us tomee skinny war feature (jars.txt) i think
Le 4 juin 2014 21:02, hwaastad he...@waastad.org a écrit :
Thanks for giving it a shot Romain.
I've been down this road before regarding codi and ears/skinny wars and I
know best practice is to keep these libraries within each war.
I
Hi,
are you sure you mean I think ;-)
To me, this seem to be an excellent alternative to the skinny alternative.
At least for TomEE.
I'll give my larger project a go.
I will give you feedback!
Thanks alot again Romain.
br hw
--
View this message in context:
16 matches
Mail list logo
