Hi, I'm trying to extract as much WSRP code as possible from GateIn so that the WSRP service can be updated without having to update GateIn itself and, ideally, be able to package it in a single (ear?) file so that it can easily be removed without having configuration files all over the place. In this process, I'm running into several issues: 1. The extension mechanism documentation is rather poor at the moment. Nowhere is it explained what extensions are good for, what can they be used for and, more importantly, what *can't* they used for. For example, it is not clear to me whether I could package the WSRP service as an extension (though I'm pretty sure I can't).

2. WSRP-related configuration is, at the moment, spread among several files located at different spots making it very difficult to extract so that it can be removed (or added to a bare portal install). For example, the main configuration file is located in web/portal/src/main/webapp/WEB-INF/conf/wsrp/wsrp-configuration.xml which is linked to by the main configuration.xml file. It would be good if this file (and the linked ones) could, at the very least, be moved to the component/wsrp module and dynamically picked-up at runtime by the kernel. I don't know if this is possible, it might just be a lack of kernel knowledge on my part.

However, even if extracting these files (and avoiding to have to link to them in the main configuration.xml file) was possible, there are still other dependencies left to be extracted. In particular, WSRP needs to create JCR workspaces and at the moment, these need to be defined in repository-configuration.xml. Is it possible to split that file so t! hat services can dynamically add new workspaces to the JCR repository as needed at runtime?

On that note, a lot of that configuration is pretty much similar for all the workspaces. Wouldn't it make sense to have reasonable default values that users would override only if needed to avoid having long and error-prone XML configuration? 3. The design of the ApplicationRegistryService makes it difficult to support WSRP because of the assumption it makes on the format of portlet identifiers leading to lots of hardcoded information and if-else cases which makes the code brittle and difficult to evolve. Independently of WSRP support, it would break if the portlet container was ever to change its identifier format. I would like to start a discussion on fixing this issue even though I know this is not the priority at the moment. TL,DR summary: What would be the best way to extract and package the WSRP-related code so that it could be added/removed dynamically (while the server is stopped at least, though, of course, hot-deploy would be even better ^_^)?

Ideas? Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Wed, 2011-01-26 at 16:26 +0100, Christophe Laprun wrote: > Hi, > > I'm trying to extract as much WSRP code as possible from GateIn so > that the WSRP service can be updated without having to update GateIn > itself and, ideally, be able to package it in a single (ear?) file so > that it can easily be removed without having configuration files all > over the place. > > In this process, I'm running into several issues: > > 1. The extension mechanism documentation is rather poor at the moment. > Nowhere is it explained what extensions are good for, what can they be > used for and, more importantly, what *can't* they used for. For > example, it is not clear to me whether I could package the WSRP > service as an extension (though I'm pretty sure I can't). You should be able to provide it as an extension, depending on what you want to do with it. The documentation for eXo kernel isn't very good, and its spread around in different locations. > 2. WSRP-related configuration is, at the moment, spread among several > files located at different spots making it very difficult to extract > so that it can be removed (or added to a bare portal install). For > example, the main configuration file is located in > web/portal/src/main/webapp/WEB-INF/conf/wsrp/wsrp-configuration.xml > which is linked to by the main configuration.xml file. It would be > good if this file (and the linked ones) could, at the very least, be > moved to the component/wsrp module and dynamically picked-up at > runtime by the kernel. I don't know if this is possible, it might just > be a lack of kernel knowledge on my part. You can add the configuration file through the extension mechanism (its what the extension mechanism is meant for), so you can move it to another module. > However, even if extracting these files (and avoiding to have to link > to them in the main configuration.xml file) was possible, there are > still other dependencies left to be extracted. In particular, WSRP > needs to create JCR workspaces and at the moment, these need to be > defined in repository-configuration.xml. Is it possible to split that > file so t! > hat services can dynamically add new workspaces to the JCR repository > as needed at runtime? don't know about the JCR configuration stuff :( > On that note, a lot of that configuration is pretty much similar for > all the workspaces. Wouldn't it make sense to have reasonable default > values that users would override only if needed to avoid having long > and error-prone XML configuration? > > 3. The design of the ApplicationRegistryService makes it difficult to > support WSRP because of the assumption it makes on the format of > portlet identifiers leading to lots of hardcoded information and > if-else cases which makes the code brittle and difficult to evolve. > Independently of WSRP support, it would break if the portlet container > was ever to change its identifier format. I would like to start a > discussion on fixing this issue even though I know this is not the > priority at the moment. > > TL,DR summary: What would be the best way to extract and package the > WSRP-related code so that it could be added/removed dynamically (while > the server is stopped at least, though, of course, hot-deploy would be > even better ^_^)? You can't dynamically add or remove things right now with the exo kernel. With the extension mechanism it requires that the ear be deployed when the server is started for the _first_ time. If you add or remove it after, it wont work (and will fill your logs with a bunch of errors). So if the wsrp.ear is available when the server first starts, its added. If the wsrp.ear is removed before the server is first started, its not added. It sucks, which is why we need a proper xml based deployment implementation.

> Ideas? > > Cordialement / Best, > Chris > > == > Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. > Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein > Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Jan 26, 2011, at 5:19 PM, Julien Viet wrote: > On Jan 26, 2011, at 5:06 PM, Matt Wringe wrote: > >> On Wed, 2011-01-26 at 16:26 +0100, Christophe Laprun wrote: >>> Hi, >>> >>> I'm trying to extract as much WSRP code as possible from GateIn so >>> that the WSRP service can be updated without having to update GateIn >>> itself and, ideally, be able to package it in a single (ear?) file so >>> that it can easily be removed without having configuration files all >>> over the place. >>> >>> In this process, I'm running into several issues: >>> >>> 1. The extension mechanism documentation is rather poor at the moment. >>> Nowhere is it explained what extensions are good for, what can they be >>> used for and, more importantly, what *can't* they used for. For >>> example, it is not clear to me whether I could package the WSRP >>> service as an extension (though I'm pretty sure I can't). >> You should be able to provide it as an extension, depending on what you >> want to do with it. >> The documentation for eXo kernel isn't very good, and its spread around >> in different locations. >> >>> 2. WSRP-related configuration is, at the moment, spread among several >>> files located at different spots making it very difficult to extract >>> so that it can be removed (or added to a bare portal install). For >>> example, the main configuration file is located in >>> web/portal/src/main/webapp/WEB-INF/conf/wsrp/wsrp-configuration.xml >>> which is linked to by the main configuration.xml file. It would be >>> good if this file (and the linked ones) could, at the very least, be >>> moved to the component/wsrp module and dynamically picked-up at >>> runtime by the kernel. I don't know if this is possible, it might just >>> be a lack of kernel knowledge on my part. >> You can add the configuration file through the extension mechanism (its >> what the extension mechanism is meant for), so you can move it to >> another module. >> >>> However, even if extracting these files (and avoiding to have to link >>> to them in the main configuration.xml file) was possible, there are >>> still other dependencies left to be extracted. In particular, WSRP >>> needs to create JCR workspaces and at the moment, these need to be >>> defined in repository-configuration.xml. Is it possible to split that >>> file so t! >>> hat services can dynamically add new workspaces to the JCR repository >>> as needed at runtime? >> don't know about the JCR configuration stuff :( >> >>> On that note, a lot of that configuration is pretty much similar for >>> all the workspaces. Wouldn't it make sense to have reasonable default >>> values that users would override only if needed to avoid having long >>> and error-prone XML configuration? >>> >>> 3. The design of the ApplicationRegistryService makes it difficult to >>> support WSRP because of the assumption it makes on the format of >>> portlet identifiers leading to lots of hardcoded information and >>> if-else cases which makes the code brittle and difficult to evolve. >>> Independently of WSRP support, it would break if the portlet container >>> was ever to change its identifier format. I would like to start a >>> discussion on fixing this issue even though I know this is not the >>> priority at the moment. >>> >>> TL,DR summary: What would be the best way to extract and package the >>> WSRP-related code so that it could be added/removed dynamically (while >>> the server is stopped at least, though, of course, hot-deploy would be >>> even better ^_^)? >> You can't dynamically add or remove things right now with the exo >> kernel. >> With the extension mechanism it requires that the ear be deployed when >> the server is started for the _first_ time. If you add or remove it >> after, it wont work (and will fill your logs with a bunch of errors). Does that mean that GateIn cannot be started then stopped then a WSRP.ear added and correctly handled?

>> So if the wsrp.ear is available when the server first starts, its added. >> If the wsrp.ear is removed before the server is first started, its not >> added. >> It sucks, which is why we need a proper xml based deployment >> implementation. > One technical constraint preventing hot redeployment is the lack of shared classes between applications in Java EE, this is required for many parts of GateIn. I don't care about hot (re-)deployment at the moment (though I have to note that it was kind of possible with JBoss Portal). > So Java EE sucks :-) > > (that being said, the WSRP JSF administration should be hot redeployable as it's a consumer of the shared classes). Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Jan 26, 2011, at 5:19 PM, Julien Viet wrote: > > On Jan 26, 2011, at 5:06 PM, Matt Wringe wrote: > >> On Wed, 2011-01-26 at 16:26 +0100, Christophe Laprun wrote: >>> Hi, >>> >>> I'm trying to extract as much WSRP code as possible from GateIn so >>> that the WSRP service can be updated without having to update GateIn >>> itself and, ideally, be able to package it in a single (ear?) file so >>> that it can easily be removed without having configuration files all >>> over the place. >>> >>> In this process, I'm running into several issues: >>> >>> 1. The extension mechanism documentation is rather poor at the moment. >>> Nowhere is it explained what extensions are good for, what can they be >>> used for and, more importantly, what *can't* they used for. For >>> example, it is not clear to me whether I could package the WSRP >>> service as an extension (though I'm pretty sure I can't). >> >> You should be able to provide it as an extension, depending on what you >> want to do with it. >> The documentation for eXo kernel isn't very good, and its spread around >> in different locations. >> >>> 2. WSRP-related configuration is, at the moment, spread among several >>> files located at different spots making it very difficult to extract >>> so that it can be removed (or added to a bare portal install). For >>> example, the main configuration file is located in >>> web/portal/src/main/webapp/WEB-INF/conf/wsrp/wsrp-configuration.xml >>> which is linked to by the main configuration.xml file. It would be >>> good if this file (and the linked ones) could, at the very least, be >>> moved to the component/wsrp module and dynamically picked-up at >>> runtime by the kernel. I don't know if this is possible, it might just >>> be a lack of kernel knowledge on my part. >> >> You can add the configuration file through the extension mechanism (its >> what the extension mechanism is meant for), so you can move it to >> another module. >> >>> However, even if extracting these files (and avoiding to have to link >>> to them in the main configuration.xml file) was possible, there are >>> still other dependencies left to be extracted. In particular, WSRP >>> needs to create JCR workspaces and at the moment, these need to be >>> defined in repository-configuration.xml. Is it possible to split that >>> file so t! >>> hat services can dynamically add new workspaces to the JCR repository >>> as needed at runtime? >> >> don't know about the JCR configuration stuff :( >> >>> On that note, a lot of that configuration is pretty much similar for >>> all the workspaces. Wouldn't it make sense to have reasonable default >>> values that users would override only if needed to avoid having long >>> and error-prone XML configuration? >>> >>> 3. The design of the ApplicationRegistryService makes it difficult to >>> support WSRP because of the assumption it makes on the format of >>> portlet identifiers leading to lots of hardcoded information and >>> if-else cases which makes the code brittle and difficult to evolve. >>> Independently of WSRP support, it would break if the portlet container >>> was ever to change its identifier format. I would like to start a >>> discussion on fixing this issue even though I know this is not the >>> priority at the moment. >>> >>> TL,DR summary: What would be the best way to extract and package the >>> WSRP-related code so that it could be added/removed dynamically (while >>> the server is stopped at least, though, of course, hot-deploy would be >>> even better ^_^)? >> >> You can't dynamically add or remove things right now with the exo >> kernel. >> With the extension mechanism it requires that the ear be deployed when >> the server is started for the _first_ time. If you add or remove it >> after, it wont work (and will fill your logs with a bunch of errors). Does that mean that GateIn cannot be started then stopped then a WSRP.ear added and correctly handled? >> So if the wsrp.ear is available when the server first starts, its added. >> If the wsrp.ear is removed before the server is first started, its not >> added. >> It sucks, which is why we need a proper xml based deployment >> implementation. > > One technical constraint preventing hot redeployment is the lack of shared classes between applications in Java EE, this is required for many parts of GateIn. I don't care about hot (re-)deployment at the moment (though I have to note that it was kind of possible with JBoss Portal). > So Java EE sucks :-) > > (that being said, the WSRP JSF administration should be hot redeployable as it's a consumer of the shared classes). Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm

On Jan 26, 2011, at 6:03 PM, Julien Viet wrote: > it was kind of possible in JPB, when you redeployed UI admin in JSF. > > it should work the same in GateIn (or if it does not we could). I was talking about the fact that you could basically hot deploy the WSRP service as a sar file in JBP and it would add the appropriate admin page / portlet and service. If you didn't want WSRP, you could just remove the sar file and you were done, no other dependency anywhere else. It didn't quite work completely hot but at least it was possible to add/remove the service in an appropriate manner while the server was stopped regardless of whether the service was present when the server was *first* started…

I'm not asking for hot (un-)deployment but I'd like to at least be able to package my service in one *single* file that could be added/removed cleanly anytime the server is stopped… Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm

Hi, I'm trying to extract as much WSRP code as possible from GateIn so that the WSRP service can be updated without having to update GateIn itself and, ideally, be able to package it in a single (ear?) file so that it can easily be removed without having configuration files all over the place. In this process, I'm running into several issues: 1. The extension mechanism documentation is rather poor at the moment. Nowhere is it explained what extensions are good for, what can they be used for and, more importantly, what *can't* they used for. For example, it is not clear to me whether I could package the WSRP service as an extension (though I'm pretty sure I can't). 2. WSRP-related configuration is, at the moment, spread among several files located at different spots making it very difficult to extract so that it can be removed (or added to a bare portal install). For example, the main configuration file is located in web/portal/src/main/webapp/WEB-INF/conf/wsrp/wsrp-configuration.xml which is linked to by the main configuration.xml file. It would be good if this file (and the linked ones) could, at the very least, be moved to the component/wsrp module and dynamically picked-up at runtime by the kernel. I don't know if this is possible, it might just be a lack of kernel knowledge on my part. However, even if extracting these files (and avoiding to have to link to them in the main configuration.xml file) was possible, there are still other dependencies left to be extracted. In particular, WSRP needs to create JCR workspaces and at the moment, these need to be defined in repository-configuration.xml. Is it possible to split that file so t! hat services can dynamically add new workspaces to the JCR repository as needed at runtime? On that note, a lot of that configuration is pretty much similar for all the workspaces. Wouldn't it make sense to have reasonable default values that users would override only if needed to avoid having long and error-prone XML configuration? 3. The design of the ApplicationRegistryService makes it difficult to support WSRP because of the assumption it makes on the format of portlet identifiers leading to lots of hardcoded information and if-else cases which makes the code brittle and difficult to evolve. Independently of WSRP support, it would break if the portlet container was ever to change its identifier format. I would like to start a discussion on fixing this issue even though I know this is not the priority at the moment. TL,DR summary: What would be the best way to extract and package the WSRP-related code so that it could be added/removed dynamically (while the server is stopped at least, though, of course, hot-deploy would be even better ^_^)? Ideas? Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

Hello Christophe, I'll try to share some of my knowledge about the extension mechanism. Hopefully it will answer some of your questions. The extension mechanism let's you : * plug your own kernel config from your own war instead of portal.war (kernel will load it from yourextension.war/WEB-INF/conf/configuration.xml) * extend the /portal servlet context so that it can serve resources from your own war About the question of JCR workspaces, the extension mechanism is able to merge all repository-configuration.xml it finds. So to declare your workspaces, just place them in a repository-configuration.xml inside your extension war at the exact same location you'll find it in portal.war.

HTH. On Wed, Jan 26, 2011 at 4:26 PM, Christophe Laprun <claprun(a)redhat.com&gt; wrote: Hi, I'm trying to extract as much WSRP code as possible from GateIn so that the WSRP service can be updated without having to update GateIn itself and, ideally, be able to package it in a single (ear?) file so that it can easily be removed without having configuration files all over the place. In this process, I'm running into several issues: 1. The extension mechanism documentation is rather poor at the moment. Nowhere is it explained what extensions are good for, what can they be used for and, more importantly, what *can't* they used for. For example, it is not clear to me whether I could package the WSRP service as an extension (though I'm pretty sure I can't). 2. WSRP-related configuration is, at the moment, spread among several files located at different spots making it very difficult to extract so that it can be removed (or added to a bare portal install). For example, the main configuration file is located in web/portal/src/main/webapp/WEB-INF/conf/wsrp/wsrp-configuration.xml which is linked to by the main configuration.xml file. It would be good if this file (and the linked ones) could, at the very least, be moved to the component/wsrp module and dynamically picked-up at runtime by the kernel. I don't know if this is possible, it might just be a lack of kernel knowledge on my part. However, even if extracting these files (and avoiding to have to link to them in the main configuration.xml file) was possible, there are still other dependencies left to be extracted. In particular, WSRP needs to create JCR workspaces and at the moment, these need to be defined in repository-configuration.xml. Is it possible to split that file so t! hat services can dynamically add new workspaces to the JCR repository as needed at runtime? On that note, a lot of that configuration is pretty much similar for all the workspaces. Wouldn't it make sense to have reasonable default values that users would override only if needed to avoid having long and error-prone XML configuration? 3. The design of the ApplicationRegistryService makes it difficult to support WSRP because of the assumption it makes on the format of portlet identifiers leading to lots of hardcoded information and if-else cases which makes the code brittle and difficult to evolve. Independently of WSRP support, it would break if the portlet container was ever to change its identifier format. I would like to start a discussion on fixing this issue even though I know this is not the priority at the moment. TL,DR summary: What would be the best way to extract and package the WSRP-related code so that it could be added/removed dynamically (while the server is stopped at least, though, of course, hot-deploy would be even better ^_^)? Ideas? Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev -- Patrice Lamarque VP Platform eXo Platform SAS _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Jan 26, 2011, at 8:06 PM, Patrice Lamarque wrote: Hello Christophe, I'll try to share some of my knowledge about the extension mechanism. Hopefully it will answer some of your questions. The extension mechanism let's you : * plug your own kernel config from your own war instead of portal.war (kernel will load it from yourextension.war/WEB-INF/conf/configuration.xml) * extend the /portal servlet context so that it can serve resources from your own war About the question of JCR workspaces, the extension mechanism is able to merge all repository-configuration.xml it finds. So to declare your workspaces, just place them in a repository-configuration.xml inside your extension war at the exact same location you'll find it in portal.war. I didnt know about that, is it referenced somewhere ? HTH. On Wed, Jan 26, 2011 at 4:26 PM, Christophe Laprun <claprun(a)redhat.com&gt;wrote: > Hi, > > I'm trying to extract as much WSRP code as possible from GateIn so that > the WSRP service can be updated without having to update GateIn itself and, > ideally, be able to package it in a single (ear?) file so that it can easily > be removed without having configuration files all over the place. > > In this process, I'm running into several issues: > > 1. The extension mechanism documentation is rather poor at the moment. > Nowhere is it explained what extensions are good for, what can they be used > for and, more importantly, what *can't* they used for. For example, it is > not clear to me whether I could package the WSRP service as an extension > (though I'm pretty sure I can't). > > 2. WSRP-related configuration is, at the moment, spread among several > files located at different spots making it very difficult to extract so that > it can be removed (or added to a bare portal install). For example, the main > configuration file is located in > web/portal/src/main/webapp/WEB-INF/conf/wsrp/wsrp-configuration.xml which is > linked to by the main configuration.xml file. It would be good if this file > (and the linked ones) could, at the very least, be moved to the > component/wsrp module and dynamically picked-up at runtime by the kernel. I > don't know if this is possible, it might just be a lack of kernel knowledge > on my part. However, even if extracting these files (and avoiding to have to > link to them in the main configuration.xml file) was possible, there are > still other dependencies left to be extracted. In particular, WSRP needs to > create JCR workspaces and at the moment, these need to be defined in > repository-configuration.xml. Is it possible to split that file so t! > hat services can dynamically add new workspaces to the JCR repository as > needed at runtime? On that note, a lot of that configuration is pretty much > similar for all the workspaces. Wouldn't it make sense to have reasonable > default values that users would override only if needed to avoid having long > and error-prone XML configuration? > > 3. The design of the ApplicationRegistryService makes it difficult to > support WSRP because of the assumption it makes on the format of portlet > identifiers leading to lots of hardcoded information and if-else cases which > makes the code brittle and difficult to evolve. Independently of WSRP > support, it would break if the portlet container was ever to change its > identifier format. I would like to start a discussion on fixing this issue > even though I know this is not the priority at the moment. > > TL,DR summary: What would be the best way to extract and package the > WSRP-related code so that it could be added/removed dynamically (while the > server is stopped at least, though, of course, hot-deploy would be even > better ^_^)? > > Ideas? > > Cordialement / Best, > Chris > > == > Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. > Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein > Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev > -- *Patrice Lamarque* VP Platform eXo Platform SAS _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Wed, 2011-01-26 at 22:23 +0100, Julien Viet wrote: > why do one's need hot redeploy ? I don't think hot deploy/undeploy/redeploy is really that important. What I do think is important is that deploy/undeploy/redeploy can be done. Right now we can't do this with the extension mechanism, we can only add a page or a portlet when the server first starts.

> > if it's to increase productivity, I don't believe in that solution > anymore because the complexity to make it real in a server agnostic > manner is very high. > > > However, I do believe in providing a server that is so quick to boot > that redeploy is not necessary anymore, or is not perceived as a value > add. > > > If you take GateIn on Tomcat, it starts in 25 seconds (first one). It > used to boot in 18s seconds one year ago, at this time, the boot time > was roughly divided into > > > - Tomcat deployment and web app scanning : 5 seconds > - JCR init 7 seconds > - XML parsing 3 seconds (JAXB and JBoss XB) > - various other things for the rest of the time > > > - I know that the JCR team is working on improving startup time of JCR > (it lost seconds because of the switch to JBoss Cache, which is slow > to start and they start like 18 cache instances but they are now able > to collocate a single instance). > - We will decrease XML parsing by getting rid of *XB , it's just a > matter of rewriting XML deployment parsing. > - We can also decrease web app deployment if we deploy less web > applications. > > > I know that JBoss is also working on making AS7 blazing fast to boot > and they will achieve it because they took the right decisions. > > > Therefore instead of taking the decision to do R&D to provide hot > redeploy, I would instead take the decision to work on reducing the > server boot time. > > > So the real challenge is: do you think we can make GateIn boot in 10 > seconds (Tomcat / AS7 / Jetty) ? > > > On Jan 26, 2011, at 9:42 PM, Marko Strukelj wrote: > > > > > One technical constraint preventing hot redeployment is the > > lack of shared classes between applications in Java EE, this > > is required for many parts of GateIn. > > > > So Java EE sucks :-) > > > > (that being said, the WSRP JSF administration should be hot > > redeployable as it's a consumer of the shared classes). > > > > > > > > > > Class sharing is a matter of classloader sharing, and all .wars > > share a parent classloader that contains classes in > > JBOSS_HOME/server/default/lib/*.jar or TOMCAT_HOME/lib/*.jar. > > > > > > That's outside Java EE scope, true, but it's de-facto how all > > implementations do it so it's a real-world existing mechanism, and > > we're relying on it too :) > > Those shared classes aren't hot-deployable though - it's just > > directories containing jars. > > > > > > In JBoss it's possible to get very creative with classloader > > hierarchies, but it requires extra configuration, and then extra > > configuration for user .war / .ear as well so that they can > > participate in these custom classloaders. Maybe that could be done > > automatically via custom deployers if only we could reliably > > identify user .ear/.wars containing portal apps (maybe if they > > contain portlet.xml?). > > > > > > The kernel problem is that it should respond to some undeploy / > > redeploy events fired by jboss, and remove services from its > > RootContainer and PortalContainer, then rescan only redeployed > > archives to read configuration, and instantiate, inject, init / > > start the services and other picocontainer components. > > > > > > We have WCI layer to provide integration with container. Maybe we > > could add deploy / undeploy callbacks there, with different wiring > > for Tomcat and JBoss. Although at the moment kernel doesn't actually > > interact with WCI, I think it's completely separate. > > > > > > > > > > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Wed, 2011-01-26 at 22:23 +0100, Julien Viet wrote: > why do one's need hot redeploy ? I don't think hot deploy/undeploy/redeploy is really that important. What I do think is important is that deploy/undeploy/redeploy can be done. Right now we can't do this with the extension mechanism, we can only add a page or a portlet when the server first starts. > > if it's to increase productivity, I don't believe in that solution > anymore because the complexity to make it real in a server agnostic > manner is very high. > > > However, I do believe in providing a server that is so quick to boot > that redeploy is not necessary anymore, or is not perceived as a value > add. > > > If you take GateIn on Tomcat, it starts in 25 seconds (first one). It > used to boot in 18s seconds one year ago, at this time, the boot time > was roughly divided into > > > - Tomcat deployment and web app scanning : 5 seconds > - JCR init 7 seconds > - XML parsing 3 seconds (JAXB and JBoss XB) > - various other things for the rest of the time > > > - I know that the JCR team is working on improving startup time of JCR > (it lost seconds because of the switch to JBoss Cache, which is slow > to start and they start like 18 cache instances but they are now able > to collocate a single instance). > - We will decrease XML parsing by getting rid of *XB , it's just a > matter of rewriting XML deployment parsing. > - We can also decrease web app deployment if we deploy less web > applications. > > > I know that JBoss is also working on making AS7 blazing fast to boot > and they will achieve it because they took the right decisions. > > > Therefore instead of taking the decision to do R&D to provide hot > redeploy, I would instead take the decision to work on reducing the > server boot time. > > > So the real challenge is: do you think we can make GateIn boot in 10 > seconds (Tomcat / AS7 / Jetty) ? > > > On Jan 26, 2011, at 9:42 PM, Marko Strukelj wrote: > > > > > One technical constraint preventing hot redeployment is the > > lack of shared classes between applications in Java EE, this > > is required for many parts of GateIn. > > > > So Java EE sucks :-) > > > > (that being said, the WSRP JSF administration should be hot > > redeployable as it's a consumer of the shared classes). > > > > > > > > > > Class sharing is a matter of classloader sharing, and all .wars > > share a parent classloader that contains classes in > > JBOSS_HOME/server/default/lib/*.jar or TOMCAT_HOME/lib/*.jar. > > > > > > That's outside Java EE scope, true, but it's de-facto how all > > implementations do it so it's a real-world existing mechanism, and > > we're relying on it too :) > > Those shared classes aren't hot-deployable though - it's just > > directories containing jars. > > > > > > In JBoss it's possible to get very creative with classloader > > hierarchies, but it requires extra configuration, and then extra > > configuration for user .war / .ear as well so that they can > > participate in these custom classloaders. Maybe that could be done > > automatically via custom deployers if only we could reliably > > identify user .ear/.wars containing portal apps (maybe if they > > contain portlet.xml?). > > > > > > The kernel problem is that it should respond to some undeploy / > > redeploy events fired by jboss, and remove services from its > > RootContainer and PortalContainer, then rescan only redeployed > > archives to read configuration, and instantiate, inject, init / > > start the services and other picocontainer components. > > > > > > We have WCI layer to provide integration with container. Maybe we > > could add deploy / undeploy callbacks there, with different wiring > > for Tomcat and JBoss. Although at the moment kernel doesn't actually > > interact with WCI, I think it's completely separate. > > > > > > > > > >

Hot deploy is a very neat feature that people expect nowadays, but yes it's true, fast startup is even more important and if fast enough, it can offset the lack of hot-deploy. But I think making deploy / undeploy to function would force us to properly implement and give more thought to some of the things, and I think there are scenarios (more than I can imagine) where lack of it is a hurdle. I'm thinking things like: - component modularization Looks like WSRP attempts either exposed some lack of clean portal - components separation, or maybe there's just a lack of understanding the facilities in place, and how to use them properly. - automated testing Let's think Shrinkwrap / Arquillian style of testing ... Programmatically compose a test archive, start container, deploy the test archive and execute tests. Currently to test things with GateIn you have to do that upside down: place tests into deploy first, then start the container, then trigger test execution. Completely different (and surprising) flow. I'm guessing, but seems to me this might be the reason that's holding back GateIn support in Arquillian. - cleanup after component is removed (that's handy for testing) If added component registers stuff in JCR, creates pages, navigations ... is there a simple way for configurations to get removed if component is undeployed? That would be very useful for testing. Or, transient storage could be configured for testing ... but would have to be prefilled with some initial portal data to prevent first-time init upon every start. Maybe someone can think of some more scenarios related to this ... On Wed, Jan 26, 2011 at 10:36 PM, Matt Wringe <mwringe(a)redhat.com <mailto:mwringe@redhat.com>> wrote: On Wed, 2011-01-26 at 22:23 +0100, Julien Viet wrote: > why do one's need hot redeploy ? I don't think hot deploy/undeploy/redeploy is really that important. What I do think is important is that deploy/undeploy/redeploy can be done. Right now we can't do this with the extension mechanism, we can only add a page or a portlet when the server first starts. > > if it's to increase productivity, I don't believe in that solution > anymore because the complexity to make it real in a server agnostic > manner is very high. > > > However, I do believe in providing a server that is so quick to boot > that redeploy is not necessary anymore, or is not perceived as a value > add. > > > If you take GateIn on Tomcat, it starts in 25 seconds (first one). It > used to boot in 18s seconds one year ago, at this time, the boot time > was roughly divided into > > > - Tomcat deployment and web app scanning : 5 seconds > - JCR init 7 seconds > - XML parsing 3 seconds (JAXB and JBoss XB) > - various other things for the rest of the time > > > - I know that the JCR team is working on improving startup time of JCR > (it lost seconds because of the switch to JBoss Cache, which is slow > to start and they start like 18 cache instances but they are now able > to collocate a single instance). > - We will decrease XML parsing by getting rid of *XB , it's just a > matter of rewriting XML deployment parsing. > - We can also decrease web app deployment if we deploy less web > applications. > > > I know that JBoss is also working on making AS7 blazing fast to boot > and they will achieve it because they took the right decisions. > > > Therefore instead of taking the decision to do R&D to provide hot > redeploy, I would instead take the decision to work on reducing the > server boot time. > > > So the real challenge is: do you think we can make GateIn boot in 10 > seconds (Tomcat / AS7 / Jetty) ? > > > On Jan 26, 2011, at 9:42 PM, Marko Strukelj wrote: > > > > > One technical constraint preventing hot redeployment is the > > lack of shared classes between applications in Java EE, this > > is required for many parts of GateIn. > > > > So Java EE sucks :-) > > > > (that being said, the WSRP JSF administration should be hot > > redeployable as it's a consumer of the shared classes). > > > > > > > > > > Class sharing is a matter of classloader sharing, and all .wars > > share a parent classloader that contains classes in > > JBOSS_HOME/server/default/lib/*.jar or TOMCAT_HOME/lib/*.jar. > > > > > > That's outside Java EE scope, true, but it's de-facto how all > > implementations do it so it's a real-world existing mechanism, and > > we're relying on it too :) > > Those shared classes aren't hot-deployable though - it's just > > directories containing jars. > > > > > > In JBoss it's possible to get very creative with classloader > > hierarchies, but it requires extra configuration, and then extra > > configuration for user .war / .ear as well so that they can > > participate in these custom classloaders. Maybe that could be done > > automatically via custom deployers if only we could reliably > > identify user .ear/.wars containing portal apps (maybe if they > > contain portlet.xml?). > > > > > > The kernel problem is that it should respond to some undeploy / > > redeploy events fired by jboss, and remove services from its > > RootContainer and PortalContainer, then rescan only redeployed > > archives to read configuration, and instantiate, inject, init / > > start the services and other picocontainer components. > > > > > > We have WCI layer to provide integration with container. Maybe we > > could add deploy / undeploy callbacks there, with different wiring > > for Tomcat and JBoss. Although at the moment kernel doesn't actually > > interact with WCI, I think it's completely separate. > > > > > > > > > > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

are you talking from an end user experience or a gatein developer experience perspective ?

On Jan 27, 2011, at 1:37 PM, Nick Scavelli wrote: > On 01/26/2011 04:23 PM, Julien Viet wrote: >> why do one's need hot redeploy ? >> >> if it's to increase productivity, I don't believe in that solution anymore because the complexity to make it real in a server agnostic manner is very high. >> >> However, I do believe in providing a server that is so quick to boot that redeploy is not necessary anymore, or is not perceived as a value add. >> > From an operations point of view, I don't want to have to bring down my servers no matter how fast they start. I just think we need to have the mindset of these things when we implement certain features. Having the ability to deploy/undeploy/redeploy and thinking more modularly will open doors for things we can do with the portal. >

Hot deploy is a very neat feature that people expect nowadays, but yes it's true, fast startup is even more important and if fast enough, it can offset the lack of hot-deploy. But I think making deploy / undeploy to function would force us to properly implement and give more thought to some of the things, and I think there are scenarios (more than I can imagine) where lack of it is a hurdle. I'm thinking things like: - component modularization Looks like WSRP attempts either exposed some lack of clean portal - components separation, or maybe there's just a lack of understanding the facilities in place, and how to use them properly. - automated testing Let's think Shrinkwrap / Arquillian style of testing ... Programmatically compose a test archive, start container, deploy the test archive and execute tests. Currently to test things with GateIn you have to do that upside down: place tests into deploy first, then start the container, then trigger test execution. Completely different (and surprising) flow. I'm guessing, but seems to me this might be the reason that's holding back GateIn support in Arquillian. - cleanup after component is removed (that's handy for testing) If added component registers stuff in JCR, creates pages, navigations ... is there a simple way for configurations to get removed if component is undeployed? That would be very useful for testing. Or, transient storage could be configured for testing ... but would have to be prefilled with some initial portal data to prevent first-time init upon every start. Maybe someone can think of some more scenarios related to this ... On Wed, Jan 26, 2011 at 10:36 PM, Matt Wringe <mwringe(a)redhat.com&gt; wrote: > On Wed, 2011-01-26 at 22:23 +0100, Julien Viet wrote: > > why do one's need hot redeploy ? > > I don't think hot deploy/undeploy/redeploy is really that important. > > What I do think is important is that deploy/undeploy/redeploy can be > done. Right now we can't do this with the extension mechanism, we can > only add a page or a portlet when the server first starts. > > > > > if it's to increase productivity, I don't believe in that solution > > anymore because the complexity to make it real in a server agnostic > > manner is very high. > > > > > > However, I do believe in providing a server that is so quick to boot > > that redeploy is not necessary anymore, or is not perceived as a value > > add. > > > > > > If you take GateIn on Tomcat, it starts in 25 seconds (first one). It > > used to boot in 18s seconds one year ago, at this time, the boot time > > was roughly divided into > > > > > > - Tomcat deployment and web app scanning : 5 seconds > > - JCR init 7 seconds > > - XML parsing 3 seconds (JAXB and JBoss XB) > > - various other things for the rest of the time > > > > > > - I know that the JCR team is working on improving startup time of JCR > > (it lost seconds because of the switch to JBoss Cache, which is slow > > to start and they start like 18 cache instances but they are now able > > to collocate a single instance). > > - We will decrease XML parsing by getting rid of *XB , it's just a > > matter of rewriting XML deployment parsing. > > - We can also decrease web app deployment if we deploy less web > > applications. > > > > > > I know that JBoss is also working on making AS7 blazing fast to boot > > and they will achieve it because they took the right decisions. > > > > > > Therefore instead of taking the decision to do R&D to provide hot > > redeploy, I would instead take the decision to work on reducing the > > server boot time. > > > > > > So the real challenge is: do you think we can make GateIn boot in 10 > > seconds (Tomcat / AS7 / Jetty) ? > > > > > > On Jan 26, 2011, at 9:42 PM, Marko Strukelj wrote: > > > > > > > > One technical constraint preventing hot redeployment is the > > > lack of shared classes between applications in Java EE, this > > > is required for many parts of GateIn. > > > > > > So Java EE sucks :-) > > > > > > (that being said, the WSRP JSF administration should be hot > > > redeployable as it's a consumer of the shared classes). > > > > > > > > > > > > > > > Class sharing is a matter of classloader sharing, and all .wars > > > share a parent classloader that contains classes in > > > JBOSS_HOME/server/default/lib/*.jar or TOMCAT_HOME/lib/*.jar. > > > > > > > > > That's outside Java EE scope, true, but it's de-facto how all > > > implementations do it so it's a real-world existing mechanism, and > > > we're relying on it too :) > > > Those shared classes aren't hot-deployable though - it's just > > > directories containing jars. > > > > > > > > > In JBoss it's possible to get very creative with classloader > > > hierarchies, but it requires extra configuration, and then extra > > > configuration for user .war / .ear as well so that they can > > > participate in these custom classloaders. Maybe that could be done > > > automatically via custom deployers if only we could reliably > > > identify user .ear/.wars containing portal apps (maybe if they > > > contain portlet.xml?). > > > > > > > > > The kernel problem is that it should respond to some undeploy / > > > redeploy events fired by jboss, and remove services from its > > > RootContainer and PortalContainer, then rescan only redeployed > > > archives to read configuration, and instantiate, inject, init / > > > start the services and other picocontainer components. > > > > > > > > > We have WCI layer to provide integration with container. Maybe we > > > could add deploy / undeploy callbacks there, with different wiring > > > for Tomcat and JBoss. Although at the moment kernel doesn't actually > > > interact with WCI, I think it's completely separate. > > > > > > > > > > > > > > > > > > >