Not sure if i still didnt get it but sounds like you either want too much client jars (== loosing users) or reinventing maven. Isnt it? Le 9 déc. 2012 16:38, "Alex The Rocker" <alex.m3...@gmail.com> a écrit :
> You're though with me, but I won't give up without trying harder :) > > Here's what I have in mind : providing a "Java EE client JARs provisioning" > REST service for : > 1. client apps which talk to the app server using JMS > 2. client apps which talk to the app server using EJB > 3. client apps which talk to the app server using JPA datatypes > To avoid a service that would also such client apps to download all jar > files if they need a feature subset, then one could steal some ideas to > Eclipse plug-ins download. > In Eclipse, you can select a few plug-ins, and ask to also get their > dependencies and even better, you can make your fine-grained selection of > what you'll actually download. > > Ideally, all Java EE app servers should provide such "client Java EE jars" > provisionning service :for example, WebSphere Application Server could > also downloading WebSphere MQ client Jars; etc. > > That's why in my initial post I was asking whether or not there's a Java EE > standard for this need, either in existing Java EE specs or in next or > future ones. > If not, then would it make sense for TomEE to provide it, as a working > "reference implementation" of a future enhancement of Java EE specs ? > > Does it sounds better now? > > thanks, > Alex > > > On Sun, Dec 9, 2012 at 8:34 AM, Romain Manni-Bucau <rmannibu...@gmail.com > >wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > >
