Can Jetty 6 continuations be used in a glassfish container? Can this be properly acheived to suspend requests as to not tie up the threadpool? Switching to a Jetty container is not an option. Using grizzly is also not an option (I need the comet support to work with activemq which uses continuations). I am stuck with glassfish v2.
So in other words, I'd like to use the jetty 6 continuation feature with all of its benefits within a different container. Is this possible?
The answer is yes.
ContinuationFilter
Related
I have set up Tomcat cluster, behiind Apache Httpd server, with 2 nodes. I read the Tomcat documentation at Tomcat cluster how to and the first requirement is:"All your session attributes must implement java.io.Serializable". I've done and session replication, failover mechanism seems to work. Now I'm using a framework for Web app develop and it seems that the object classes that are stored in the session don't implement Serializable. I'm looking for a workaround to solve this problem in the simplier manner. I've read a lot of questions/answer but not solution so far. Any idea? Tomcat version 7.0.76. Thank you.
I want to use scheduling in jboss7 (and in wildfly) but I don't want to use any EJB. I know the EJB #Schedule can be used but I have a web application and the same WAR should be used in Tomcat too so EJB is out of the question.
What can I use for scheduling?
Thanks,
V.
Is there any additional configuration that needs to be done in order to enable CDI JTA Transactions using #Transactional annotation under CDI beans with Weblogic 12.1.3 server?
I have tried to just add the annotation into a service method, but EntityManager didn't recognize to be running under a transaction.
Is there any interceptor or something else that needs to be registered?
#JoshAment is right.
WebLogic 12.1.3 only partially supports Java EE 7 (it supports its four pieces: JPA 2.1, JAX-RS 2.0, JSON-P 1.0, WebSockets 1.0). But #Transactional is a part of JTA 1.2.
Right now only Liberty Profile is fully certified against Java EE 7.
The planned year-end WebLogic 12.1.4 is going to support it also.
Anyway, answering your question: just configured persistence.xml should be enough to use the #javax.transaction.Transactional annotation in your code.
// You may also consider to move away from Java EE 7 ;) then you would be able to freely choose whatever lib you want. I strongly believe that server itself should not provide anything except servlets.
I'm working on a project where I have several war files inside a tomcat 7 have to communicate with a single embedded activeMQ (5.5.1) broker inside the same Tomcat.
I'm wondering what was the best practice to manage this and how to start and stop the broker properly.
Actually I try tu use a global JNDI entry in server.xml and in each war gets my activemq connection with a lookup. The first connection to the broker implicitly starts it. But with this method I run into various problems like instance already existing or locks in data store.
Should I use instead an additional war which uses a BrokerFactory to start the broker explicitly? In this case how to make sure that this war executes first in Tomcat ? And how do I stop my broker and where?
Thanks for the help.
from the docs...
If you are using the VM transport and wish to explicitly configure an
Embedded Broker there is a chance that you could create the JMS
connections first before the broker starts up. Currently ActiveMQ will
auto-create a broker if you use the VM transport and there is not one
already configured. (In 5.2 it is possible to use the waitForStart and
create=false options for the connection uri)
So to work around this if you are using Spring you may wish to use the
depends-on attribute so that your JMS ConnectionFactory depends on the
embedded broker to avoid this happening. e.g.
see these pages for more information...
http://activemq.apache.org/vm-transport-reference.html
http://activemq.apache.org/how-do-i-embed-a-broker-inside-a-connection.html
http://activemq.apache.org/how-do-i-restart-embedded-broker.html
I am using OSGI with Glassfish 3.0.1.We use Jersey REST as the resource layer. We have lots of osgi services. we are planning to decouple them & deploy it in a cloud. One way we do this is by doing a http REST call. But we would like to do service to service call at the api level. One way to do this is by using DOSGI. But Glassfish 3.0.1 doesn't seem to support DOSGI. Any other suggestions?
I believe that Glassfish contains Apache Felix, which is a fully compliant OSGi Framework. Therefore you do not need explicit support from Glassfish in order to use a set of bundles that provide Remote Services (the name "DOSGI" is now deprecated). Indeed, this is kind of the point of OSGi!
Anyway the next obvious question is which Remote Services implementation to choose. I would advise you NOT to use CXF since it is too buggy and unmaintained. That leaves Eclipse ECF or Paremus RSA.
(Disclaimer: the Paremus implementation is commercial and I work for Paremus).