Re: WARNING - Failed to scan jar from classloader hierarchy

I saved the file as conf/exclusions.list.txt by mistake, after fixing the name it works now. Thanks, Dmitry -- View this message in context: http://tomee-openejb.979440.n4.nabble.com/WARNING-Failed-to-scan-jar-from-classloader-hierarchy-tp4678670p4678677.html Sent from the TomEE Users

Re: WARNING - Failed to scan jar from classloader hierarchy

Hi Romain, I can see it's related to org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:103) from the stacktarce, here it is: WARNING - Failed to scan [file:/C:/distributions/apache-tomee-webprofile-7.0.0/lib/sonic_SF.jar] from classloader hierarchy

Re: WARNING - Failed to scan jar from classloader hierarchy

Hi Dmitry, why do you link it to JasperInitializer? Do you know why this jar is not scannable? Anyway creating a file conf/exclusions.list with this content: default-list sonic should do the trick. Romain Manni-Bucau @rmannibucau | Blog

Re: [ANNOUNCE] Apache TomEE 7.0.0

@Ihsan: this should sync up soon I guess, official tag is on our main repo: https://git1-us-west.apache.org/repos/asf?p=tomee.git;a=summary Romain Manni-Bucau @rmannibucau | Blog | Github |

Re: [ANNOUNCE] Apache TomEE 7.0.0

Many thanks to everyone who is involved with this, can’t wait to upgrade my servers to 7.0.0 By the way, are you planning to tag the release on Github? I couldn’t see the release here: https://github.com/apache/tomee/releases > On May 29, 2016,

WARNING - Failed to scan jar from classloader hierarchy

Hi All, I just upgraded to TomEE 7 and getting some jar scanning warnings that I didn’t see before, for example: WARNING - Failed to scan [file:/C:/distributions/apache-tomee-webprofile-7.0.0/lib/sonic_Channel.jar] from classloader hierarchy java.io.FileNotFoundException:

RE: Can't read beans.xml (TomEE 1.7.4 + new Camel CDI)

Upgrading to TomeEE 7 eliminated this error, Thanks John & Romain. Cheers, Dmitry From: Romain Manni-Bucau [via TomEE & OpenEJB] [mailto:ml-node+s979440n4678667...@n4.nabble.com] Sent: May-30-16 11:10 AM To: Shultz, Dmitry Subject: Re: Can't read beans.xml (TomEE

Re: Can't read beans.xml (TomEE 1.7.4 + new Camel CDI)

Hi, Camel CDI relies on CDI 1.1 semantics. scan is a CDI 1.1 feature. TomEE 1.7 is Java EE 6, meaning its using CDI 1.0 not CDI 1.1. Though I do see a typo in their beans.xml, saying the version is 1.0 (that attribute is mostly ignored). You should try on the recently released TomEE 7. John

Re: Can't read beans.xml (TomEE 1.7.4 + new Camel CDI)

Hi Camel cdi doesnt work on javaee6, upgrading to tomee 7.0.0 would be the easiest Le 30 mai 2016 20:41, "dimas" a écrit : > Hi All, > > I'm getting following error while deploying web app which is built using > Camel CDI component (2.17.1): > > May 30, 2016 10:52:38

Can't read beans.xml (TomEE 1.7.4 + new Camel CDI)

Hi All, I'm getting following error while deploying web app which is built using Camel CDI component (2.17.1): May 30, 2016 10:52:38 AM org.apache.openejb.config.DeploymentLoader mergeBeansXml SEVERE: Unable to read beans.xml from:

Re: Recommended ORM for 7

If you use JSF I would just add Eclipselink or Hibernate otherwise Plume. EclipseLink allows loading lazy relationships as long as the connection is still available so you rarely have issues with lazy loading. Instead you have more issues with N+1, we use x-rebel to catch that. EclipseLink has a

Re: EJB vs REST

It doesn't and is not related actually if you expose ejbd endpoints/any not configured RMI endpoint. Point was more RMI will imply a verbose configuration you will likely not like or want to maintain (whitelist) vs JAX-RS. Romain Manni-Bucau @rmannibucau | Blog

Re: EJB vs REST

Wouldn't SELinux take care of the serialization exploit? I mean exploits come along all the time, which is why SELinux should be in use; assuming the use of Linux. On Mon, May 30, 2016 at 2:47 AM, Romain Manni-Bucau wrote: > you can also see the 0-day vulnerability as

Re: EJB vs REST

I depends on the service. Some use MAC addresses, some use customer GUIDs as keys. Typically I cache expensive calls and use the key to retrieve from cache (thus you only pass the key, not everything that goes with it each time). Since the cache is distributed and the VMs are behind a load

Re: EJB vs REST

you can also see the 0-day vulnerability as another step requiring configuration with RMI and not with JAX-RS/JSON default usage. Also another thing to justify if you get an audit ;) Romain Manni-Bucau @rmannibucau | Blog |

Re: EJB vs REST

Also, another aspect to all of this, is that we have a moderately sized application, which uses RMI for the business logic. Converting that to @Stateful EJB, would be a breeze, and we could really be confident it would continue working once we've gone through our testing cycle. I'm guessing that

Re: EJB vs REST

CXF supports session state: https://github.com/apache/cxf/blob/ac9b9b1898bbe0cc911b34cc3d32664ac59fdc34/systests/rs-security/src/test/java/org/apache/cxf/systest/jaxrs/security/oauth2/grants/AuthorizationGrantTest.java#L57 Romain Manni-Bucau @rmannibucau | Blog

Re: EJB vs REST

That is very interesting. Apparently Jersey has a proxy client API as well. There has to be some sort of state, even if it's as simple as maintaining that your user is authenticated. With this proxy client api, is it possible to have cookies automatically kept, and sent during each request? On

Re: EJB vs REST

2016-05-30 7:52 GMT+02:00 Trenton D. Adams : > On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau > > wrote: > > > Hello > > > > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams : > > > > > Good day, > > > > > > I've had