date:20160615

Re: CXF and WebSocket messages are merged together

2016-06-15 Thread Ihsan Ecemis

Thanks for your answer Romain.  I would appreciate any links to inspire me how 
to do that, especially for Twilio API calls.  I don’t know how to use 
sessionIds to track connections.

Here are 2 new pieces of information:

(1) WebSocket connections were shaky for some users and Atmosphere javascript 
client had a failover to long-polling. 

So yesterday, we disabled long-polling failover and since then we didn't have 
any errors from Twilio.  Probably it is too early to claim victory but I think 
it is an interesting observation.

If we don’t see any other errors, I will think that the client was switching 
from websocket to long-polling, and then getting disconnected.  The server 
(Atmosphere?) didn’t realize this disconnect and kept on writing to the same 
connection. And at some point that same connection was handed over to the 
Twilio API call…  (which should not happen!  must be prevented by Tomcat?  
nginx?  CXF?  Atmosphere?) 

I don’t know how the Socket Connection Pool works at low-level so this is only 
my speculation, both from my observation there is something really wrong here. 

(2) I looked at Twilio error messages more carefully,  and each error I looked 
so far contained WebSockets messages addressed to the same user (This is very 
manual process, I check our logs for each task_id posted to Twilio in JSON).

In one case there were 5 WebSockets messages addressed to the same user, 
prepended to Twilio XML.   These 5 messages spanned 576 seconds, i.e. almost 10 
minutes!  (Each WebSockets messages has a  timestamp).   So we kept on writing 
to the same connection for 10 minutes after the WebSocket was disconnected   ;-(

> On Jun 15, 2016, at 7:26 PM, Romain Manni-Bucau  wrote:
> 
> Is debugging using the sessionId to track connections an option?
> Le 16 juin 2016 01:12, "Ihsan Ecemis"  a écrit :
> 
>> 
>> TL;DR:  We are having this weird, non-reproducable problem in a complex
>> system with lots of moving parts. I posted this question to Atmosphere
>> mailing list but didn’t get useful answers.  I would appreciate if anyone
>> can tell me whether there is any chance what we observe can be a bug with
>> Tomcat/TomEE.  Any other help/tips would be greatly appreciated. Thanks
>> 
>> 
>> Problem:
>> 
>> We experience some weird problems with WebSockets under Atmosphere,
>> running under TomEE 7.0.0 — the whole stack is listed below.
>> 
>> 
>> One of our JAX-RS API endpoints (something like /twilio/) is called by
>> Twilio.  Twilio expects  the following XML response:
>> 
>> 
>> 
>> That system was working fine for months.  We were receiving Text Messages
>> with no errors from Twilio.
>> 
>> 
>> Then, we added WebSockets at a different endpoint (something like
>> /ws/).  Using our AngularJS app, our users started communicating with
>> our backend in JSON.  A sample message our backend wrote to a WebSocket
>> client:
>> 
>> 
>> {"thread_id":"Server-2702","session_id":null,"command":"cancel_caleasy_item","data":{"text_message_id":1126,"task_id":10134},"time":1465409434004}
>> 
>> 
>> 
>> After a while, Twilio started sending us "Schema validation warning”
>> emails.  When I went to Twilio Dashboard,  I saw that they received the
>> following response to their API call:
>> 
>> {"thread_id":”Server-1732","session_id":null,"command":"cancel_caleasy_item","data":{"text_message_id”:734,"task_id”:9345},"time":
>> 1465409122781}> standalone="yes"?>
>> 
>> 
>> So Twilio received a message that was meant to be sent to a WebSocket
>> user, prepended to the usual Twilio response!  This looks crazy, and not
>> unacceptable of course.
>> 
>> This happens a few times, sometimes a dozen times a day.  We put together
>> a test system but could not reproduce the problem. (Our test system was not
>> exactly the same system as our production in many respects unfortunately)
>> 
>> Sometimes Twilio receives more than one WebSocket message, again an actual
>> example (redacted just a little for brevity):
>> 
>> {"thread_id":"Server-2722","session_id":null,"command":"cancel_caleasy_item","data":{"text_message_id":1966,"task_id":2},"time":1465409571004}{"thread_id":"Server-2723","session_id":null,"command":"new_caleasy_item","data":{"text_message_id":1453,"text_message_created_at":null,"meal_type_id":6,"body":"Edamame","report_date":"2016-06-03","caleasy_media_list":[],"task_id":4,"expiration_millis":18},"time":1465409582010}> version="1.0" encoding="UTF-8" standalone="yes"?>
>> 
>> 
>> In this example, our Backend wrote 2 WebSocket messages, probably from 2
>> separate threads, intended for 2 separate WebSocket users, and then it
>> wrote the response to Twilio.  It looks like we are writing to a connection
>> nobody is reading from, and appending more messages to it, and then the
>> whole thing is returned to Twilio when they make the API call…
>> 
>> 
>> I don’t understand how this could happening.  In nginx?  (I really doubt
>> nginx can have

Re: CXF and WebSocket messages are merged together

2016-06-15 Thread Romain Manni-Bucau

Is debugging using the sessionId to track connections an option?
Le 16 juin 2016 01:12, "Ihsan Ecemis"  a écrit :

>
> TL;DR:  We are having this weird, non-reproducable problem in a complex
> system with lots of moving parts. I posted this question to Atmosphere
> mailing list but didn’t get useful answers.  I would appreciate if anyone
> can tell me whether there is any chance what we observe can be a bug with
> Tomcat/TomEE.  Any other help/tips would be greatly appreciated. Thanks
>
>
> Problem:
>
> We experience some weird problems with WebSockets under Atmosphere,
> running under TomEE 7.0.0 — the whole stack is listed below.
>
>
> One of our JAX-RS API endpoints (something like /twilio/) is called by
> Twilio.  Twilio expects  the following XML response:
>
> 
>
> That system was working fine for months.  We were receiving Text Messages
> with no errors from Twilio.
>
>
> Then, we added WebSockets at a different endpoint (something like
> /ws/).  Using our AngularJS app, our users started communicating with
> our backend in JSON.  A sample message our backend wrote to a WebSocket
> client:
>
>
> {"thread_id":"Server-2702","session_id":null,"command":"cancel_caleasy_item","data":{"text_message_id":1126,"task_id":10134},"time":1465409434004}
>
>
>
> After a while, Twilio started sending us "Schema validation warning”
> emails.  When I went to Twilio Dashboard,  I saw that they received the
> following response to their API call:
>
> {"thread_id":”Server-1732","session_id":null,"command":"cancel_caleasy_item","data":{"text_message_id”:734,"task_id”:9345},"time":
> 1465409122781} standalone="yes"?>
>
>
> So Twilio received a message that was meant to be sent to a WebSocket
> user, prepended to the usual Twilio response!  This looks crazy, and not
> unacceptable of course.
>
> This happens a few times, sometimes a dozen times a day.  We put together
> a test system but could not reproduce the problem. (Our test system was not
> exactly the same system as our production in many respects unfortunately)
>
> Sometimes Twilio receives more than one WebSocket message, again an actual
> example (redacted just a little for brevity):
>
> {"thread_id":"Server-2722","session_id":null,"command":"cancel_caleasy_item","data":{"text_message_id":1966,"task_id":2},"time":1465409571004}{"thread_id":"Server-2723","session_id":null,"command":"new_caleasy_item","data":{"text_message_id":1453,"text_message_created_at":null,"meal_type_id":6,"body":"Edamame","report_date":"2016-06-03","caleasy_media_list":[],"task_id":4,"expiration_millis":18},"time":1465409582010} version="1.0" encoding="UTF-8" standalone="yes"?>
>
>
> In this example, our Backend wrote 2 WebSocket messages, probably from 2
> separate threads, intended for 2 separate WebSocket users, and then it
> wrote the response to Twilio.  It looks like we are writing to a connection
> nobody is reading from, and appending more messages to it, and then the
> whole thing is returned to Twilio when they make the API call…
>
>
> I don’t understand how this could happening.  In nginx?  (I really doubt
> nginx can have such a huge bug)   In Tomcat?   A problem between nginx and
> Tomcat that only affects WebSockets when regular API calls are also used?
> I have no idea and I don’t know where to start to investigate   ;-(
>
>
> Here is our stack:
>
> *) AWS Linux 4.1.10-17.31, TomEE 7.0.0, nginx as proxy server on the same
> AWS instance
> *) SSL ends on nginx. nginx is configured for WebSockets following online
> instructions.
> *) We serve JAX-RS API calls via Apache CXF (version 3.1.6), using
> standard @Path("/") annotations.
> *) We have just one WebSocket service using Atmosphere (version 2.4.2),
> defined as @ManagedService(path = "/caleasy”)
> *) WebSocket service is used by our AngularJS based UI
> *) No other specific setup with CXF and Atmosphere
>
> In our web.xml, we configure Atmosphere as follows:
>
>   
> AtmosphereServlet
> AtmosphereServlet
> org.atmosphere.cpr.AtmosphereServlet
>   
>
>   
> AtmosphereServlet
> /ws/*
>   
>
>   
> org.atmosphere.cpr.SessionSupport
>   
>
>
>
> PS: Our TomEE logs have the following Exceptions, but I am not sure
> whether they are normal or suspicious:
>
> 2016-06-09 13:52:41,832 ERROR [nio-8080-exec-9] o.a.c.JSR356Endpoint
>-
> java.io.EOFException: null
> at
> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1267)
> at
> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.isReadyForRead(NioEndpoint.java:1176)
> at
> org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:58)
> at
> org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.upgradeDispatch(WsHttpUpgradeHandler.java:148)
> at
> org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)
> at
>

Re: NetBeans 8.1 does not think TomEE 7.0.0 has started

2016-06-15 Thread HWinMT

I found what you are talking about "forced tomcat to send back
> server header" in the change log. I try that tomorrow. Thanks.



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/NetBeans-8-1-does-not-think-TomEE-7-0-0-has-started-tp4678907p4678915.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: old API 'file:/C:/Program%20Files/tomcat-8.5.3-tomee7/lib/annotations-api.jar' was found on the classpath

2016-06-15 Thread Romain Manni-Bucau

Hi

Default tomcat annotation-api.jar needs to be removed. It has old version
of the api.
Le 16 juin 2016 00:15, "HWinMT"  a écrit :

> In trying to resolve an issue with Netbeans 8.1 / Tomee 7 I am dropping an
> existing .war file into Tomcat 8.5.3 / TomEE 7 and starting the Tomcat from
> the command prompt. This a .war file from a current project on Tomcat
> 7.0.69
> / TomEE 1.7.4.
>
> Deployment fails with:
>
> 15-Jun-2016 15:32:58.322 WARNING [localhost-startStop-1]
>
> org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.getLookupMethod
> Method 'lookup' is not available for 'javax.ejb.EJB'. The old API
> 'file:/C:/Program%20Files/tomcat-8.5.3-tomee7/lib/annotations-api.jar' was
> found on the classpath.
>
> 15-Jun-2016 15:32:58.337 SEVERE [localhost-startStop-1]
> sun.reflect.NativeMethodAccessorImpl.invoke ContainerBase.addChild: start:
>  org.apache.catalina.LifecycleException: Failed to start component
>
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Metrics]]
>
> Caused by: java.lang.NoSuchMethodError:
>
> javax.persistence.PersistenceContext.synchronization()Ljavax/persistence/SynchronizationType;
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/old-API-file-C-Program-20Files-tomcat-8-5-3-tomee7-lib-annotations-api-jar-was-found-on-the-classpath-tp4678911.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

Re: NetBeans 8.1 does not think TomEE 7.0.0 has started

2016-06-15 Thread Romain Manni-Bucau

https://bz.apache.org/bugzilla/show_bug.cgi?id=58750 is the issue ref
Le 16 juin 2016 00:20, "HWinMT"  a écrit :

> Hi, thanks for the reply. I only get the sql lock problem when I remove the
> quotes suggest in the link I referenced in the post above the error.
>
> No sure how to do what you are talking about "forced tomcat to send back
> server header". But I'll see what I can figure out. Maybe I can see
> something in Monitor.
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/NetBeans-8-1-does-not-think-TomEE-7-0-0-has-started-tp4678907p4678912.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

Re: NetBeans 8.1 does not think TomEE 7.0.0 has started

2016-06-15 Thread HWinMT

Hi, thanks for the reply. I only get the sql lock problem when I remove the
quotes suggest in the link I referenced in the post above the error. 

No sure how to do what you are talking about "forced tomcat to send back
server header". But I'll see what I can figure out. Maybe I can see
something in Monitor.



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/NetBeans-8-1-does-not-think-TomEE-7-0-0-has-started-tp4678907p4678912.html
Sent from the TomEE Users mailing list archive at Nabble.com.

old API 'file:/C:/Program%20Files/tomcat-8.5.3-tomee7/lib/annotations-api.jar' was found on the classpath

2016-06-15 Thread HWinMT

In trying to resolve an issue with Netbeans 8.1 / Tomee 7 I am dropping an
existing .war file into Tomcat 8.5.3 / TomEE 7 and starting the Tomcat from
the command prompt. This a .war file from a current project on Tomcat 7.0.69
/ TomEE 1.7.4.  

Deployment fails with:

15-Jun-2016 15:32:58.322 WARNING [localhost-startStop-1]
org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.getLookupMethod
Method 'lookup' is not available for 'javax.ejb.EJB'. The old API
'file:/C:/Program%20Files/tomcat-8.5.3-tomee7/lib/annotations-api.jar' was
found on the classpath.

15-Jun-2016 15:32:58.337 SEVERE [localhost-startStop-1]
sun.reflect.NativeMethodAccessorImpl.invoke ContainerBase.addChild: start: 
 org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Metrics]]

Caused by: java.lang.NoSuchMethodError:
javax.persistence.PersistenceContext.synchronization()Ljavax/persistence/SynchronizationType;




--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/old-API-file-C-Program-20Files-tomcat-8-5-3-tomee7-lib-annotations-api-jar-was-found-on-the-classpath-tp4678911.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: Exclusions.list not working

2016-06-15 Thread Romain Manni-Bucau

Le 16 juin 2016 00:02, "Jeff Wallace"  a écrit :
>
> Romain -
> Thanks for the response.
>
> I just downloaded the Zip, extracted it, manually copy my EAR into
> TOMEE/apps, start TOMEE via 'catalina.bat start' in TOMEE/bin
>
> I went into TOMEE/conf/context.xml and I don't have anything configured in
> there.
>
> The class that is getting picked up is an EJB.  It lives inside of that
> 'calculation-svc' JAR
>

Then it should clearly work for a standalone tomee.

Maybe check against last bundle releases if you dont use them.

> I will look into activating debug logs and see what I can find.
>
>
> On Wed, Jun 15, 2016 at 4:18 PM, Romain Manni-Bucau 
> wrote:
>
> > Hi
> >
> > Le 15 juin 2016 21:49, "Jeff Wallace"  a écrit
:
> > >
> > > I am using Apache Tomcat Version 7.0.55.
> > >
> >
> > How do you setup tomee? Manually?
> >
> > > I am trying to get TOMEE to completely ignore a specific JAR of mine
when
> > > it loads up.
> > >
> > > To do this, I created {TOMEE}/conf/exclusions.list
> > > and this is the entire contents of the that file ::
> > >
> > > default-list
> > > calculation-svc-0.0.1-SNAPSHOT
> > >
> >
> > Looks good - you can skip the version too.
> >
> > > For some reason though, after restarting TOMEE it still continues to
pick
> > > up classes from within that JAR.
> > >
> >
> > Maybe activate debug logs. Also ensure your war doesnt use a custom
tomcat
> > scanner in context.xml. finally can you say us which kind of class it
picks
> > up? Servlet/jaxrs/
> >
> > > Am I missing something?
> > >
> > > I can see from the catalina log, that it looks like TOMEE is trying to
> > pull
> > > in exclusions, but it's not finding any.  Plus, it appears to be
doing it
> > > twice.  Not sure if that's normal or not.  Below is the log output ::
> >
> > Can be ok it does it is logged twice for old versions.
> >
> > > Jun 15, 2016 2:32:22 PM org.apache.openejb.config.NewLoaderLogic
> > > getExclusions
> > > INFO: Loaded classpath exclusions from:
> > > C:\Applications\tomee\conf\exclusions.list
> > > Jun 15, 2016 2:32:22 PM org.apache.openejb.config.NewLoaderLogic
> > > getExclusions
> > > INFO: Loaded classpath exclusions from:
> > > C:\Applications\tomee\conf\exclusions.list
> > >
> > >
> > > For additional resources, I also have a discussion about this issue on
> > > Stack Overflow at ::
> > > http://stackoverflow.com/questions/37798824/tomee-exclude-a-jar
> >

Re: Exclusions.list not working

2016-06-15 Thread Jeff Wallace

Romain -
Thanks for the response.

I just downloaded the Zip, extracted it, manually copy my EAR into
TOMEE/apps, start TOMEE via 'catalina.bat start' in TOMEE/bin

I went into TOMEE/conf/context.xml and I don't have anything configured in
there.

The class that is getting picked up is an EJB.  It lives inside of that
'calculation-svc' JAR

I will look into activating debug logs and see what I can find.


On Wed, Jun 15, 2016 at 4:18 PM, Romain Manni-Bucau 
wrote:

> Hi
>
> Le 15 juin 2016 21:49, "Jeff Wallace"  a écrit :
> >
> > I am using Apache Tomcat Version 7.0.55.
> >
>
> How do you setup tomee? Manually?
>
> > I am trying to get TOMEE to completely ignore a specific JAR of mine when
> > it loads up.
> >
> > To do this, I created {TOMEE}/conf/exclusions.list
> > and this is the entire contents of the that file ::
> >
> > default-list
> > calculation-svc-0.0.1-SNAPSHOT
> >
>
> Looks good - you can skip the version too.
>
> > For some reason though, after restarting TOMEE it still continues to pick
> > up classes from within that JAR.
> >
>
> Maybe activate debug logs. Also ensure your war doesnt use a custom tomcat
> scanner in context.xml. finally can you say us which kind of class it picks
> up? Servlet/jaxrs/
>
> > Am I missing something?
> >
> > I can see from the catalina log, that it looks like TOMEE is trying to
> pull
> > in exclusions, but it's not finding any.  Plus, it appears to be doing it
> > twice.  Not sure if that's normal or not.  Below is the log output ::
>
> Can be ok it does it is logged twice for old versions.
>
> > Jun 15, 2016 2:32:22 PM org.apache.openejb.config.NewLoaderLogic
> > getExclusions
> > INFO: Loaded classpath exclusions from:
> > C:\Applications\tomee\conf\exclusions.list
> > Jun 15, 2016 2:32:22 PM org.apache.openejb.config.NewLoaderLogic
> > getExclusions
> > INFO: Loaded classpath exclusions from:
> > C:\Applications\tomee\conf\exclusions.list
> >
> >
> > For additional resources, I also have a discussion about this issue on
> > Stack Overflow at ::
> > http://stackoverflow.com/questions/37798824/tomee-exclude-a-jar
>

NetBeans 8.1 does not think TomEE 7.0.0 has started

2016-06-15 Thread HWinMT

Tomcat 8.5.3 / WebProfile Drop In War from
http://tomee.apache.org/downloads.html / Windows7

Tried this:
http://stackoverflow.com/questions/30647156/tomee-starts-but-netbeans-gives-failed-to-start-error
*(This already rem'd out in the server.xml)*

and this:
http://stackoverflow.com/questions/5764/starting-of-tomcat-failed-from-netbeans
*15-Jun-2016 14:48:29.927 SEVERE [main]
org.apache.tomcat.jdbc.pool.ConnectionPool.init Unable to create initial
connections of pool.*
/ java.sql.SQLException: Database lock acquisition failure: lockFile:
org.hsqldb.persist.LockFile@5798aaca[file =C:\Program
Files\tomcat-8.5.3-tomee7\data\hsqldb\hsqldb.lck, exists=true, locked=false,
valid=false, ] method: checkHeartbeat read: 2016-06-15 20:48:28 heartbeat -
read: -4040 ms./


and this:
http://tomee-openejb.979440.n4.nabble.com/NetBeans-8-does-not-think-TomEE-has-started-td4675364.html
*(This already rem'd out in the server.xml)*





--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/NetBeans-8-1-does-not-think-TomEE-7-0-0-has-started-tp4678907.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: Exclusions.list not working

2016-06-15 Thread Romain Manni-Bucau

Hi

Le 15 juin 2016 21:49, "Jeff Wallace"  a écrit :
>
> I am using Apache Tomcat Version 7.0.55.
>

How do you setup tomee? Manually?

> I am trying to get TOMEE to completely ignore a specific JAR of mine when
> it loads up.
>
> To do this, I created {TOMEE}/conf/exclusions.list
> and this is the entire contents of the that file ::
>
> default-list
> calculation-svc-0.0.1-SNAPSHOT
>

Looks good - you can skip the version too.

> For some reason though, after restarting TOMEE it still continues to pick
> up classes from within that JAR.
>

Maybe activate debug logs. Also ensure your war doesnt use a custom tomcat
scanner in context.xml. finally can you say us which kind of class it picks
up? Servlet/jaxrs/

> Am I missing something?
>
> I can see from the catalina log, that it looks like TOMEE is trying to
pull
> in exclusions, but it's not finding any.  Plus, it appears to be doing it
> twice.  Not sure if that's normal or not.  Below is the log output ::

Can be ok it does it is logged twice for old versions.

> Jun 15, 2016 2:32:22 PM org.apache.openejb.config.NewLoaderLogic
> getExclusions
> INFO: Loaded classpath exclusions from:
> C:\Applications\tomee\conf\exclusions.list
> Jun 15, 2016 2:32:22 PM org.apache.openejb.config.NewLoaderLogic
> getExclusions
> INFO: Loaded classpath exclusions from:
> C:\Applications\tomee\conf\exclusions.list
>
>
> For additional resources, I also have a discussion about this issue on
> Stack Overflow at ::
> http://stackoverflow.com/questions/37798824/tomee-exclude-a-jar

Re: New install hangs at startup.

2016-06-15 Thread Romain Manni-Bucau

Hello

Execute a jstack on the process pid when it hangs. Will immediately says
why.

Rare cases i saw it hanging not waiting on a resource was due to a wrongly
configured scanning. However default should be fine.

Also check your env doesnt inherit from another catalina variable.
Le 15 juin 2016 21:59, "paulhr"  a écrit :

I have made no changes at all, just uncompressed the file into
/opt/apache-tomee-webprofile-7.0.0.  Issued the
/opt/apache-tomee-webprofile-7.0.0/bin/startup.sh only to have the startup
hang at the following step

INFO - Deployed
Application(path=/opt/apache-tomee-webprofile-7.0.0/webapps/docs)
INFO - At least one JAR was scanned for TLDs yet contained no TLDs. Enable
debug logging for this logger for a complete list of JARs that were scanned
but $





--
View this message in context:
http://tomee-openejb.979440.n4.nabble.com/New-install-hangs-at-startup-tp4678904.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Exclusions.list not working

2016-06-15 Thread Jeff Wallace

I am using Apache Tomcat Version 7.0.55.

I am trying to get TOMEE to completely ignore a specific JAR of mine when
it loads up.

To do this, I created {TOMEE}/conf/exclusions.list
and this is the entire contents of the that file ::

default-list
calculation-svc-0.0.1-SNAPSHOT

For some reason though, after restarting TOMEE it still continues to pick
up classes from within that JAR.

Am I missing something?

I can see from the catalina log, that it looks like TOMEE is trying to pull
in exclusions, but it's not finding any.  Plus, it appears to be doing it
twice.  Not sure if that's normal or not.  Below is the log output ::
Jun 15, 2016 2:32:22 PM org.apache.openejb.config.NewLoaderLogic
getExclusions
INFO: Loaded classpath exclusions from:
C:\Applications\tomee\conf\exclusions.list
Jun 15, 2016 2:32:22 PM org.apache.openejb.config.NewLoaderLogic
getExclusions
INFO: Loaded classpath exclusions from:
C:\Applications\tomee\conf\exclusions.list


For additional resources, I also have a discussion about this issue on
Stack Overflow at ::
http://stackoverflow.com/questions/37798824/tomee-exclude-a-jar

Re: Error with TomeeJaxRsService when deploy application as .ear, but not when it is simply a .war

2016-06-15 Thread Romain Manni-Bucau

Without a sample hard to say

FYI tested such an ear on 7.0.0 and it works. I suspect it is linked to
something else than the packaging (like the configuration or code
dependencies)


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-06-15 19:27 GMT+02:00 jayleg :

> The same problem occurs after upgrading to 1.7.4.
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/Error-with-TomeeJaxRsService-when-deploy-application-as-ear-but-not-when-it-is-simply-a-war-tp4678607p4678900.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

Re: Moving EJB app from WebSphere App Server 8.5 to TomEE 1.7.3

2016-06-15 Thread jayleg

I added the following property to system.properties to force the JNDI names
to be similar to WebSphere.

openejb.jndiname.format = ejb/{interfaceClass.simpleName}



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/Moving-EJB-app-from-WebSphere-App-Server-8-5-to-TomEE-1-7-3-tp4677845p4678901.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: Error with TomeeJaxRsService when deploy application as .ear, but not when it is simply a .war

2016-06-15 Thread jayleg

The same problem occurs after upgrading to 1.7.4.



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/Error-with-TomeeJaxRsService-when-deploy-application-as-ear-but-not-when-it-is-simply-a-war-tp4678607p4678900.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: TomEE 7 logger heap leak?

2016-06-15 Thread Romain Manni-Bucau

2016-06-15 16:46 GMT+02:00 Steve Goldsmith :

> Right, but the container still uses log4j, correct? I want everything to
> use the same logger/format.
>
>
I assume you mean JUL (tomee doesn't use or provide log4j since a lot of
versions)

Normally no, at least for parts we control (so should include tomee,
tomcat, openwebbeans, CXF, openjpa from memory + all slf4j by default libs
of course)


>
> On Wed, Jun 15, 2016 at 10:43 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> wrote:
>
> > this property just redirects logs to slf4j (and therefore logback if
> that's
> > your impl). Then the logger eviction per classloader is on your
> > charge/config.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-06-15 16:41 GMT+02:00 Steve Goldsmith :
> >
> > > Well, I'm using logback as well with slf4j.
> > >
> > > On Wed, Jun 15, 2016 at 10:36 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > openejb.log.factory=slf4j is not good enough? We also need a
> > confirmation
> > > > our hypothesis are right or not.
> > > >
> > > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Wordpress Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Tomitriber
> > > >  | JavaEE Factory
> > > > 
> > > >
> > > > 2016-06-15 16:33 GMT+02:00 Steve Goldsmith :
> > > >
> > > > > OK, so what handler should I use?
> > > > >
> > > > > On Wed, Jun 15, 2016 at 3:20 AM, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I see, can be linked to the bridge and I'm not sure logback/jul
> > > > > integration
> > > > > > is able to respect classloaders (didn't check) but tomcat default
> > > > > > LogManager does and we enforce the classloader normally where we
> > can
> > > so
> > > > > it
> > > > > > shouldn't leak.
> > > > > >
> > > > > > openejb.log.factory=slf4j should allow you to use logback without
> > the
> > > > > > bridge (IIRC you can miss first 2 log lines but their data are
> > > > repeated a
> > > > > > bit later so not a big issue). If it doesn't leak without these
> > > changes
> > > > > > then it would be interesting to test this.
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau  |  Blog
> > > > > >  | Old Wordpress Blog
> > > > > >  | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn  | Tomitriber
> > > > > >  | JavaEE Factory
> > > > > > 
> > > > > >
> > > > > > 2016-06-15 1:21 GMT+02:00 Steve Goldsmith :
> > > > > >
> > > > > > > I sent you a link to the configuration I use, but here's what I
> > > have:
> > > > > > >
> > > > > > > In TOMEE/bin:
> > > > > > >
> > > > > > >- logback-config dir
> > > > > > >- logback.xml
> > > > > > >   - jul-to-slf4j-1.7.7.jar
> > > > > > >- setenv.sh
> > > > > > >   -
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> CLASSPATH=$CATALINA_HOME/bin/jul-to-slf4j-1.7.7.jar:$CATALINA_HOME/bin/slf4j-api-1.7.7.jar:$CATALINA_HOME/bin/logback-classic-1.1.2.jar:$CATALINA_HOME/bin/logback-core-1.1.2.jar:$CATALINA_HOME/bin/logback-config/
> > > > > > >   - logback-classic-1.1.2.jar
> > > > > > >- logback-core-1.1.2.jar
> > > > > > >- slf4j-api-1.7.7.jar
> > > > > > >
> > > > > > > In TOMEE/conf:
> > > > > > >
> > > > > > >- logging.properties
> > > > > > >   - handlers = org.slf4j.bridge.SLF4JBridgeHandler
> > > > > > >
> > > > > > > I just upgraded to 7.0.0 release from an April snapshot. First,
> > > I'll
> > > > > see
> > > > > > if
> > > > > > > it pops up again (it takes a week or so), then I'll remove
> > > > > logback/slf4j
> > > > > > > configuration changes. If there's a better way to integrate
> > logback
> > > > I'm
> > > > > > all
> > > > > > > ears.
> > > > > > >
> > > > > > > On Tue, Jun 14, 2016 at 6:37 PM, Romain Manni-Bucau <
> > > > > > rmannibu...@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Not linked to jsonp.
> > > > > > > >
> > > > > > > > First time i see something linked to our logger and only
> case i
> > > can
> > >

Re: WARNING: Failed to unregister the JMX name && JDBC driver [org.postgresql.Driver] but failed to unregister

2016-06-15 Thread Romain Manni-Bucau

Not normal but doesn't happen using tomcat-jdbc - you use dbcp.

Will check and fix it for next release.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-06-15 16:14 GMT+02:00 gilbertoca :

> Hi again,
>
> I've seen this message every time I quit TomEE embedded (maven plugin):
>
>
> The data-source name is "java:app/gace/MyDS" and we're using PostgreSQL 9.4
> .
>
> Is it a normal behavior?
>
> Regards,
> Gilberto
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/WARNING-Failed-to-unregister-the-JMX-name-JDBC-driver-org-postgresql-Driver-but-failed-to-unregister-tp4678894.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>

WARNING: Failed to unregister the JMX name && JDBC driver [org.postgresql.Driver] but failed to unregister

2016-06-15 Thread gilbertoca

Hi again,

I've seen this message every time I quit TomEE embedded (maven plugin):


The data-source name is "java:app/gace/MyDS" and we're using PostgreSQL 9.4
.

Is it a normal behavior?

Regards,
Gilberto



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/WARNING-Failed-to-unregister-the-JMX-name-JDBC-driver-org-postgresql-Driver-but-failed-to-unregister-tp4678894.html
Sent from the TomEE Users mailing list archive at Nabble.com.

Re: TomEE 7 logger heap leak?

2016-06-15 Thread Steve Goldsmith

Right, but the container still uses log4j, correct? I want everything to
use the same logger/format.


On Wed, Jun 15, 2016 at 10:43 AM, Romain Manni-Bucau 
wrote:

> this property just redirects logs to slf4j (and therefore logback if that's
> your impl). Then the logger eviction per classloader is on your
> charge/config.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-06-15 16:41 GMT+02:00 Steve Goldsmith :
>
> > Well, I'm using logback as well with slf4j.
> >
> > On Wed, Jun 15, 2016 at 10:36 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > wrote:
> >
> > > openejb.log.factory=slf4j is not good enough? We also need a
> confirmation
> > > our hypothesis are right or not.
> > >
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Wordpress Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Tomitriber
> > >  | JavaEE Factory
> > > 
> > >
> > > 2016-06-15 16:33 GMT+02:00 Steve Goldsmith :
> > >
> > > > OK, so what handler should I use?
> > > >
> > > > On Wed, Jun 15, 2016 at 3:20 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > I see, can be linked to the bridge and I'm not sure logback/jul
> > > > integration
> > > > > is able to respect classloaders (didn't check) but tomcat default
> > > > > LogManager does and we enforce the classloader normally where we
> can
> > so
> > > > it
> > > > > shouldn't leak.
> > > > >
> > > > > openejb.log.factory=slf4j should allow you to use logback without
> the
> > > > > bridge (IIRC you can miss first 2 log lines but their data are
> > > repeated a
> > > > > bit later so not a big issue). If it doesn't leak without these
> > changes
> > > > > then it would be interesting to test this.
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Wordpress Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Tomitriber
> > > > >  | JavaEE Factory
> > > > > 
> > > > >
> > > > > 2016-06-15 1:21 GMT+02:00 Steve Goldsmith :
> > > > >
> > > > > > I sent you a link to the configuration I use, but here's what I
> > have:
> > > > > >
> > > > > > In TOMEE/bin:
> > > > > >
> > > > > >- logback-config dir
> > > > > >- logback.xml
> > > > > >   - jul-to-slf4j-1.7.7.jar
> > > > > >- setenv.sh
> > > > > >   -
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> CLASSPATH=$CATALINA_HOME/bin/jul-to-slf4j-1.7.7.jar:$CATALINA_HOME/bin/slf4j-api-1.7.7.jar:$CATALINA_HOME/bin/logback-classic-1.1.2.jar:$CATALINA_HOME/bin/logback-core-1.1.2.jar:$CATALINA_HOME/bin/logback-config/
> > > > > >   - logback-classic-1.1.2.jar
> > > > > >- logback-core-1.1.2.jar
> > > > > >- slf4j-api-1.7.7.jar
> > > > > >
> > > > > > In TOMEE/conf:
> > > > > >
> > > > > >- logging.properties
> > > > > >   - handlers = org.slf4j.bridge.SLF4JBridgeHandler
> > > > > >
> > > > > > I just upgraded to 7.0.0 release from an April snapshot. First,
> > I'll
> > > > see
> > > > > if
> > > > > > it pops up again (it takes a week or so), then I'll remove
> > > > logback/slf4j
> > > > > > configuration changes. If there's a better way to integrate
> logback
> > > I'm
> > > > > all
> > > > > > ears.
> > > > > >
> > > > > > On Tue, Jun 14, 2016 at 6:37 PM, Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Not linked to jsonp.
> > > > > > >
> > > > > > > First time i see something linked to our logger and only case i
> > can
> > > > > think
> > > > > > > about are linked to bad config or not default setup so need
> more
> > > > > details
> > > > > > to
> > > > > > > validate or not and potentially fix it.
> > > > > > > Le 15 juin 2016 00:32, "Steve Goldsmith"  a
> > > écrit
> > > > :
> > > > > > >
> > > > > > > It could be
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-0-0-M3-memory-leak-suspect-td4678194.html
> > > > > > > since that server is running a snapshot. I'll upgrade to the
> > final
> > > > >

Re: TomEE 7 logger heap leak?

2016-06-15 Thread Romain Manni-Bucau

this property just redirects logs to slf4j (and therefore logback if that's
your impl). Then the logger eviction per classloader is on your
charge/config.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-06-15 16:41 GMT+02:00 Steve Goldsmith :

> Well, I'm using logback as well with slf4j.
>
> On Wed, Jun 15, 2016 at 10:36 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> wrote:
>
> > openejb.log.factory=slf4j is not good enough? We also need a confirmation
> > our hypothesis are right or not.
> >
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-06-15 16:33 GMT+02:00 Steve Goldsmith :
> >
> > > OK, so what handler should I use?
> > >
> > > On Wed, Jun 15, 2016 at 3:20 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > I see, can be linked to the bridge and I'm not sure logback/jul
> > > integration
> > > > is able to respect classloaders (didn't check) but tomcat default
> > > > LogManager does and we enforce the classloader normally where we can
> so
> > > it
> > > > shouldn't leak.
> > > >
> > > > openejb.log.factory=slf4j should allow you to use logback without the
> > > > bridge (IIRC you can miss first 2 log lines but their data are
> > repeated a
> > > > bit later so not a big issue). If it doesn't leak without these
> changes
> > > > then it would be interesting to test this.
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Wordpress Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Tomitriber
> > > >  | JavaEE Factory
> > > > 
> > > >
> > > > 2016-06-15 1:21 GMT+02:00 Steve Goldsmith :
> > > >
> > > > > I sent you a link to the configuration I use, but here's what I
> have:
> > > > >
> > > > > In TOMEE/bin:
> > > > >
> > > > >- logback-config dir
> > > > >- logback.xml
> > > > >   - jul-to-slf4j-1.7.7.jar
> > > > >- setenv.sh
> > > > >   -
> > > > >
> > > > >
> > > >
> > >
> >
> CLASSPATH=$CATALINA_HOME/bin/jul-to-slf4j-1.7.7.jar:$CATALINA_HOME/bin/slf4j-api-1.7.7.jar:$CATALINA_HOME/bin/logback-classic-1.1.2.jar:$CATALINA_HOME/bin/logback-core-1.1.2.jar:$CATALINA_HOME/bin/logback-config/
> > > > >   - logback-classic-1.1.2.jar
> > > > >- logback-core-1.1.2.jar
> > > > >- slf4j-api-1.7.7.jar
> > > > >
> > > > > In TOMEE/conf:
> > > > >
> > > > >- logging.properties
> > > > >   - handlers = org.slf4j.bridge.SLF4JBridgeHandler
> > > > >
> > > > > I just upgraded to 7.0.0 release from an April snapshot. First,
> I'll
> > > see
> > > > if
> > > > > it pops up again (it takes a week or so), then I'll remove
> > > logback/slf4j
> > > > > configuration changes. If there's a better way to integrate logback
> > I'm
> > > > all
> > > > > ears.
> > > > >
> > > > > On Tue, Jun 14, 2016 at 6:37 PM, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Not linked to jsonp.
> > > > > >
> > > > > > First time i see something linked to our logger and only case i
> can
> > > > think
> > > > > > about are linked to bad config or not default setup so need more
> > > > details
> > > > > to
> > > > > > validate or not and potentially fix it.
> > > > > > Le 15 juin 2016 00:32, "Steve Goldsmith"  a
> > écrit
> > > :
> > > > > >
> > > > > > It could be
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-0-0-M3-memory-leak-suspect-td4678194.html
> > > > > > since that server is running a snapshot. I'll upgrade to the
> final
> > > > > release.
> > > > > >
> > > > > > On Tue, Jun 14, 2016 at 5:04 PM, Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Not known and quite unlikely since it is the tomee/openejb only
> > > > logger
> > > > > so
> > > > > > > should be very few mem.
> > > > > > >
> > > > > > > What is your logging config?
> > > > > > >
> > > > > > > Can you reproduce it? Have some instance in prod for weeks
> > without
> > > >

Re: TomEE 7 logger heap leak?

2016-06-15 Thread Steve Goldsmith

Well, I'm using logback as well with slf4j.

On Wed, Jun 15, 2016 at 10:36 AM, Romain Manni-Bucau 
wrote:

> openejb.log.factory=slf4j is not good enough? We also need a confirmation
> our hypothesis are right or not.
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-06-15 16:33 GMT+02:00 Steve Goldsmith :
>
> > OK, so what handler should I use?
> >
> > On Wed, Jun 15, 2016 at 3:20 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > I see, can be linked to the bridge and I'm not sure logback/jul
> > integration
> > > is able to respect classloaders (didn't check) but tomcat default
> > > LogManager does and we enforce the classloader normally where we can so
> > it
> > > shouldn't leak.
> > >
> > > openejb.log.factory=slf4j should allow you to use logback without the
> > > bridge (IIRC you can miss first 2 log lines but their data are
> repeated a
> > > bit later so not a big issue). If it doesn't leak without these changes
> > > then it would be interesting to test this.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Wordpress Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Tomitriber
> > >  | JavaEE Factory
> > > 
> > >
> > > 2016-06-15 1:21 GMT+02:00 Steve Goldsmith :
> > >
> > > > I sent you a link to the configuration I use, but here's what I have:
> > > >
> > > > In TOMEE/bin:
> > > >
> > > >- logback-config dir
> > > >- logback.xml
> > > >   - jul-to-slf4j-1.7.7.jar
> > > >- setenv.sh
> > > >   -
> > > >
> > > >
> > >
> >
> CLASSPATH=$CATALINA_HOME/bin/jul-to-slf4j-1.7.7.jar:$CATALINA_HOME/bin/slf4j-api-1.7.7.jar:$CATALINA_HOME/bin/logback-classic-1.1.2.jar:$CATALINA_HOME/bin/logback-core-1.1.2.jar:$CATALINA_HOME/bin/logback-config/
> > > >   - logback-classic-1.1.2.jar
> > > >- logback-core-1.1.2.jar
> > > >- slf4j-api-1.7.7.jar
> > > >
> > > > In TOMEE/conf:
> > > >
> > > >- logging.properties
> > > >   - handlers = org.slf4j.bridge.SLF4JBridgeHandler
> > > >
> > > > I just upgraded to 7.0.0 release from an April snapshot. First, I'll
> > see
> > > if
> > > > it pops up again (it takes a week or so), then I'll remove
> > logback/slf4j
> > > > configuration changes. If there's a better way to integrate logback
> I'm
> > > all
> > > > ears.
> > > >
> > > > On Tue, Jun 14, 2016 at 6:37 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Not linked to jsonp.
> > > > >
> > > > > First time i see something linked to our logger and only case i can
> > > think
> > > > > about are linked to bad config or not default setup so need more
> > > details
> > > > to
> > > > > validate or not and potentially fix it.
> > > > > Le 15 juin 2016 00:32, "Steve Goldsmith"  a
> écrit
> > :
> > > > >
> > > > > It could be
> > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-0-0-M3-memory-leak-suspect-td4678194.html
> > > > > since that server is running a snapshot. I'll upgrade to the final
> > > > release.
> > > > >
> > > > > On Tue, Jun 14, 2016 at 5:04 PM, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Not known and quite unlikely since it is the tomee/openejb only
> > > logger
> > > > so
> > > > > > should be very few mem.
> > > > > >
> > > > > > What is your logging config?
> > > > > >
> > > > > > Can you reproduce it? Have some instance in prod for weeks
> without
> > > > issues
> > > > > > but these ones are not in 1000TPS family so can have missed sthg.
> > > > > > Le 14 juin 2016 22:56, "sgjava"  a écrit :
> > > > > >
> > > > > > > I'm running into a situation where after about a week of
> runtime
> > > the
> > > > > heap
> > > > > > > gets chewed up. I ran MAT on a heap dump and get:
> > > > > > >
> > > > > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > > > > "java.net.URLClassLoader @ 0x83332c88", occupies 1,581,490,368
> > > > (93.31%)
> > > > > > > bytes. The memory is accumulated in one instance of
> > > > > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by
> > " > > > > class
> > > > > > > loader>".
> > > > > > >
> > > > > > > Now I'm using logback similar to this
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: TomEE 7 logger heap leak?

2016-06-15 Thread Romain Manni-Bucau

openejb.log.factory=slf4j is not good enough? We also need a confirmation
our hypothesis are right or not.




Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-06-15 16:33 GMT+02:00 Steve Goldsmith :

> OK, so what handler should I use?
>
> On Wed, Jun 15, 2016 at 3:20 AM, Romain Manni-Bucau  >
> wrote:
>
> > I see, can be linked to the bridge and I'm not sure logback/jul
> integration
> > is able to respect classloaders (didn't check) but tomcat default
> > LogManager does and we enforce the classloader normally where we can so
> it
> > shouldn't leak.
> >
> > openejb.log.factory=slf4j should allow you to use logback without the
> > bridge (IIRC you can miss first 2 log lines but their data are repeated a
> > bit later so not a big issue). If it doesn't leak without these changes
> > then it would be interesting to test this.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-06-15 1:21 GMT+02:00 Steve Goldsmith :
> >
> > > I sent you a link to the configuration I use, but here's what I have:
> > >
> > > In TOMEE/bin:
> > >
> > >- logback-config dir
> > >- logback.xml
> > >   - jul-to-slf4j-1.7.7.jar
> > >- setenv.sh
> > >   -
> > >
> > >
> >
> CLASSPATH=$CATALINA_HOME/bin/jul-to-slf4j-1.7.7.jar:$CATALINA_HOME/bin/slf4j-api-1.7.7.jar:$CATALINA_HOME/bin/logback-classic-1.1.2.jar:$CATALINA_HOME/bin/logback-core-1.1.2.jar:$CATALINA_HOME/bin/logback-config/
> > >   - logback-classic-1.1.2.jar
> > >- logback-core-1.1.2.jar
> > >- slf4j-api-1.7.7.jar
> > >
> > > In TOMEE/conf:
> > >
> > >- logging.properties
> > >   - handlers = org.slf4j.bridge.SLF4JBridgeHandler
> > >
> > > I just upgraded to 7.0.0 release from an April snapshot. First, I'll
> see
> > if
> > > it pops up again (it takes a week or so), then I'll remove
> logback/slf4j
> > > configuration changes. If there's a better way to integrate logback I'm
> > all
> > > ears.
> > >
> > > On Tue, Jun 14, 2016 at 6:37 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Not linked to jsonp.
> > > >
> > > > First time i see something linked to our logger and only case i can
> > think
> > > > about are linked to bad config or not default setup so need more
> > details
> > > to
> > > > validate or not and potentially fix it.
> > > > Le 15 juin 2016 00:32, "Steve Goldsmith"  a écrit
> :
> > > >
> > > > It could be
> > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-0-0-M3-memory-leak-suspect-td4678194.html
> > > > since that server is running a snapshot. I'll upgrade to the final
> > > release.
> > > >
> > > > On Tue, Jun 14, 2016 at 5:04 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Not known and quite unlikely since it is the tomee/openejb only
> > logger
> > > so
> > > > > should be very few mem.
> > > > >
> > > > > What is your logging config?
> > > > >
> > > > > Can you reproduce it? Have some instance in prod for weeks without
> > > issues
> > > > > but these ones are not in 1000TPS family so can have missed sthg.
> > > > > Le 14 juin 2016 22:56, "sgjava"  a écrit :
> > > > >
> > > > > > I'm running into a situation where after about a week of runtime
> > the
> > > > heap
> > > > > > gets chewed up. I ran MAT on a heap dump and get:
> > > > > >
> > > > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > > > "java.net.URLClassLoader @ 0x83332c88", occupies 1,581,490,368
> > > (93.31%)
> > > > > > bytes. The memory is accumulated in one instance of
> > > > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by
> " > > > class
> > > > > > loader>".
> > > > > >
> > > > > > Now I'm using logback similar to this
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> http://hwellmann.blogspot.com/2012/11/logging-with-slf4j-and-logback-in.html
> > > > > >
> > > > > > Is this a known issue?
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > View this message in context:
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-logger-heap-leak-tp4678876.html
> > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > > >
> > > > >
> > >

Re: TomEE 7 logger heap leak?

2016-06-15 Thread Steve Goldsmith

OK, so what handler should I use?

On Wed, Jun 15, 2016 at 3:20 AM, Romain Manni-Bucau 
wrote:

> I see, can be linked to the bridge and I'm not sure logback/jul integration
> is able to respect classloaders (didn't check) but tomcat default
> LogManager does and we enforce the classloader normally where we can so it
> shouldn't leak.
>
> openejb.log.factory=slf4j should allow you to use logback without the
> bridge (IIRC you can miss first 2 log lines but their data are repeated a
> bit later so not a big issue). If it doesn't leak without these changes
> then it would be interesting to test this.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-06-15 1:21 GMT+02:00 Steve Goldsmith :
>
> > I sent you a link to the configuration I use, but here's what I have:
> >
> > In TOMEE/bin:
> >
> >- logback-config dir
> >- logback.xml
> >   - jul-to-slf4j-1.7.7.jar
> >- setenv.sh
> >   -
> >
> >
> CLASSPATH=$CATALINA_HOME/bin/jul-to-slf4j-1.7.7.jar:$CATALINA_HOME/bin/slf4j-api-1.7.7.jar:$CATALINA_HOME/bin/logback-classic-1.1.2.jar:$CATALINA_HOME/bin/logback-core-1.1.2.jar:$CATALINA_HOME/bin/logback-config/
> >   - logback-classic-1.1.2.jar
> >- logback-core-1.1.2.jar
> >- slf4j-api-1.7.7.jar
> >
> > In TOMEE/conf:
> >
> >- logging.properties
> >   - handlers = org.slf4j.bridge.SLF4JBridgeHandler
> >
> > I just upgraded to 7.0.0 release from an April snapshot. First, I'll see
> if
> > it pops up again (it takes a week or so), then I'll remove logback/slf4j
> > configuration changes. If there's a better way to integrate logback I'm
> all
> > ears.
> >
> > On Tue, Jun 14, 2016 at 6:37 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > Not linked to jsonp.
> > >
> > > First time i see something linked to our logger and only case i can
> think
> > > about are linked to bad config or not default setup so need more
> details
> > to
> > > validate or not and potentially fix it.
> > > Le 15 juin 2016 00:32, "Steve Goldsmith"  a écrit :
> > >
> > > It could be
> > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-0-0-M3-memory-leak-suspect-td4678194.html
> > > since that server is running a snapshot. I'll upgrade to the final
> > release.
> > >
> > > On Tue, Jun 14, 2016 at 5:04 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Not known and quite unlikely since it is the tomee/openejb only
> logger
> > so
> > > > should be very few mem.
> > > >
> > > > What is your logging config?
> > > >
> > > > Can you reproduce it? Have some instance in prod for weeks without
> > issues
> > > > but these ones are not in 1000TPS family so can have missed sthg.
> > > > Le 14 juin 2016 22:56, "sgjava"  a écrit :
> > > >
> > > > > I'm running into a situation where after about a week of runtime
> the
> > > heap
> > > > > gets chewed up. I ran MAT on a heap dump and get:
> > > > >
> > > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > > "java.net.URLClassLoader @ 0x83332c88", occupies 1,581,490,368
> > (93.31%)
> > > > > bytes. The memory is accumulated in one instance of
> > > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by " > > class
> > > > > loader>".
> > > > >
> > > > > Now I'm using logback similar to this
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> http://hwellmann.blogspot.com/2012/11/logging-with-slf4j-and-logback-in.html
> > > > >
> > > > > Is this a known issue?
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-logger-heap-leak-tp4678876.html
> > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Steven P. Goldsmith
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>



-- 
Steven P. Goldsmith

Re: SSL install config errors.

2016-06-15 Thread Romain Manni-Bucau

2016-06-15 14:26 GMT+02:00 paulhr :

> A few more facts during continued analysis.
>
> This error does not happen on my Eclipse Mars2 instance on my local
> Widows 7 workstation.
>
>
Can it mean you used an instance which can have old config files?


> This is not an open source project.  Sorry, I can not put any artifacts
> on public site.
>
>
You don't have to, if you are right and server.xml is the issue you just
need to put there server.xml but ensure mvn tomee:run fails as it does for
you


PS: don't forget to send us the error you get on server.xml parsing


>
> On 6/15/2016 7:50 AM, Romain Manni-Bucau [via TomEE & OpenEJB] wrote:
> > then the error you pasted is not the one you get
> >
> > can you setup on github a project with the config in src/main/tomee/conf
> > and tomee-maven-plugin setup to reproduce your issue with "mvn package
> > tomee:run"?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github
> >  |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-06-15 12:32 GMT+02:00 paulhr <[hidden email]
> > >:
> >
> > > I don't have a resources.xml file anywhere in the Tomee install.
> > >
> > > [root] # find /opt -name resources.xml
> > > [root] #
> > >
> > > When I comment out the  XML element the error goes away.
> > >
> > >
> > > On 6/15/2016 2:43 AM, Romain Manni-Bucau [via TomEE & OpenEJB] wrote:
> > > > Hi
> > > >
> > > > this error is in resources.xml not in server.xml. You put  > ...> but
> > > > this is not a supported entry there.
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Wordpress Blog
> > > >  | Github
> > > >  |
> > > > LinkedIn  | Tomitriber
> > > >  | JavaEE Factory
> > > > 
> > > >
> > > > 2016-06-15 1:06 GMT+02:00 paulhr <[hidden email]
> > > > >:
> > > >
> > > > > I am using this Connector XML Element for in my server.xml file as
> > > > per my
> > > > > SSL
> > > > > vendors instructions for Tomcat.
> > > > >
> > > > >  > > > > protocol="org.apache.coyote.http11.Http11Protocol"
> > > > >maxThreads="150" minSpareThreads="25"
> > > > maxSpareThreads="75"
> > > > > enableLookups="false" disableUploadTimeout="true"
> > > > >acceptCount="100" SSLEnabled="true" scheme="https"
> > > > > secure="true"  keyAlias="server"
> > > > keystoreFile="/root/usque_software.jks"
> > > > >keystorePass="__" clientAuth="false"
> > sslProtocol="TLS"
> > > > > xpoweredBy="false"  />
> > > > >
> > > > > We spent over an hour trouble shooting the issue and have come no
> > > > closer to
> > > > > resolving it.
> > > > >
> > > > > The Catalina.log has the following exception stack.  It seems like
> > > > there is
> > > > > an XML parsing error.  There does not seem to be a XSD defined
> > for the
> > > > > server.xml file to validate against.  Can someone tell me if Tomee
> > > > 1.7.4
> > > > > supports all the element attributes provided?
> > > > >
> > > > > INFO: Using
> > > > >
> > > >
> > 'openejb.jndiname.format={deploymentId}{interfaceType.openejbLegacyName}'
> > > > > Jun 14, 2016 7:23:31 PM org.apache.openejb.config.ReadDescriptors
> > > > > readResourcesXml
> > > > > WARNING: can't read
> > > > > org.apache.openejb.config.ReadDescriptors$UrlSource@183dc7ad to
> > load
> > > > > resources for module
> > org.apache.openejb.config.ResourcesModule@2b2bef9
> > > > > javax.xml.bind.UnmarshalException: unexpected element
> > > > > (uri:"http://www.openejb.org/System/Configuration;, local:"role").
> > > > > Expected
> > > > > elements are
> > > > > <{http://www.openejb.org/System/Configuration}Service>,<{
> > > > > http://www.openejb.org/System/Configuration}Resource>,<{
> > > > > http://www.openejb.org/System/Configuration}JndiProvider>,<{
> > > > > http://www.openejb.org/System/Configuration}Connector>,<{
> > > > > http://www.openejb.org/System/Configuration}Container>
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:662)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:258)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:253)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: SSL install config errors.

2016-06-15 Thread paulhr

A few more facts during continued analysis.

This error does not happen on my Eclipse Mars2 instance on my local 
Widows 7 workstation.

This is not an open source project.  Sorry, I can not put any artifacts 
on public site.


On 6/15/2016 7:50 AM, Romain Manni-Bucau [via TomEE & OpenEJB] wrote:
> then the error you pasted is not the one you get
>
> can you setup on github a project with the config in src/main/tomee/conf
> and tomee-maven-plugin setup to reproduce your issue with "mvn package
> tomee:run"?
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github 
>  |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-06-15 12:32 GMT+02:00 paulhr <[hidden email] 
> >:
>
> > I don't have a resources.xml file anywhere in the Tomee install.
> >
> > [root] # find /opt -name resources.xml
> > [root] #
> >
> > When I comment out the  XML element the error goes away.
> >
> >
> > On 6/15/2016 2:43 AM, Romain Manni-Bucau [via TomEE & OpenEJB] wrote:
> > > Hi
> > >
> > > this error is in resources.xml not in server.xml. You put  ...> but
> > > this is not a supported entry there.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Wordpress Blog
> > >  | Github
> > >  |
> > > LinkedIn  | Tomitriber
> > >  | JavaEE Factory
> > > 
> > >
> > > 2016-06-15 1:06 GMT+02:00 paulhr <[hidden email]
> > > >:
> > >
> > > > I am using this Connector XML Element for in my server.xml file as
> > > per my
> > > > SSL
> > > > vendors instructions for Tomcat.
> > > >
> > > >  > > > protocol="org.apache.coyote.http11.Http11Protocol"
> > > >maxThreads="150" minSpareThreads="25"
> > > maxSpareThreads="75"
> > > > enableLookups="false" disableUploadTimeout="true"
> > > >acceptCount="100" SSLEnabled="true" scheme="https"
> > > > secure="true"  keyAlias="server"
> > > keystoreFile="/root/usque_software.jks"
> > > >keystorePass="__" clientAuth="false" 
> sslProtocol="TLS"
> > > > xpoweredBy="false"  />
> > > >
> > > > We spent over an hour trouble shooting the issue and have come no
> > > closer to
> > > > resolving it.
> > > >
> > > > The Catalina.log has the following exception stack.  It seems like
> > > there is
> > > > an XML parsing error.  There does not seem to be a XSD defined 
> for the
> > > > server.xml file to validate against.  Can someone tell me if Tomee
> > > 1.7.4
> > > > supports all the element attributes provided?
> > > >
> > > > INFO: Using
> > > >
> > > 
> 'openejb.jndiname.format={deploymentId}{interfaceType.openejbLegacyName}'
> > > > Jun 14, 2016 7:23:31 PM org.apache.openejb.config.ReadDescriptors
> > > > readResourcesXml
> > > > WARNING: can't read
> > > > org.apache.openejb.config.ReadDescriptors$UrlSource@183dc7ad to 
> load
> > > > resources for module 
> org.apache.openejb.config.ResourcesModule@2b2bef9
> > > > javax.xml.bind.UnmarshalException: unexpected element
> > > > (uri:"http://www.openejb.org/System/Configuration;, local:"role").
> > > > Expected
> > > > elements are
> > > > <{http://www.openejb.org/System/Configuration}Service>,<{
> > > > http://www.openejb.org/System/Configuration}Resource>,<{
> > > > http://www.openejb.org/System/Configuration}JndiProvider>,<{
> > > > http://www.openejb.org/System/Configuration}Connector>,<{
> > > > http://www.openejb.org/System/Configuration}Container>
> > > > at
> > > >
> > > >
> > >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:662)
> > > > at
> > > >
> > > >
> > >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:258)
> > > > at
> > > >
> > > >
> > >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:253)
> > > > at
> > > >
> > > >
> > >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:120)
> > > > at
> > > >
> > > >
> > >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:105)
> > > > at
> > > >
> > > >
> > >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:262)
> > > > at
> > > >
> > > >
> > >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:498)
> > > > at
> > > >
> > > >
> > >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:480)
> > >

Re: SSL install config errors.

2016-06-15 Thread Romain Manni-Bucau

then the error you pasted is not the one you get

can you setup on github a project with the config in src/main/tomee/conf
and tomee-maven-plugin setup to reproduce your issue with "mvn package
tomee:run"?


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-06-15 12:32 GMT+02:00 paulhr :

> I don't have a resources.xml file anywhere in the Tomee install.
>
> [root] # find /opt -name resources.xml
> [root] #
>
> When I comment out the  XML element the error goes away.
>
>
> On 6/15/2016 2:43 AM, Romain Manni-Bucau [via TomEE & OpenEJB] wrote:
> > Hi
> >
> > this error is in resources.xml not in server.xml. You put  but
> > this is not a supported entry there.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github
> >  |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-06-15 1:06 GMT+02:00 paulhr <[hidden email]
> > >:
> >
> > > I am using this Connector XML Element for in my server.xml file as
> > per my
> > > SSL
> > > vendors instructions for Tomcat.
> > >
> > >  > > protocol="org.apache.coyote.http11.Http11Protocol"
> > >maxThreads="150" minSpareThreads="25"
> > maxSpareThreads="75"
> > > enableLookups="false" disableUploadTimeout="true"
> > >acceptCount="100" SSLEnabled="true" scheme="https"
> > > secure="true"  keyAlias="server"
> > keystoreFile="/root/usque_software.jks"
> > >keystorePass="__" clientAuth="false" sslProtocol="TLS"
> > > xpoweredBy="false"  />
> > >
> > > We spent over an hour trouble shooting the issue and have come no
> > closer to
> > > resolving it.
> > >
> > > The Catalina.log has the following exception stack.  It seems like
> > there is
> > > an XML parsing error.  There does not seem to be a XSD defined for the
> > > server.xml file to validate against.  Can someone tell me if Tomee
> > 1.7.4
> > > supports all the element attributes provided?
> > >
> > > INFO: Using
> > >
> > 'openejb.jndiname.format={deploymentId}{interfaceType.openejbLegacyName}'
> > > Jun 14, 2016 7:23:31 PM org.apache.openejb.config.ReadDescriptors
> > > readResourcesXml
> > > WARNING: can't read
> > > org.apache.openejb.config.ReadDescriptors$UrlSource@183dc7ad to load
> > > resources for module org.apache.openejb.config.ResourcesModule@2b2bef9
> > > javax.xml.bind.UnmarshalException: unexpected element
> > > (uri:"http://www.openejb.org/System/Configuration;, local:"role").
> > > Expected
> > > elements are
> > > <{http://www.openejb.org/System/Configuration}Service>,<{
> > > http://www.openejb.org/System/Configuration}Resource>,<{
> > > http://www.openejb.org/System/Configuration}JndiProvider>,<{
> > > http://www.openejb.org/System/Configuration}Connector>,<{
> > > http://www.openejb.org/System/Configuration}Container>
> > > at
> > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:662)
> > > at
> > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:258)
> > > at
> > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:253)
> > > at
> > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:120)
> > > at
> > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:105)
> > > at
> > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:262)
> > > at
> > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:498)
> > > at
> > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:480)
> > > at
> > >
> > >
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:150)
> > > at
> > > org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551)
> > > at
> > >
> > >
> >
> org.apache.openejb.config.sys.JaxbOpenejb$NamespaceFilter.startElement(JaxbOpenejb.java:350)
> > > at
> > >
> > >
> >
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509)
> > > at
> > >
> > >
> >
>

Re: SSL install config errors.

2016-06-15 Thread paulhr

I don't have a resources.xml file anywhere in the Tomee install.

[root] # find /opt -name resources.xml
[root] #

When I comment out the  XML element the error goes away.


On 6/15/2016 2:43 AM, Romain Manni-Bucau [via TomEE & OpenEJB] wrote:
> Hi
>
> this error is in resources.xml not in server.xml. You put  but
> this is not a supported entry there.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github 
>  |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-06-15 1:06 GMT+02:00 paulhr <[hidden email] 
> >:
>
> > I am using this Connector XML Element for in my server.xml file as 
> per my
> > SSL
> > vendors instructions for Tomcat.
> >
> >  > protocol="org.apache.coyote.http11.Http11Protocol"
> >maxThreads="150" minSpareThreads="25" 
> maxSpareThreads="75"
> > enableLookups="false" disableUploadTimeout="true"
> >acceptCount="100" SSLEnabled="true" scheme="https"
> > secure="true"  keyAlias="server" 
> keystoreFile="/root/usque_software.jks"
> >keystorePass="__" clientAuth="false" sslProtocol="TLS"
> > xpoweredBy="false"  />
> >
> > We spent over an hour trouble shooting the issue and have come no 
> closer to
> > resolving it.
> >
> > The Catalina.log has the following exception stack.  It seems like 
> there is
> > an XML parsing error.  There does not seem to be a XSD defined for the
> > server.xml file to validate against.  Can someone tell me if Tomee 
> 1.7.4
> > supports all the element attributes provided?
> >
> > INFO: Using
> > 
> 'openejb.jndiname.format={deploymentId}{interfaceType.openejbLegacyName}'
> > Jun 14, 2016 7:23:31 PM org.apache.openejb.config.ReadDescriptors
> > readResourcesXml
> > WARNING: can't read
> > org.apache.openejb.config.ReadDescriptors$UrlSource@183dc7ad to load
> > resources for module org.apache.openejb.config.ResourcesModule@2b2bef9
> > javax.xml.bind.UnmarshalException: unexpected element
> > (uri:"http://www.openejb.org/System/Configuration;, local:"role").
> > Expected
> > elements are
> > <{http://www.openejb.org/System/Configuration}Service>,<{
> > http://www.openejb.org/System/Configuration}Resource>,<{
> > http://www.openejb.org/System/Configuration}JndiProvider>,<{
> > http://www.openejb.org/System/Configuration}Connector>,<{
> > http://www.openejb.org/System/Configuration}Container>
> > at
> >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:662)
> > at
> >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:258)
> > at
> >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:253)
> > at
> >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:120)
> > at
> >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:105)
> > at
> >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:262)
> > at
> >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:498)
> > at
> >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:480)
> > at
> >
> > 
> com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:150)
> > at
> > org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551)
> > at
> >
> > 
> org.apache.openejb.config.sys.JaxbOpenejb$NamespaceFilter.startElement(JaxbOpenejb.java:350)
> > at
> >
> > 
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509)
> > at
> >
> > 
> com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182)
> > at
> >
> > 
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:357)
> > at
> >
> > 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2787)
> > at
> >
> > 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
> > at
> >
> > 
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:118)
> > at
> >
> > 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
> > at
> >
> > 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)

Re: SSL install config errors.

2016-06-15 Thread Romain Manni-Bucau

Hi

this error is in resources.xml not in server.xml. You put  but
this is not a supported entry there.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-06-15 1:06 GMT+02:00 paulhr :

> I am using this Connector XML Element for in my server.xml file as per my
> SSL
> vendors instructions for Tomcat.
>
>  protocol="org.apache.coyote.http11.Http11Protocol"
>maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
> enableLookups="false" disableUploadTimeout="true"
>acceptCount="100" SSLEnabled="true" scheme="https"
> secure="true"  keyAlias="server" keystoreFile="/root/usque_software.jks"
>keystorePass="__" clientAuth="false" sslProtocol="TLS"
> xpoweredBy="false"  />
>
> We spent over an hour trouble shooting the issue and have come no closer to
> resolving it.
>
> The Catalina.log has the following exception stack.  It seems like there is
> an XML parsing error.  There does not seem to be a XSD defined for the
> server.xml file to validate against.  Can someone tell me if Tomee 1.7.4
> supports all the element attributes provided?
>
> INFO: Using
> 'openejb.jndiname.format={deploymentId}{interfaceType.openejbLegacyName}'
> Jun 14, 2016 7:23:31 PM org.apache.openejb.config.ReadDescriptors
> readResourcesXml
> WARNING: can't read
> org.apache.openejb.config.ReadDescriptors$UrlSource@183dc7ad to load
> resources for module org.apache.openejb.config.ResourcesModule@2b2bef9
> javax.xml.bind.UnmarshalException: unexpected element
> (uri:"http://www.openejb.org/System/Configuration;, local:"role").
> Expected
> elements are
> <{http://www.openejb.org/System/Configuration}Service>,<{
> http://www.openejb.org/System/Configuration}Resource>,<{
> http://www.openejb.org/System/Configuration}JndiProvider>,<{
> http://www.openejb.org/System/Configuration}Connector>,<{
> http://www.openejb.org/System/Configuration}Container>
> at
>
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:662)
> at
>
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:258)
> at
>
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:253)
> at
>
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:120)
> at
>
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:105)
> at
>
> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:262)
> at
>
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:498)
> at
>
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:480)
> at
>
> com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:150)
> at
> org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551)
> at
>
> org.apache.openejb.config.sys.JaxbOpenejb$NamespaceFilter.startElement(JaxbOpenejb.java:350)
> at
>
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509)
> at
>
> com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182)
> at
>
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:357)
> at
>
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2787)
> at
>
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
> at
>
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:118)
> at
>
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
> at
>
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
> at
>
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
> at
>
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
>
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
>
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
> at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:357)
> at

Re: TomEE 7 logger heap leak?

2016-06-15 Thread Romain Manni-Bucau

I see, can be linked to the bridge and I'm not sure logback/jul integration
is able to respect classloaders (didn't check) but tomcat default
LogManager does and we enforce the classloader normally where we can so it
shouldn't leak.

openejb.log.factory=slf4j should allow you to use logback without the
bridge (IIRC you can miss first 2 log lines but their data are repeated a
bit later so not a big issue). If it doesn't leak without these changes
then it would be interesting to test this.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-06-15 1:21 GMT+02:00 Steve Goldsmith :

> I sent you a link to the configuration I use, but here's what I have:
>
> In TOMEE/bin:
>
>- logback-config dir
>- logback.xml
>   - jul-to-slf4j-1.7.7.jar
>- setenv.sh
>   -
>
> CLASSPATH=$CATALINA_HOME/bin/jul-to-slf4j-1.7.7.jar:$CATALINA_HOME/bin/slf4j-api-1.7.7.jar:$CATALINA_HOME/bin/logback-classic-1.1.2.jar:$CATALINA_HOME/bin/logback-core-1.1.2.jar:$CATALINA_HOME/bin/logback-config/
>   - logback-classic-1.1.2.jar
>- logback-core-1.1.2.jar
>- slf4j-api-1.7.7.jar
>
> In TOMEE/conf:
>
>- logging.properties
>   - handlers = org.slf4j.bridge.SLF4JBridgeHandler
>
> I just upgraded to 7.0.0 release from an April snapshot. First, I'll see if
> it pops up again (it takes a week or so), then I'll remove logback/slf4j
> configuration changes. If there's a better way to integrate logback I'm all
> ears.
>
> On Tue, Jun 14, 2016 at 6:37 PM, Romain Manni-Bucau  >
> wrote:
>
> > Not linked to jsonp.
> >
> > First time i see something linked to our logger and only case i can think
> > about are linked to bad config or not default setup so need more details
> to
> > validate or not and potentially fix it.
> > Le 15 juin 2016 00:32, "Steve Goldsmith"  a écrit :
> >
> > It could be
> >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-0-0-M3-memory-leak-suspect-td4678194.html
> > since that server is running a snapshot. I'll upgrade to the final
> release.
> >
> > On Tue, Jun 14, 2016 at 5:04 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > Not known and quite unlikely since it is the tomee/openejb only logger
> so
> > > should be very few mem.
> > >
> > > What is your logging config?
> > >
> > > Can you reproduce it? Have some instance in prod for weeks without
> issues
> > > but these ones are not in 1000TPS family so can have missed sthg.
> > > Le 14 juin 2016 22:56, "sgjava"  a écrit :
> > >
> > > > I'm running into a situation where after about a week of runtime the
> > heap
> > > > gets chewed up. I ran MAT on a heap dump and get:
> > > >
> > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > "java.net.URLClassLoader @ 0x83332c88", occupies 1,581,490,368
> (93.31%)
> > > > bytes. The memory is accumulated in one instance of
> > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by " > class
> > > > loader>".
> > > >
> > > > Now I'm using logback similar to this
> > > >
> > > >
> > >
> >
> >
> http://hwellmann.blogspot.com/2012/11/logging-with-slf4j-and-logback-in.html
> > > >
> > > > Is this a known issue?
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-logger-heap-leak-tp4678876.html
> > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
>
>
> --
> Steven P. Goldsmith
>

Re: CXF and WebSocket messages are merged together

Re: CXF and WebSocket messages are merged together

Re: NetBeans 8.1 does not think TomEE 7.0.0 has started

Re: old API 'file:/C:/Program%20Files/tomcat-8.5.3-tomee7/lib/annotations-api.jar' was found on the classpath

Re: NetBeans 8.1 does not think TomEE 7.0.0 has started

Re: NetBeans 8.1 does not think TomEE 7.0.0 has started

old API 'file:/C:/Program%20Files/tomcat-8.5.3-tomee7/lib/annotations-api.jar' was found on the classpath

Re: Exclusions.list not working

Re: Exclusions.list not working

NetBeans 8.1 does not think TomEE 7.0.0 has started

Re: Exclusions.list not working

Re: New install hangs at startup.

Exclusions.list not working

Re: Error with TomeeJaxRsService when deploy application as .ear, but not when it is simply a .war

Re: Moving EJB app from WebSphere App Server 8.5 to TomEE 1.7.3

Re: Error with TomeeJaxRsService when deploy application as .ear, but not when it is simply a .war

Re: TomEE 7 logger heap leak?

Re: WARNING: Failed to unregister the JMX name && JDBC driver [org.postgresql.Driver] but failed to unregister

WARNING: Failed to unregister the JMX name && JDBC driver [org.postgresql.Driver] but failed to unregister

Re: TomEE 7 logger heap leak?

Re: TomEE 7 logger heap leak?

Re: TomEE 7 logger heap leak?

Re: TomEE 7 logger heap leak?

Re: TomEE 7 logger heap leak?

Re: SSL install config errors.

Re: SSL install config errors.

Re: SSL install config errors.

Re: SSL install config errors.

Re: SSL install config errors.

Re: TomEE 7 logger heap leak?

30 matches

Site Navigation

Mail list logo

Footer information