Re: Suggestion: tick client JARs provisionning service
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" 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 >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" 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" 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" 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
>
Re: Suggestion: tick client JARs provisionning service
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 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" 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" 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" 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 > >
Re: Suggestion: tick client JARs provisionning service
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" 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 >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" 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" 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. > > > > > > >
Re: Suggestion: tick client JARs provisionning service
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 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" 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" 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" > 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" 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: > > > > > > > > > > > > >
Re: Suggestion: tick client JARs provisionning service
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" 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 >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" 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" 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" 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 > > > > > > independ
Re: Suggestion: tick client JARs provisionning service
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 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" 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 > >wrote: > > > > > +1 > > > Don't really understand the question. Could you elaborate a bit more? > > > Le 8 déc. 2012 18:11, "Romain Manni-Bucau" 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" 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 > > > > > > > > > > > > > > >
Re: Suggestion: tick client JARs provisionning service
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" 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 >wrote: > > > +1 > > Don't really understand the question. Could you elaborate a bit more? > > Le 8 déc. 2012 18:11, "Romain Manni-Bucau" 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" 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 > > > > > > > > > >
Re: Suggestion: tick client JARs provisionning service
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 wrote: > +1 > Don't really understand the question. Could you elaborate a bit more? > Le 8 déc. 2012 18:11, "Romain Manni-Bucau" 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" 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 > > > > > >
Re: Suggestion: tick client JARs provisionning service
+1 Don't really understand the question. Could you elaborate a bit more? Le 8 déc. 2012 18:11, "Romain Manni-Bucau" 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" 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 > > >
Re: Suggestion: tick client JARs provisionning service
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" 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 >
Suggestion: tick client JARs provisionning service
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
