Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-07-09 13:57:03
|
First of all, great to see the interest from the Geronimo side, and = particularly your efforts on this, James! Regarding deployment units, I see 2 use cases: - a deployment unit that exposes remote beans, for example via RMI - a deployment unit that exposes a local bunch of components, to be = accessed from multiple WARs in the same server A single standard WAR that uses Spring within doesn't need special = treatment: From my point of view, that should still be deployed as WAR, = as there is no real benefit in deploying it as a special unit. So = basically, I envisage something similar to an EJB JAR, rather than a WAR = replacement. An EAR-like deployment unit that contains both standard WARs and Spring = JARs is a different matter, I guess: There's no strong need for it, as = WARs and Spring JARs can easily be deployed separately to the same = server, at least for a start. Let's concentrate on an EJB-JAR-style = deployment unit first! Questions are: How are remote beans able to interoperate with the = server's central RMI infrastructure, and how are local components able = to expose themselves in some subtree of the server's central JNDI = registry? Very similar to the needs of an EJB container, actually :-) Regarding the name: EJB JARs don't have a special name, as far as I = know, but "Spring JAR" sounds a bit too generic. SPAR is nice, although = it's the name of a food chain ;-) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Dmitriy Kopylenko Sent: Friday, July 09, 2004 2:10 PM To: spr...@li... Subject: Re: [Springframework-developer] Spring/Geronimo So Rod, James, as I'm trying to understand, what would be the purpose (use case) of=20 creating such a "deployment unit"? To be able to expose=20 application-level beans via JMX or expose Spring components itself such=20 as BeanFactory via JMX? And also, what is the "lower-level" transaction management in Geronimo?=20 Is it JTS? Thanks, Dmitriy. Rod Johnson wrote: >All > >I recently met up with James Strachan, to discuss Spring/Geronimo >integration, among other things. Btw James has recently joined us as a >Spring developer--he's a great addition to our team! > >Spring/Geronimo integration is an exciting prospect, and we should >prioritize anything we need to do towards it. > >The Geronimo team plan to give Spring a deployment unit, supported in >Geronimo like an EJB Jar file etc. James has been working on >this. This involves (a) Spring having a deployment unit that Geronimo >recognizes and gives its own class loader; (b) Geronimo trying to = expose >Spring beans via JMX. > >So we need to define a Spring deployment unit. This should presumably = be a >JAR that contains: >- application classes >- one or more XML files >- manifest giving location and order of XML files >- manifest classpath expressing dependencies as normal >- ? some mechanism for indicating dependencies, such as DataSources. It >would be good to be able to fail fast, rather than when the app tries = to >start up. > >James is happy to implement support in Geronimo for any definition = format we >choose. Let's start thinking! We can no doubt leverage such a = deployment >unit outside Geronimo also... > >Geronimo will ship the Spring binaries itself. And it uses CGLIB = heavily and >(I assume) Commons Logging/Log4j. So it would be nice to be able to = drop in >a Spring deployment unit and just have it start up. > >There may also be integration possibilities with transaction >management--getting access to lower-level details of transaction = management >than is available via JTA. I've opened a discussion on this with Jeremy >Boynes. > >Rgds >Rod > > > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20 >digital self defense, top technical experts, no vendor pitches,=20 >unmatched networking opportunities. Visit www.blackhat.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > =20 > ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20 digital self defense, top technical experts, no vendor pitches,=20 unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-07-09 14:35:30
|
>> Regarding the name: EJB JARs don't have a special name, >They're called EARs. If I'm not totally confused, an EAR contains multiple WARs and EJB JARs, = with each EJB JAR in turn defining multiple EJBs. I was referring to the = latter, not to the big elephant deployment unit ;-) Juergen |
|
From: <jas...@ma...> - 2004-07-09 14:51:11
|
On 9 Jul 2004, at 15:36, j=FCrgen h=F6ller [werk3AT] wrote: >>> Regarding the name: EJB JARs don't have a special name, > >> They're called EARs. > > If I'm not totally confused, an EAR contains multiple WARs and EJB=20 > JARs, with each EJB JAR in turn defining multiple EJBs. I was=20 > referring to the latter, not to the big elephant deployment unit ;-) Ah OK :) James ------- http://radio.weblogs.com/0112098/ |
|
From: <tho...@tr...> - 2004-07-09 15:08:55
|
Quoting "jürgen höller [werk3AT]" <jue...@we...>: > >> Regarding the name: EJB JARs don't have a special name, > > >They're called EARs. > > If I'm not totally confused, an EAR contains multiple WARs and EJB JARs, with > each EJB JAR in turn defining multiple EJBs. I was referring to the latter, > not to the big elephant deployment unit ;-) > So that's what the E stands for. Then we should name it CAR - Chicken ARchive :-) Or, How about BAR for Bean ARchive, PAR for POJO ARchive or LAR for Lightwheight ARchive. Possibilities are endless. Speaking of archives - is it necessary to deploy in an archive format or does Geronimo support exploded directories? Thomas > Juergen > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <jas...@ma...> - 2004-07-09 15:22:51
|
On 9 Jul 2004, at 16:08, tho...@tr... wrote: > Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>: > >>>> Regarding the name: EJB JARs don't have a special name, >> >>> They're called EARs. >> >> If I'm not totally confused, an EAR contains multiple WARs and EJB=20 >> JARs, with >> each EJB JAR in turn defining multiple EJBs. I was referring to the=20= >> latter, >> not to the big elephant deployment unit ;-) >> > > So that's what the E stands for. Then we should name it CAR - Chicken=20= > ARchive > :-) > > Or, How about BAR for Bean ARchive, PAR for POJO ARchive or LAR for=20 > Lightwheight > ARchive. Possibilities are endless. :) I've a fondness for the bar :) > Speaking of archives - is it necessary to deploy in an archive format=20= > or does > Geronimo support exploded directories? It will support exploded directories too (haven't checked if it does=20 already yet :). Whether its a file or a directory doesn't matter that=20 much in the grand scheme of things; its the layout that we need to=20 standardise on. James ------- http://radio.weblogs.com/0112098/ |
|
From: Guillaume P. <gpo...@gl...> - 2004-07-09 15:43:50
|
tho...@tr... wrote: >So that's what the E stands for. Then we should name it CAR - Chicken ARchive >:-) > The E in EAR stands for the same thing than the E in EJB, for Enterprise. Guillaume |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-09 17:20:46
|
> The E in EAR stands for the same thing than the E in EJB, for Enterprise. Ahhh, that what it stands for!.I thought it was Elephant ;-) |
|
From: Guillaume P. <gpo...@gl...> - 2004-07-09 17:52:48
|
Dmitriy Kopylenko wrote: > > The E in EAR stands for the same thing than the E in EJB, for > Enterprise. > > Ahhh, that what it stands for!.I thought it was Elephant ;-) Err, I thought the original post was a question, rather than I joke. I should have read more carefully heh. |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-09 15:28:29
|
How about SBAR - Spring Bean ARchive?... ;-) tho...@tr... wrote: >Quoting "jürgen höller [werk3AT]" <jue...@we...>: > > > >>>>Regarding the name: EJB JARs don't have a special name, >>>> >>>> >>>They're called EARs. >>> >>> >>If I'm not totally confused, an EAR contains multiple WARs and EJB JARs, with >>each EJB JAR in turn defining multiple EJBs. I was referring to the latter, >>not to the big elephant deployment unit ;-) >> >> >> > >So that's what the E stands for. Then we should name it CAR - Chicken ARchive >:-) > >Or, How about BAR for Bean ARchive, PAR for POJO ARchive or LAR for Lightwheight >ARchive. Possibilities are endless. > >Speaking of archives - is it necessary to deploy in an archive format or does >Geronimo support exploded directories? > >Thomas > > > >>Juergen >> >> >>------------------------------------------------------- >>This SF.Net email sponsored by Black Hat Briefings & Training. >>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >>digital self defense, top technical experts, no vendor pitches, >>unmatched networking opportunities. Visit www.blackhat.com >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> > > > > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >digital self defense, top technical experts, no vendor pitches, >unmatched networking opportunities. Visit www.blackhat.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-09 17:59:19
|
;-) Guillaume Poirier wrote: > Dmitriy Kopylenko wrote: > >> > The E in EAR stands for the same thing than the E in EJB, for >> Enterprise. >> >> Ahhh, that what it stands for!.I thought it was Elephant ;-) > > > Err, I thought the original post was a question, rather than I joke. > I should have read more carefully heh. > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital > self defense, top technical experts, no vendor pitches, unmatched > networking opportunities. Visit www.blackhat.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jas...@ma...> - 2004-07-09 14:15:09
|
On 9 Jul 2004, at 14:58, j=FCrgen h=F6ller [werk3AT] wrote: > First of all, great to see the interest from the Geronimo side, and=20 > particularly your efforts on this, James! > > Regarding deployment units, I see 2 use cases: > - a deployment unit that exposes remote beans, for example via RMI Or maybe an alternative to MDBs or web services too. > - a deployment unit that exposes a local bunch of components, to be=20 > accessed from multiple WARs in the same server Agreed - or things which become available for reuse by other=20 deployments via JNDI etc. > A single standard WAR that uses Spring within doesn't need special=20 > treatment: =46rom my point of view, that should still be deployed as=20= > WAR, as there is no real benefit in deploying it as a special unit. So=20= > basically, I envisage something similar to an EJB JAR, rather than a=20= > WAR replacement. Agreed - however it'd be nice to maybe expose Spring created POJOs to=20 the Geronimo management stack if a standard WAR were used. Maybe=20 Geronimo & Spring could detect each other somehow (e.g. Geronimo could=20= look for a magic Spring file) and so expose the Spring stuff to=20 Geronimo's management stack. I guess the other option is to allow folks=20= to use Spring-JMX inside the WAR. > An EAR-like deployment unit that contains both standard WARs and=20 > Spring JARs is a different matter, I guess: There's no strong need for=20= > it, as WARs and Spring JARs can easily be deployed separately to the=20= > same server, at least for a start. Let's concentrate on an=20 > EJB-JAR-style deployment unit first! > > Questions are: How are remote beans able to interoperate with the=20 > server's central RMI infrastructure, and how are local components able=20= > to expose themselves in some subtree of the server's central JNDI=20 > registry? Very similar to the needs of an EJB container, actually :-) We need to figure out what the various connectors are (JNDI, JCA, JMS,=20= RMI, WS etc) and then hopefully the geronimo-spring deployer would take=20= care of wiring things up; though we need to figure out how to expose=20 this stuff neatly. > Regarding the name: EJB JARs don't have a special name, They're called EARs. > as far as I know, but "Spring JAR" sounds a bit too generic. SPAR is=20= > nice, although it's the name of a food chain ;-) :) I'm easy really, call 'em anything you like. James ------- http://radio.weblogs.com/0112098/ |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-09 14:54:25
|
> - a deployment unit that exposes a local bunch of components, to be accessed from multiple WARs in the same server That sounds interesting. So let's say I have a /Shared Kernel /[Eric Evans - Domain Driven Design] domain model that needs to be accessed from multiple web apps deployed on the same container. Package those classes into a SPAR (or what ever that name is), drop it into the container and viola - those beans are available for different WARs deployed in the same container. Is my thinking off? Dmitriy. |
|
From: Rod J. <rod...@in...> - 2004-07-09 14:59:47
|
I haven't had time to read this thread in detail (will later tonight), bu= t I think we should allow for non-XML Spring configs. Now we have sep BeanDefinitionReaders, some beans could be sourced via JDBC, Groovy, properties, or other cool definition formats as yet unknown... ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Friday, July 09, 2004 2:58 PM Subject: Re: [Springframework-developer] Spring/Geronimo First of all, great to see the interest from the Geronimo side, and particularly your efforts on this, James! Regarding deployment units, I see 2 use cases: - a deployment unit that exposes remote beans, for example via RMI - a deployment unit that exposes a local bunch of components, to be acces= sed from multiple WARs in the same server A single standard WAR that uses Spring within doesn't need special treatment: From my point of view, that should still be deployed as WAR, a= s there is no real benefit in deploying it as a special unit. So basically,= I envisage something similar to an EJB JAR, rather than a WAR replacement. An EAR-like deployment unit that contains both standard WARs and Spring J= ARs is a different matter, I guess: There's no strong need for it, as WARs an= d Spring JARs can easily be deployed separately to the same server, at leas= t for a start. Let's concentrate on an EJB-JAR-style deployment unit first! Questions are: How are remote beans able to interoperate with the server'= s central RMI infrastructure, and how are local components able to expose themselves in some subtree of the server's central JNDI registry? Very similar to the needs of an EJB container, actually :-) Regarding the name: EJB JARs don't have a special name, as far as I know, but "Spring JAR" sounds a bit too generic. SPAR is nice, although it's th= e name of a food chain ;-) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Dmitriy Kopylenko Sent: Friday, July 09, 2004 2:10 PM To: spr...@li... Subject: Re: [Springframework-developer] Spring/Geronimo So Rod, James, as I'm trying to understand, what would be the purpose (use case) of creating such a "deployment unit"? To be able to expose application-level beans via JMX or expose Spring components itself such as BeanFactory via JMX? And also, what is the "lower-level" transaction management in Geronimo? Is it JTS? Thanks, Dmitriy. Rod Johnson wrote: >All > >I recently met up with James Strachan, to discuss Spring/Geronimo >integration, among other things. Btw James has recently joined us as a >Spring developer--he's a great addition to our team! > >Spring/Geronimo integration is an exciting prospect, and we should >prioritize anything we need to do towards it. > >The Geronimo team plan to give Spring a deployment unit, supported in >Geronimo like an EJB Jar file etc. James has been working on >this. This involves (a) Spring having a deployment unit that Geronimo >recognizes and gives its own class loader; (b) Geronimo trying to expose >Spring beans via JMX. > >So we need to define a Spring deployment unit. This should presumably be= a >JAR that contains: >- application classes >- one or more XML files >- manifest giving location and order of XML files >- manifest classpath expressing dependencies as normal >- ? some mechanism for indicating dependencies, such as DataSources. It >would be good to be able to fail fast, rather than when the app tries to >start up. > >James is happy to implement support in Geronimo for any definition forma= t we >choose. Let's start thinking! We can no doubt leverage such a deployment >unit outside Geronimo also... > >Geronimo will ship the Spring binaries itself. And it uses CGLIB heavily and >(I assume) Commons Logging/Log4j. So it would be nice to be able to drop= in >a Spring deployment unit and just have it start up. > >There may also be integration possibilities with transaction >management--getting access to lower-level details of transaction managem= ent >than is available via JTA. I've opened a discussion on this with Jeremy >Boynes. > >Rgds >Rod > > > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >digital self defense, top technical experts, no vendor pitches, >unmatched networking opportunities. Visit www.blackhat.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jas...@ma...> - 2004-07-09 15:28:38
|
On 9 Jul 2004, at 15:59, Rod Johnson wrote: > I haven't had time to read this thread in detail (will later tonight), > but I > think we should allow for non-XML Spring configs. Now we have sep > BeanDefinitionReaders, some beans could be sourced via JDBC, Groovy, > properties, or other cool definition formats as yet unknown... Agreed - alternatives to XML could be handy and could be used by any user of spring, whether they intend to deploy in Geronimo or not. e.g. in Groovy we could change something like this... <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property> <property name="url"><value>jdbc:mysql://localhost:3306/mydb</value></property> <property name="username"><value>root</value></property> </bean> </beans> into this Foo.groovy file bean(id:"myDataSource", class:org.apache.commons.dbcp.BasicDataSource.class, destroy_method:"close", driverClassName:"com.mysql.jdbc.Driver", url:"jdbc:mysql://localhost:3306/mydb", username:"root") Which saves a bit of typing, avoids the pointy bracket stuff and allows variables and expressions to be used (e.g. so the same script can be reused but at runtime use different parameterizable port numbers etc). Of course if ever you want if / while / for loops in your configuration, then the scripting language approach becomes a huge win. James ------- http://radio.weblogs.com/0112098/ |
