from security perspective, the provisioning service need to be in a webapp which can be configured to listen on another port than the one used for Internet access to application web apps on TomEE. It would also suck from security side if I had meant to include authentication in the provisioning, but I didn't mention it. For a proof a concept, I would need a way to find dependencies of Jars, I know how to do it with something like a Java bytecode reader, but it sounds like an overkill. Eclipse uses OSGi XML descriptors for dependencies, do we have something similar in TomEE binary distributions?
Alex On Sun, Dec 9, 2012 at 5:05 PM, Romain Manni-Bucau <rmannibu...@gmail.com>wrote: > Can you prototype it? With your description it sounds too risky for prod > envrt but id like to be sure. > Le 9 déc. 2012 16:55, "Alex The Rocker" <alex.m3...@gmail.com> a écrit : > > > 1/ no, I don't want too much clients jars in my application : quite the > > opposite : I only want javaee-api.jar in my application, and the rest > (the > > implementation jars compatible with the app server chosen by my > customers) > > would be dynamically downloaded to this client (with a smart > "auto-update" > > mechanism to avoid downloading at each start-up if there's no new > version). > > > > 2/ no it's not maven related, because I'm looking for a run-time / > > production feature. Maven is good for development activities. Likewise > I'm > > not looking for Opscode's Chef. I want the app server to deliver its own > > implementation jars to client apps, taking these jars from its own lib/ > > directories > > > > Maybe I'm asking too much, I don't realize.. > > > > Alex > > > > > > On Sun, Dec 9, 2012 at 4:41 PM, Romain Manni-Bucau < > rmannibu...@gmail.com > > >wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
