date:20121216

Yes and no, it makes the connection being from the client why is better for
it and it works - when websockets can have issues with proxies and so on.
Websocket are nice when you have a real protocol...just create one and ask
the client to ask for an update with a timer, that's already better and you
keep the full connected advantages
Le 17 déc. 2012 08:54, "Howard W. Smith, Jr."  a
écrit :

> Polling is too much network traffic in my opinion. Websocket is instant
> messaging. No need to add polling code and xhtml here there for different
> type of messages coming from server and no need of an ajax request to
> server throughout entire session just to get an update from the server.
>  On Dec 17, 2012 2:47 AM, "Romain Manni-Bucau" 
> wrote:
>
> > Side note: if your need is pushing regularly to the client just having
> some
> > client polling can make it far easier to manage on both sides...
> > Le 17 déc. 2012 08:33, "Howard W. Smith, Jr."  a
> > écrit :
> >
> > > Almost forgot...PrimeFaces peer/friend of mine informed me that JMS is
> > good
> > > for running two instances of an app, similar to load balancer.
> > >
> > > Prior to using TomEE, I really wanted to use PrimeFaces Push (powered
> by
> > > Atmosphere/websocket), and at that time, I was thinking that I could
> > > possibly run Tomcat or TomEE just to push messages to the clients of my
> > app
> > > running on Glassfish, since Glassfish had issues with PrimeFaces Push
> > > (Atmosphere). I think he said that tomEE and Glassfish could do that,
> but
> > > they would have to communicate via JMS or the two servlets would have
> to
> > > serve requests/responses, appropriately, via JMS.
> > >
> > > I am probably not stating the above correctly as he said, but that's
> how
> > I
> > > understood what he told me.
> > >
> > > Now that I'm only using tomEE, there is no need to do such a thing.
> > Loving
> > > TomEE!!!
> > >
> > >
> > >
> > > On Mon, Dec 17, 2012 at 2:26 AM, Howard W. Smith, Jr. <
> > > smithh032...@gmail.com> wrote:
> > >
> > > > Very interesting discussion and responses here! Anthony motivates me
> to
> > > > jump on the bandwagon of using JMS/message-driven-beans, and at the
> > same
> > > > time, Romain tells me, not much need (for local) in a Java EE 6
> > > > application. :)
> > > >
> > > > Either way, i have not ruled out JMS. I have done some strategic
> coding
> > > on
> > > > my part to avoid @Schedule or use of timer service...using Date class
> > to
> > > > postpone pushing data to google calendar, and only pushing when there
> > is
> > > a
> > > > new date to update...application-wide. At first, i was pushing data
> to
> > > > google calendar after 'every' update request... sending over 1,000
> > > requests
> > > > to google calendar sometimes or daily (adding and deleting events on
> > > google
> > > > calendar to keep google calendar in sync with the database), but I
> cut
> > > that
> > > > back (or decreased the # of requests) with the new code I developed
> 2+
> > > > months ago. just makes for a faster user experience since they
> > requested
> > > to
> > > > have data updated via ajax on change/selection of this field, and
> that
> > > > field.
> > > >
> > > > Right now, JMS would be similar to a nice science project for me...
> > just
> > > > to see if I can do it and the success of it.
> > > >
> > > >
> > > > On Mon, Dec 17, 2012 at 1:57 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > > wrote:
> > > >
> > > >> I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it on
> > the
> > > >> road qince javaee 6, no more.
> > > >>
> > > >> It works but i dont find it effective when it stays local
> > > >>
> > > >
> > > >
> > >
> >
>

link drop in wars unviable

2012-12-16 Thread José Luiz Siesler Junior

God nigth.

The links 
tomee-plus-webapp-1.5.1.warand
tomee-webapp-1.5.1.warare
unviable. I
tried to download all links on the page, but all are broken.

Someone could send the files through war or other link that is not broken?

Tks.
Jose.

Re: Why are Tomcat's threads more costly than background threads?

Polling is too much network traffic in my opinion. Websocket is instant
messaging. No need to add polling code and xhtml here there for different
type of messages coming from server and no need of an ajax request to
server throughout entire session just to get an update from the server.
 On Dec 17, 2012 2:47 AM, "Romain Manni-Bucau" 
wrote:

> Side note: if your need is pushing regularly to the client just having some
> client polling can make it far easier to manage on both sides...
> Le 17 déc. 2012 08:33, "Howard W. Smith, Jr."  a
> écrit :
>
> > Almost forgot...PrimeFaces peer/friend of mine informed me that JMS is
> good
> > for running two instances of an app, similar to load balancer.
> >
> > Prior to using TomEE, I really wanted to use PrimeFaces Push (powered by
> > Atmosphere/websocket), and at that time, I was thinking that I could
> > possibly run Tomcat or TomEE just to push messages to the clients of my
> app
> > running on Glassfish, since Glassfish had issues with PrimeFaces Push
> > (Atmosphere). I think he said that tomEE and Glassfish could do that, but
> > they would have to communicate via JMS or the two servlets would have to
> > serve requests/responses, appropriately, via JMS.
> >
> > I am probably not stating the above correctly as he said, but that's how
> I
> > understood what he told me.
> >
> > Now that I'm only using tomEE, there is no need to do such a thing.
> Loving
> > TomEE!!!
> >
> >
> >
> > On Mon, Dec 17, 2012 at 2:26 AM, Howard W. Smith, Jr. <
> > smithh032...@gmail.com> wrote:
> >
> > > Very interesting discussion and responses here! Anthony motivates me to
> > > jump on the bandwagon of using JMS/message-driven-beans, and at the
> same
> > > time, Romain tells me, not much need (for local) in a Java EE 6
> > > application. :)
> > >
> > > Either way, i have not ruled out JMS. I have done some strategic coding
> > on
> > > my part to avoid @Schedule or use of timer service...using Date class
> to
> > > postpone pushing data to google calendar, and only pushing when there
> is
> > a
> > > new date to update...application-wide. At first, i was pushing data to
> > > google calendar after 'every' update request... sending over 1,000
> > requests
> > > to google calendar sometimes or daily (adding and deleting events on
> > google
> > > calendar to keep google calendar in sync with the database), but I cut
> > that
> > > back (or decreased the # of requests) with the new code I developed 2+
> > > months ago. just makes for a faster user experience since they
> requested
> > to
> > > have data updated via ajax on change/selection of this field, and that
> > > field.
> > >
> > > Right now, JMS would be similar to a nice science project for me...
> just
> > > to see if I can do it and the success of it.
> > >
> > >
> > > On Mon, Dec 17, 2012 at 1:57 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > > wrote:
> > >
> > >> I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it on
> the
> > >> road qince javaee 6, no more.
> > >>
> > >> It works but i dont find it effective when it stays local
> > >>
> > >
> > >
> >
>

Re: Reusing Datasource

2012-12-16 Thread Jean-Louis MONTEIRO

I think the more related to synonyms
It's possible for ejbs, but we don't actually have the same feature for
datasources

JLouis


2012/12/17 Romain Manni-Bucau 

> Hi,
>
> First i think we never release openejb 3.2
>
> Then you can define the datasource globally either in conf/openejb.xml or
> as properties of the container (initialcontext). Just match the expectes
> name in persistence.xml
> Le 17 déc. 2012 08:25, "tkayser"  a écrit :
>
> > Hi,
> >
> > I am using Openejb 3.2 with an Embedded Configuration. I stumbled upon
> the
> > following problem, for which I found a workaround but i still wonder if
> > there is no better solution.
> >
> > For my code I use two different DataBases. Further i use different
> > ejb.jar's
> > which are not under my control. So I can't change the persistence.xml or
> > anything. Understandable  the auto-linking can't guess the correct Data
> > Source for the different ejb.jars to use. So my workaround ist to define
> > for
> > each JNDI-Name the ejb.jars definie in their persistence.xml the correct
> > database:
> >
> >  = new:/Resource?type=Datasource
> > 
> >
> >  = new:/Resource?type=Datasource
> > 
> >
> >  = new:/Resource?type=Datasource
> > 
> >
> > The problem with the solution ist of course, that i have to definie the
> > same
> > Database configuration several times.
> >
> > Is there a way to reference the DataSource definition. Like: for
> jndi-name3
> > use the datasource defined under jndi-name1?
> >
> > Thanks in advance
> > Tom
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> > http://openejb.979440.n4.nabble.com/Reusing-Datasource-tp4659727.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
> >
>



-- 
Jean-Louis

Re: Reusing Datasource

Hi,

First i think we never release openejb 3.2

Then you can define the datasource globally either in conf/openejb.xml or
as properties of the container (initialcontext). Just match the expectes
name in persistence.xml
Le 17 déc. 2012 08:25, "tkayser"  a écrit :

> Hi,
>
> I am using Openejb 3.2 with an Embedded Configuration. I stumbled upon the
> following problem, for which I found a workaround but i still wonder if
> there is no better solution.
>
> For my code I use two different DataBases. Further i use different
> ejb.jar's
> which are not under my control. So I can't change the persistence.xml or
> anything. Understandable  the auto-linking can't guess the correct Data
> Source for the different ejb.jars to use. So my workaround ist to define
> for
> each JNDI-Name the ejb.jars definie in their persistence.xml the correct
> database:
>
>  = new:/Resource?type=Datasource
> 
>
>  = new:/Resource?type=Datasource
> 
>
>  = new:/Resource?type=Datasource
> 
>
> The problem with the solution ist of course, that i have to definie the
> same
> Database configuration several times.
>
> Is there a way to reference the DataSource definition. Like: for jndi-name3
> use the datasource defined under jndi-name1?
>
> Thanks in advance
> Tom
>
>
>
>
>
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Reusing-Datasource-tp4659727.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Re: Why are Tomcat's threads more costly than background threads?

Side note: if your need is pushing regularly to the client just having some
client polling can make it far easier to manage on both sides...
Le 17 déc. 2012 08:33, "Howard W. Smith, Jr."  a
écrit :

> Almost forgot...PrimeFaces peer/friend of mine informed me that JMS is good
> for running two instances of an app, similar to load balancer.
>
> Prior to using TomEE, I really wanted to use PrimeFaces Push (powered by
> Atmosphere/websocket), and at that time, I was thinking that I could
> possibly run Tomcat or TomEE just to push messages to the clients of my app
> running on Glassfish, since Glassfish had issues with PrimeFaces Push
> (Atmosphere). I think he said that tomEE and Glassfish could do that, but
> they would have to communicate via JMS or the two servlets would have to
> serve requests/responses, appropriately, via JMS.
>
> I am probably not stating the above correctly as he said, but that's how I
> understood what he told me.
>
> Now that I'm only using tomEE, there is no need to do such a thing. Loving
> TomEE!!!
>
>
>
> On Mon, Dec 17, 2012 at 2:26 AM, Howard W. Smith, Jr. <
> smithh032...@gmail.com> wrote:
>
> > Very interesting discussion and responses here! Anthony motivates me to
> > jump on the bandwagon of using JMS/message-driven-beans, and at the same
> > time, Romain tells me, not much need (for local) in a Java EE 6
> > application. :)
> >
> > Either way, i have not ruled out JMS. I have done some strategic coding
> on
> > my part to avoid @Schedule or use of timer service...using Date class to
> > postpone pushing data to google calendar, and only pushing when there is
> a
> > new date to update...application-wide. At first, i was pushing data to
> > google calendar after 'every' update request... sending over 1,000
> requests
> > to google calendar sometimes or daily (adding and deleting events on
> google
> > calendar to keep google calendar in sync with the database), but I cut
> that
> > back (or decreased the # of requests) with the new code I developed 2+
> > months ago. just makes for a faster user experience since they requested
> to
> > have data updated via ajax on change/selection of this field, and that
> > field.
> >
> > Right now, JMS would be similar to a nice science project for me... just
> > to see if I can do it and the success of it.
> >
> >
> > On Mon, Dec 17, 2012 at 1:57 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > > wrote:
> >
> >> I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it on the
> >> road qince javaee 6, no more.
> >>
> >> It works but i dont find it effective when it stays local
> >>
> >
> >
>

Re: Why are Tomcat's threads more costly than background threads?

Almost forgot...PrimeFaces peer/friend of mine informed me that JMS is good
for running two instances of an app, similar to load balancer.

Prior to using TomEE, I really wanted to use PrimeFaces Push (powered by
Atmosphere/websocket), and at that time, I was thinking that I could
possibly run Tomcat or TomEE just to push messages to the clients of my app
running on Glassfish, since Glassfish had issues with PrimeFaces Push
(Atmosphere). I think he said that tomEE and Glassfish could do that, but
they would have to communicate via JMS or the two servlets would have to
serve requests/responses, appropriately, via JMS.

I am probably not stating the above correctly as he said, but that's how I
understood what he told me.

Now that I'm only using tomEE, there is no need to do such a thing. Loving
TomEE!!!

On Mon, Dec 17, 2012 at 2:26 AM, Howard W. Smith, Jr. <
smithh032...@gmail.com> wrote:

> Very interesting discussion and responses here! Anthony motivates me to
> jump on the bandwagon of using JMS/message-driven-beans, and at the same
> time, Romain tells me, not much need (for local) in a Java EE 6
> application. :)
>
> Either way, i have not ruled out JMS. I have done some strategic coding on
> my part to avoid @Schedule or use of timer service...using Date class to
> postpone pushing data to google calendar, and only pushing when there is a
> new date to update...application-wide. At first, i was pushing data to
> google calendar after 'every' update request... sending over 1,000 requests
> to google calendar sometimes or daily (adding and deleting events on google
> calendar to keep google calendar in sync with the database), but I cut that
> back (or decreased the # of requests) with the new code I developed 2+
> months ago. just makes for a faster user experience since they requested to
> have data updated via ajax on change/selection of this field, and that
> field.
>
> Right now, JMS would be similar to a nice science project for me... just
> to see if I can do it and the success of it.
>
>
> On Mon, Dec 17, 2012 at 1:57 AM, Romain Manni-Bucau  > wrote:
>
>> I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it on the
>> road qince javaee 6, no more.
>>
>> It works but i dont find it effective when it stays local
>>
>
>

Re: Why are Tomcat's threads more costly than background threads?

Very interesting discussion and responses here! Anthony motivates me to
jump on the bandwagon of using JMS/message-driven-beans, and at the same
time, Romain tells me, not much need (for local) in a Java EE 6
application. :)

Either way, i have not ruled out JMS. I have done some strategic coding on
my part to avoid @Schedule or use of timer service...using Date class to
postpone pushing data to google calendar, and only pushing when there is a
new date to update...application-wide. At first, i was pushing data to
google calendar after 'every' update request... sending over 1,000 requests
to google calendar sometimes or daily (adding and deleting events on google
calendar to keep google calendar in sync with the database), but I cut that
back (or decreased the # of requests) with the new code I developed 2+
months ago. just makes for a faster user experience since they requested to
have data updated via ajax on change/selection of this field, and that
field.

Right now, JMS would be similar to a nice science project for me... just to
see if I can do it and the success of it.

On Mon, Dec 17, 2012 at 1:57 AM, Romain Manni-Bucau
wrote:

> I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it on the
> road qince javaee 6, no more.
>
> It works but i dont find it effective when it stays local
>

Reusing Datasource

2012-12-16 Thread tkayser

Hi,

I am using Openejb 3.2 with an Embedded Configuration. I stumbled upon the
following problem, for which I found a workaround but i still wonder if
there is no better solution.

For my code I use two different DataBases. Further i use different ejb.jar's
which are not under my control. So I can't change the persistence.xml or
anything. Understandable  the auto-linking can't guess the correct Data
Source for the different ejb.jars to use. So my workaround ist to define for
each JNDI-Name the ejb.jars definie in their persistence.xml the correct
database:

 = new:/Resource?type=Datasource


 = new:/Resource?type=Datasource


 = new:/Resource?type=Datasource


The problem with the solution ist of course, that i have to definie the same
Database configuration several times. 

Is there a way to reference the DataSource definition. Like: for jndi-name3
use the datasource defined under jndi-name1?

Thanks in advance
Tom








--
View this message in context: 
http://openejb.979440.n4.nabble.com/Reusing-Datasource-tp4659727.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: TomEE 1.5.1: bean encountered a non-application exception; nested exception???

okay, thanks Romain for the response. :)

On Mon, Dec 17, 2012 at 2:09 AM, Romain Manni-Bucau
wrote:

> Because that's not an app exception (see ejb spec and/or
> @ApplicationException)
> Le 17 déc. 2012 04:43, "Howard W. Smith, Jr."  a
> écrit :
>
> > First of all, I already fixed the cause of this exception in my app, I
> just
> > wanted to ask a question about the exception.
> >
> > The exception occurred when the following line of code was executed:
> >
> > ejbFacadeDetails.create(argOrder.getDetailsId());
> >
> >
> > argOrder.getDetailsId() returned/was 'null', because of the following
> code.
> >
> >
> > // these lines below occur at beginning of the method
> > OrderDetails orderDetails = new OrderDetails(1);
> > orderDetails.setDetailsTx("");
> > details.append(request.getMessage());
> >
> > // these lines below occur later on in the code
> > if (details.length() > 0) {
> > orderDetails.setDetailsTx(details.toString());
> > order.setDetailsId(orderDetails);
> > }
> >
> >
> > I fixed the above code already and the exception is no longer raised, but
> > my question is, why is this considered a 'non-application exception' and
> a
> > 'nested exception' as stated in the stacktrace below?
> >
> > javax.ejb.EJBException: The bean encountered a non-application exception;
> > nested exception is:
> > java.lang.IllegalArgumentException: Object: null is not a known entity
> > type.
> > at
> >
> >
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:363)
> > at
> >
> >
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:283)
> > at
> >
> >
> jpa.session.OrderDetailsFacade$LocalBeanProxy.create(jpa/session/OrderDetailsFacade.java)
> > at
> >
> >
> jsf.orders.pf_OrdersController.createFromAirportShuttleRequest(pf_OrdersController.java:14194)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> > at java.lang.reflect.Method.invoke(Unknown Source)
> > at
> >
> >
> org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
> > at
> >
> >
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
> > at
> >
> >
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
> > at
> >
> >
> jsf.orders.pf_OrdersController_$$_javassist_6.createFromAirportShuttleRequest(pf_OrdersController_$$_javassist_6.java)
> > at
> >
> >
> utils.mail.AddAirportShuttleRequest.createOrderForAirportShuttle(AddAirportShuttleRequest.java:322)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> > at java.lang.reflect.Method.invoke(Unknown Source)
> > at
> >
> >
> org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
> > at
> >
> >
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
> > at
> >
> >
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
> > at
> >
> >
> utils.mail.AddAirportShuttleRequest_$$_javassist_53.createOrderForAirportShuttle(AddAirportShuttleRequest_$$_javassist_53.java)
> > at
> >
> >
> utils.mail.EmailRequestBean.processAirportShuttleRequest(EmailRequestBean.java:212)
> > at
> >
> >
> utils.mail.EmailRequestBean.addAirportShuttleRequests(EmailRequestBean.java:152)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> > at java.lang.reflect.Method.invoke(Unknown Source)
> > at
> >
> >
> org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
> > at
> >
> >
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
> > at
> >
> >
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
> > at
> >
> >
> utils.mail.EmailRequestBean_$$_javassist_52.addAirportShuttleRequests(EmailRequestBean_$$_javassist_52.java)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> > at java.lang.reflect.Method.invoke(Unknown Source)
> > at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:737)
> > at javax.el.BeanELResolver.invoke(BeanELResolver.java:467)
> > at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:246)
> > at

Re: TomEE 1.5.1: bean encountered a non-application exception; nested exception???

Because that's not an app exception (see ejb spec and/or
@ApplicationException)
Le 17 déc. 2012 04:43, "Howard W. Smith, Jr."  a
écrit :

> First of all, I already fixed the cause of this exception in my app, I just
> wanted to ask a question about the exception.
>
> The exception occurred when the following line of code was executed:
>
> ejbFacadeDetails.create(argOrder.getDetailsId());
>
>
> argOrder.getDetailsId() returned/was 'null', because of the following code.
>
>
> // these lines below occur at beginning of the method
> OrderDetails orderDetails = new OrderDetails(1);
> orderDetails.setDetailsTx("");
> details.append(request.getMessage());
>
> // these lines below occur later on in the code
> if (details.length() > 0) {
> orderDetails.setDetailsTx(details.toString());
> order.setDetailsId(orderDetails);
> }
>
>
> I fixed the above code already and the exception is no longer raised, but
> my question is, why is this considered a 'non-application exception' and a
> 'nested exception' as stated in the stacktrace below?
>
> javax.ejb.EJBException: The bean encountered a non-application exception;
> nested exception is:
> java.lang.IllegalArgumentException: Object: null is not a known entity
> type.
> at
>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:363)
> at
>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:283)
> at
>
> jpa.session.OrderDetailsFacade$LocalBeanProxy.create(jpa/session/OrderDetailsFacade.java)
> at
>
> jsf.orders.pf_OrdersController.createFromAirportShuttleRequest(pf_OrdersController.java:14194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
>
> org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
> at
>
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
> at
>
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
> at
>
> jsf.orders.pf_OrdersController_$$_javassist_6.createFromAirportShuttleRequest(pf_OrdersController_$$_javassist_6.java)
> at
>
> utils.mail.AddAirportShuttleRequest.createOrderForAirportShuttle(AddAirportShuttleRequest.java:322)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
>
> org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
> at
>
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
> at
>
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
> at
>
> utils.mail.AddAirportShuttleRequest_$$_javassist_53.createOrderForAirportShuttle(AddAirportShuttleRequest_$$_javassist_53.java)
> at
>
> utils.mail.EmailRequestBean.processAirportShuttleRequest(EmailRequestBean.java:212)
> at
>
> utils.mail.EmailRequestBean.addAirportShuttleRequests(EmailRequestBean.java:152)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
>
> org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
> at
>
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
> at
>
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
> at
>
> utils.mail.EmailRequestBean_$$_javassist_52.addAirportShuttleRequests(EmailRequestBean_$$_javassist_52.java)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:737)
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:467)
> at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:246)
> at de.odysseus.el.tree.impl.ast.AstMethod.eval(AstMethod.java:91)
> at de.odysseus.el.tree.impl.ast.AstMethod.invoke(AstMethod.java:104)
> at de.odysseus.el.tree.impl.ast.AstEval.invoke(AstEval.java:71)
> at
> de.odysseus.el.TreeMethodExpression.invoke(TreeMethodExpression.java:132)
> at
>
> org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression.invoke(Conte

Re: Why are Tomcat's threads more costly than background threads?

I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it on the
road qince javaee 6, no more.

It works but i dont find it effective when it stays local

@others: am i alone?
Le 17 déc. 2012 06:53, "Anthony Fryer"  a écrit :

> Yes i've done this before a few times and had really good results using
> weblogic.  I must say i have an element of doubt about it with Romain not
> liking it though.  I've used ActiveMQ before and not encountered issues but
> these guys are the tomee devs and I'd go with what they say.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659718.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Re: TomEE can't find ehcache.xml

2012-12-16 Thread Jean-Louis MONTEIRO

Cool.
Le 16 déc. 2012 15:12, "Luca Merolla"  a écrit :

> Thanks I have solved by removing "new CacheManager" with:
>
> manager = CacheManager.newInstance(getClass().getResource(
> "/ehcache.xml"));
>
>
> On Sun, Dec 16, 2012 at 10:35 AM, Jean-Louis MONTEIRO  >wrote:
>
> > Hi,
> >
> > You should get the URL of the ehCache file first.
> > Otherwise, it should be a relative path to user.dir or so.
> >
> > Anyway, check out that page
> >
> >
> http://ehcache.org/documentation/code-samples#ways-of-loading-cache-configuration
> > It contains examples on how to proceed.
> >
> > And let us know if that still does not work.
> > BTW, in such a case a simple ready to run sample would be a must for us.
> >
> > Jean-Louis
> >
> >
> > 2012/12/16 Luca Merolla 
> >
> > > ybe the problem is due to the fact that ehcache.xml is in a jar stor
> >
> >
> >
> >
> > --
> > Jean-Louis
> >
>

Re: Why are Tomcat's threads more costly than background threads?

Yes i've done this before a few times and had really good results using
weblogic.  I must say i have an element of doubt about it with Romain not
liking it though.  I've used ActiveMQ before and not encountered issues but
these guys are the tomee devs and I'd go with what they say.



--
View this message in context: 
http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659718.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

Ok so what i'm hearing is that you're against the idea because you don't
trust the implementation of JMS included in tomee?



--
View this message in context: 
http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659713.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

well i don't like it because for asynchronouism you now have some
tools in JavaEE. then i agree the retry mecanism can be interesting
but
1) did you already look what does the container (AMQ here) when you
send/receive a message? i wouldn't try to get any perf with such a lot
of job
2) AMQ blocks easily and it is as easy to get twice the same message
or lost it so i wouldn't bet on it


don't take it bad, AMQ is fine in general but got so much issues that
i wouldnt use it when i stay in the same JVM

@Asynchronous should be interesting

that's said when a server is really used async is useless (work has to
be done :p)

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/17 Howard W. Smith, Jr. :
> Good points Anthony and thanks for sharing all that. Stephen, right now, I
> assume the same as what you stated. My experience with entirely  @stateless
> solution, IMHO, got me nowhere because @stateless seems to be application
> scope and the database got locked application scope/wide, so that is why I
> reverted to user session being responsible for the update. JMS seems a bit
> @stateless in its nature to me. I honestly believe that entirely @stateless
> can perform narrower scope transactions. Maybe one day I can achieve such a
> thing. :-)
>  On Dec 16, 2012 7:07 PM, "Anthony Fryer"  wrote:
>
>> Romain, you're opinion means alot so i'm wondering why you are against JMS
>> in
>> this case.  This kind of pattern happens alot in my experience.  In this
>> case a timer job executes that finds a list of jobs to execute, in this
>> case
>> read a list of emails and for each email insert a row into a database.
>>
>> In my experience, the timer job that executes wants to finish as quickly as
>> possible so you don't get overlapping timer executions and also to minimize
>> resource utilization.  Putting a jms message on a queue is generally alot
>> quicker than performing an actual database insert.  In addition JMS gives
>> you guaranteed message delivery, so you know that the message is going to
>> get processed and not get lost.  It is part of the JMS spec that i believe
>> is very applicable in this case.
>>
>> As for the transactional semantics that apply to the Message Driven Bean
>> that performs the actual work of inserting the record into the database,
>> again i think it works well in this case.  If the MDB is executing within a
>> container managed transaction, then only if the database insert succeeds
>> and
>> the transaction commits will the message be taken off the queue.  This
>> means
>> if the database insert fails, you haven't lost the message and can either
>> retry or configure the JMS to place the message on an error queue that can
>> be processed in a different way.
>>
>> How would you handle a database insert failure in the current solution?
>>
>> Also I don't think it matters if the MDB that performs the message
>> processing is local or not.  Its irrelevant really.  I wouldn't be using
>> the
>> JMS just for asynchronous calls.  I'd be using it for the guarenteed
>> message
>> delivery and processing, performance AND asynchronous processing.
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659710.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>

Re: Why are Tomcat's threads more costly than background threads?

Good points Anthony and thanks for sharing all that. Stephen, right now, I
assume the same as what you stated. My experience with entirely  @stateless
solution, IMHO, got me nowhere because @stateless seems to be application
scope and the database got locked application scope/wide, so that is why I
reverted to user session being responsible for the update. JMS seems a bit
@stateless in its nature to me. I honestly believe that entirely @stateless
can perform narrower scope transactions. Maybe one day I can achieve such a
thing. :-)
 On Dec 16, 2012 7:07 PM, "Anthony Fryer"  wrote:

> Romain, you're opinion means alot so i'm wondering why you are against JMS
> in
> this case.  This kind of pattern happens alot in my experience.  In this
> case a timer job executes that finds a list of jobs to execute, in this
> case
> read a list of emails and for each email insert a row into a database.
>
> In my experience, the timer job that executes wants to finish as quickly as
> possible so you don't get overlapping timer executions and also to minimize
> resource utilization.  Putting a jms message on a queue is generally alot
> quicker than performing an actual database insert.  In addition JMS gives
> you guaranteed message delivery, so you know that the message is going to
> get processed and not get lost.  It is part of the JMS spec that i believe
> is very applicable in this case.
>
> As for the transactional semantics that apply to the Message Driven Bean
> that performs the actual work of inserting the record into the database,
> again i think it works well in this case.  If the MDB is executing within a
> container managed transaction, then only if the database insert succeeds
> and
> the transaction commits will the message be taken off the queue.  This
> means
> if the database insert fails, you haven't lost the message and can either
> retry or configure the JMS to place the message on an error queue that can
> be processed in a different way.
>
> How would you handle a database insert failure in the current solution?
>
> Also I don't think it matters if the MDB that performs the message
> processing is local or not.  Its irrelevant really.  I wouldn't be using
> the
> JMS just for asynchronous calls.  I'd be using it for the guarenteed
> message
> delivery and processing, performance AND asynchronous processing.
>
>
>
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659710.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Re: Why are Tomcat's threads more costly than background threads?

Romain, you're opinion means alot so i'm wondering why you are against JMS in
this case. This kind of pattern happens alot in my experience. In this
case a timer job executes that finds a list of jobs to execute, in this case
read a list of emails and for each email insert a row into a database.

In my experience, the timer job that executes wants to finish as quickly as
possible so you don't get overlapping timer executions and also to minimize
resource utilization. Putting a jms message on a queue is generally alot
quicker than performing an actual database insert. In addition JMS gives
you guaranteed message delivery, so you know that the message is going to
get processed and not get lost. It is part of the JMS spec that i believe
is very applicable in this case.

As for the transactional semantics that apply to the Message Driven Bean
that performs the actual work of inserting the record into the database,
again i think it works well in this case. If the MDB is executing within a
container managed transaction, then only if the database insert succeeds and
the transaction commits will the message be taken off the queue. This means
if the database insert fails, you haven't lost the message and can either
retry or configure the JMS to place the message on an error queue that can
be processed in a different way.

How would you handle a database insert failure in the current solution?

Also I don't think it matters if the MDB that performs the message
processing is local or not. Its irrelevant really. I wouldn't be using the
JMS just for asynchronous calls. I'd be using it for the guarenteed message
delivery and processing, performance AND asynchronous processing.

--
View this message in context:
http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659710.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

2012-12-16 Thread Stephen Connolly

Need to take care around transaction symmantics with JMS too.

On Sunday, 16 December 2012, Anthony Fryer wrote:

> Another change you could make to improve the performance of the method
> invoked by the timer, is instead of performing the actual database insert
> for each email in that method, instead write a message to a JMS queue.
>  Then
> create a message driven bean that processes the JMS messages and performs
> the actual database insert.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659697.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Re: Why are Tomcat's threads more costly than background threads?

I have never used JMS/message-driven-beans as of yet, but considering it...

On Sun, Dec 16, 2012 at 8:35 AM, Romain Manni-Bucau
wrote:

> i'm quite again using JMS for local asynchronism generally
>
> not the goal of JMS IMO
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2012/12/16 Anthony Fryer :
> > Another change you could make to improve the performance of the method
> > invoked by the timer, is instead of performing the actual database insert
> > for each email in that method, instead write a message to a JMS queue.
>  Then
> > create a message driven bean that processes the JMS messages and performs
> > the actual database insert.
> >
> >
> >
> > --
> > View this message in context:
> http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659697.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Re: Why are Tomcat's threads more costly than background threads?

Anthony, thanks for the recommendation. I will have to give that a try.
On Dec 16, 2012 8:33 AM, "Anthony Fryer"  wrote:

> Another change you could make to improve the performance of the method
> invoked by the timer, is instead of performing the actual database insert
> for each email in that method, instead write a message to a JMS queue.
>  Then
> create a message driven bean that processes the JMS messages and performs
> the actual database insert.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659697.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Re: Conflicts with TomEEClassLoaderEnricher

2012-12-16 Thread Marco de Booij


I will give it a try. I will keep you informed.

Op 16-12-12 14:42, Romain Manni-Bucau schreef:

depend on your config but basically for each version just update
tomee/lib (and optionally webapps/tomee if you need it)

seems fine using tomee instead of tmocat as base, can you give it a try?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/16 Marco de Booij :

I used TomEE for development. But everytime there was a new version of TomEE
I had to unpack the new TomEE package and redo the configuration. Perhaps my
wrong but I could not find another way. My idea is that if I deploy TomEE as
a war then I can keep my configuration and also my Tomcat7 would be kept up
to date through Debian.

Op 16-12-12 13:41, Romain Manni-Bucau schreef:

Why not using a TomEE instead of a Tomcat 7 as base?

will try to deploy a sonar in a tomee in the afternoon

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/16 Marco de Booy :

Sorry. I forgot that. Yes I deploy TomEE in Tomcat. My (personal) server
has
not enough resources to run 3 J2ee (tomEE, Sonar, and Nexus) at the same

time. Since they are all lightly used they should be able to run in a
512Mb
Tomcat.

Regards,

Marco


On Sat, 15 Dec 2012 18:56:13 +0100, Romain Manni-Bucau wrote:

Hi,

you deploy tomee in tomcat?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/15 Marco de Booij :

Hello,

*Tomcat* 7.0.26
*Tomee*  1.5.0
*Sonar*3.2
*Debian*  6.0.6

Re: TomEE can't find ehcache.xml

2012-12-16 Thread Luca Merolla

Thanks I have solved by removing "new CacheManager" with:

manager = CacheManager.newInstance(getClass().getResource(
"/ehcache.xml"));


On Sun, Dec 16, 2012 at 10:35 AM, Jean-Louis MONTEIRO wrote:

> Hi,
>
> You should get the URL of the ehCache file first.
> Otherwise, it should be a relative path to user.dir or so.
>
> Anyway, check out that page
>
> http://ehcache.org/documentation/code-samples#ways-of-loading-cache-configuration
> It contains examples on how to proceed.
>
> And let us know if that still does not work.
> BTW, in such a case a simple ready to run sample would be a must for us.
>
> Jean-Louis
>
>
> 2012/12/16 Luca Merolla 
>
> > ybe the problem is due to the fact that ehcache.xml is in a jar stor
>
>
>
>
> --
> Jean-Louis
>

Re: Conflicts with TomEEClassLoaderEnricher

depend on your config but basically for each version just update
tomee/lib (and optionally webapps/tomee if you need it)

seems fine using tomee instead of tmocat as base, can you give it a try?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/16 Marco de Booij :
> I used TomEE for development. But everytime there was a new version of TomEE
> I had to unpack the new TomEE package and redo the configuration. Perhaps my
> wrong but I could not find another way. My idea is that if I deploy TomEE as
> a war then I can keep my configuration and also my Tomcat7 would be kept up
> to date through Debian.
>
> Op 16-12-12 13:41, Romain Manni-Bucau schreef:
>>
>> Why not using a TomEE instead of a Tomcat 7 as base?
>>
>> will try to deploy a sonar in a tomee in the afternoon
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2012/12/16 Marco de Booy :
>>>
>>> Sorry. I forgot that. Yes I deploy TomEE in Tomcat. My (personal) server
>>> has
>>> not enough resources to run 3 J2ee (tomEE, Sonar, and Nexus) at the same
>>>
>>> time. Since they are all lightly used they should be able to run in a
>>> 512Mb
>>> Tomcat.
>>>
>>> Regards,
>>>
>>> Marco
>>>
>>>
>>> On Sat, 15 Dec 2012 18:56:13 +0100, Romain Manni-Bucau wrote:

 Hi,

 you deploy tomee in tomcat?

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/15 Marco de Booij :
>
> Hello,
>
> *Tomcat* 7.0.26
> *Tomee*  1.5.0
> *Sonar*3.2
> *Debian*  6.0.6
>
>
>

Re: Why are Tomcat's threads more costly than background threads?

i'm quite again using JMS for local asynchronism generally

not the goal of JMS IMO

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/16 Anthony Fryer :
> Another change you could make to improve the performance of the method
> invoked by the timer, is instead of performing the actual database insert
> for each email in that method, instead write a message to a JMS queue.  Then
> create a message driven bean that processes the JMS messages and performs
> the actual database insert.
>
>
>
> --
> View this message in context: 
> http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659697.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

Another change you could make to improve the performance of the method
invoked by the timer, is instead of performing the actual database insert
for each email in that method, instead write a message to a JMS queue.  Then
create a message driven bean that processes the JMS messages and performs
the actual database insert.



--
View this message in context: 
http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659697.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Conflicts with TomEEClassLoaderEnricher

2012-12-16 Thread Marco de Booij

I used TomEE for development. But everytime there was a new version of 
TomEE I had to unpack the new TomEE package and redo the configuration. 
Perhaps my wrong but I could not find another way. My idea is that if I 
deploy TomEE as a war then I can keep my configuration and also my 
Tomcat7 would be kept up to date through Debian.


Op 16-12-12 13:41, Romain Manni-Bucau schreef:

Why not using a TomEE instead of a Tomcat 7 as base?

will try to deploy a sonar in a tomee in the afternoon

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/16 Marco de Booy :

Sorry. I forgot that. Yes I deploy TomEE in Tomcat. My (personal) server has
not enough resources to run 3 J2ee (tomEE, Sonar, and Nexus) at the same
time. Since they are all lightly used they should be able to run in a 512Mb
Tomcat.

Regards,

Marco


On Sat, 15 Dec 2012 18:56:13 +0100, Romain Manni-Bucau wrote:

Hi,

you deploy tomee in tomcat?

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/15 Marco de Booij :

Hello,

*Tomcat* 7.0.26
*Tomee*  1.5.0
*Sonar*3.2
*Debian*  6.0.6

Re: Conflicts with TomEEClassLoaderEnricher