Add openejb-provisionning libraries (a zip is available) then you have a
Resolver class you can use with mvn info (resolve("org:foo:1")
Le 9 déc. 2012 23:10, "Alex The Rocker" <alex.m3...@gmail.com> a écrit :> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
