Hmm, but the point is it depends so much on the needs that it will end up with the tull server to manage all cases, no? Le 9 déc. 2012 00:28, "Alex The Rocker" <alex.m3...@gmail.com> a écrit :
> Hello, > > Suppose you want to write a Java client application for your web app that > relies on JNDI, JMS and send & receives EJBs to and from the application > server. > Then, in your client application (which is not a web app, but rather a Java > program with a class having a main() entry point method), you'll need to > have in our classpath: > - ActiveMQ JARs for using JMS in a way compatible with TomEE's ActiveMQ > - TomEE actually uses web service protocols to make remote calls to EJB > Session Beans. There still needs to be a client library that knows how to > encode an EJB call into XML and extract the returned result as a Java > Object. > - the same idea would also apply to Java Programming Objects > > See jbossall-client.jar for something equivalent provided by JBoss : > > http://docs.jboss.org/jbossas/docs/Installation_And_Getting_Started_Guide/5/html/ch01.html#d0e525 > > Now, better than JBoss client libraries, we'd like to have a REST service > on the app server allowing our "client application" to download the app > server's client libraries specific to its JMS, EBJ, etc. implementation > into some directory that would be added to the client application's > CLASSPATH at runtime. > > Is it clearer ? > > Alex > > > On Sat, Dec 8, 2012 at 6:22 PM, Jean-Louis MONTEIRO <jeano...@gmail.com > >wrote: > > > +1 > > Don't really understand the question. Could you elaborate a bit more? > > Le 8 déc. 2012 18:11, "Romain Manni-Bucau" <rmannibu...@gmail.com> a > > écrit : > > > > > Not sure i got you. These jars are not always mandatory and depends on > > your > > > needs. > > > Le 8 déc. 2012 17:56, "Alex The Rocker" <alex.m3...@gmail.com> a > écrit : > > > > > > > Hello, > > > > > > > > A developer in our company asked me if there's any "clean way to > > download > > > > "tick client" TomEE-specific JAR files. > > > > > > > > For example, for (not so recent) TomEE 1.5.1 snapshot, his > application > > > > needs to use the following JAR files at runtime: > > > > > > > > activemq-core-5.6.0.jar > > > > javaee-api-6.0-4-tomcat.jar > > > > openejb-client-4.5.1-SNAPSHOT.jar > > > > openjpa-2.2.0.jar > > > > slf4j-api-1.6.6.jar > > > > > > > > Given that: > > > > a/ I have advised him not to include these JARs in his application, > > > > because his application must be compatible with newer TomEE releases, > > > thus > > > > the question about a "provisioning service" for downloading those > Java > > EE > > > > client-enabling JARs. > > > > b/ His application doesn't need these JARs at build-time : he only > > uses > > > > generic (ie, non vendor specific) APIs like JNDI or JMS > > > > c/ The last JAR file quoted above (slf4j-api.jar) is interesting > > because > > > > it's not directly a Java EE client implementation, but a dependency > of > > > some > > > > of the other JARs > > > > > > > > Question: > > > > 1. Is there a generic way to fulfill this requirement in a vendor > > > > independent way? if not, anything planned in Java EE 7 ? > > > > 2. Would it make sense to have such feature in TomEE to keeping Java > EE > > > > tick clients up to date? If yes, then may I fill a JIRA for it? > > > > > > > > Thanks, > > > > Alex > > > > > > > > > >
