Portlet TLDs on the JBoss AS version of GateIn was not working, so I had to renable the patch to specify the portlet war which contains the portlet TLDs. [I don't know why the patch was missing, if there was a reason for its absence please let me know]

This means we have a patch to the deployers/jbossweb.deployers/web.xml to specify the jar containing the tlds (see http://www.jboss.org/community/wiki/GlobalTLDs)

> <init-param> > <description>Portlet standard tlds</description> > <param-name>tagLibJar2</param-name> > <param-value>../../deploy/exoplatform.ear/pc-portlet-2.1.0- > Beta1.jar</param-value> > </init-param> Can we change the jar name to be unversioned so that when the version changes it doesn't break this?

Or can we specify a token instead of hardcoding the jar name? Or does anyone know a better way to add the tlds to the portlets on JBoss AS? _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Tue, 2009-10-06 at 17:08 +0200, Julien Viet wrote: > On Oct 6, 2009, at 4:59 PM, Matt Wringe wrote: > > > Portlet TLDs on the JBoss AS version of GateIn was not working, so I > > had > > to renable the patch to specify the portlet war which contains the > > portlet TLDs. [I don't know why the patch was missing, if there was a > > reason for its absence please let me know] > > > > It works differently in tomcat (to not say more conveniently), as > tomcat takes any TLD that it finds in the lib directory. yeah, I like how with tomcat it will find and use all tlds on the classpath. > > This means we have a patch to the deployers/jbossweb.deployers/web.xml > > to specify the jar containing the tlds (see > > http://www.jboss.org/community/wiki/GlobalTLDs) > > it would be nice in JBoss AS to have a better way to add global TLD > that do not require a patch of a file because we also have to keep the > web.xml file in our JBoss patch directory. Would it be possible to > have something that goes in that direction, like a deployment > descriptor that would be found by JBoss deployers and we would only > have to have the correct declaration in the JBoss patch directory. We can create a custom jboss deployer that could do this for us (and we could just use the portlet.xml file as the triggering deployment descriptor). I already have one that was designed for now abandoned JBoss AS5 version of JBoss Portal. What this deployer does is modify the web.xml of the portlet to do the exact same thing as the patch. JBoss deployers are really limited at this point when it comes to modify things other than deployment descriptors. There are a lot of things we can do with a JBoss deployer, we wouldn't even need to use the container specific wci implementation since the deployer can easily add the servlets to the web.xml. I am not sure if we want to go this route (and we would need to update exobuild to allow deployment to the deployers directory instead of the deploy directory). Thoughts on this? > > > >> <init-param> > >> <description>Portlet standard tlds</description> > >> <param-name>tagLibJar2</param-name> > >> <param-value>../../deploy/exoplatform.ear/pc-portlet-2.1.0- > >> Beta1.jar</param-value> > >> </init-param> > > > > Can we change the jar name to be unversioned so that when the version > > changes it doesn't break this? > > you mean as a deploy time facility ? > > as this jar contains code, maybe it would be best to copy the TLD in > another jar file at deploy time that would have a constant name. hmm, I guess we could do that and just have it as an exploded war in the patch. If we want to be able to deploy an actual war from the maven repo, we would still need to figure out how remove the versioning from its name (I don't know if exopackaging can do that or not). > > Or can we specify a token instead of > > hardcoding the jar name? > > > > Or does anyone know a better way to add the tlds to the portlets on > > JBoss AS? > > > > _______________________________________________ > > 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 Tue, 2009-10-06 at 19:20 +0200, Dimitri BAELI wrote: > ../../deploy/exoplatform.ear/pc-portlet-2.1.0-Beta01.jar has three > main issues: > * ../../deploy : hard coded path > * exoplatform.ear : hard coded ear name > * pc-portlet-2.1.0-Beta01.jar : hardcoded version > > We can at least use the resource filtering of maven to generate the > server-patch jar > * Ideally with ${ear.name} and ${org.gatein.pc.version} from > gatein-parent pom. > > Please fill an issue on that in GTNPORTAL https://jira.jboss.org/jira/browse/GTNPORTAL-25 > , I'll have a look, but using the maven tooling is better imho (as > exobuild is slowly migrating to maven). > > Dimitri BAELI - eXo Platform SAS > > > On Tue, Oct 6, 2009 at 5:35 PM, Matt Wringe <mwringe(a)redhat.com&gt; > wrote: > On Tue, 2009-10-06 at 17:08 +0200, Julien Viet wrote: > > On Oct 6, 2009, at 4:59 PM, Matt Wringe wrote: > > > > > Portlet TLDs on the JBoss AS version of GateIn was not > working, so I > > > had > > > to renable the patch to specify the portlet war which > contains the > > > portlet TLDs. [I don't know why the patch was missing, if > there was a > > > reason for its absence please let me know] > > > > > > > It works differently in tomcat (to not say more > conveniently), as > > tomcat takes any TLD that it finds in the lib directory. > > > yeah, I like how with tomcat it will find and use all tlds on > the > classpath. > > > > This means we have a patch to the > deployers/jbossweb.deployers/web.xml > > > to specify the jar containing the tlds (see > > > http://www.jboss.org/community/wiki/GlobalTLDs) > > > > it would be nice in JBoss AS to have a better way to add > global TLD > > that do not require a patch of a file because we also have > to keep the > > web.xml file in our JBoss patch directory. Would it be > possible to > > have something that goes in that direction, like a > deployment > > descriptor that would be found by JBoss deployers and we > would only > > have to have the correct declaration in the JBoss patch > directory. > > > We can create a custom jboss deployer that could do this for > us (and we > could just use the portlet.xml file as the triggering > deployment > descriptor). > I already have one that was designed for now abandoned JBoss > AS5 version > of JBoss Portal. What this deployer does is modify the web.xml > of the > portlet to do the exact same thing as the patch. JBoss > deployers are > really limited at this point when it comes to modify things > other than > deployment descriptors. > There are a lot of things we can do with a JBoss deployer, we > wouldn't > even need to use the container specific wci implementation > since the > deployer can easily add the servlets to the web.xml. > > I am not sure if we want to go this route (and we would need > to update > exobuild to allow deployment to the deployers directory > instead of the > deploy directory). > > Thoughts on this? > > > > > > >> <init-param> > > >> <description>Portlet standard tlds</description> > > >> <param-name>tagLibJar2</param-name> > > >> > <param-value>../../deploy/exoplatform.ear/pc-portlet-2.1.0- > > >> Beta1.jar</param-value> > > >> </init-param> > > > > > > Can we change the jar name to be unversioned so that when > the version > > > changes it doesn't break this? > > > > you mean as a deploy time facility ? > > > > as this jar contains code, maybe it would be best to copy > the TLD in > > another jar file at deploy time that would have a constant > name. > > > hmm, I guess we could do that and just have it as an exploded > war in the > patch. If we want to be able to deploy an actual war from the > maven > repo, we would still need to figure out how remove the > versioning from > its name (I don't know if exopackaging can do that or not). > > > > > Or can we specify a token instead of > > > hardcoding the jar name? > > > > > > Or does anyone know a better way to add the tlds to the > portlets on > > > JBoss AS? > > > > > > _______________________________________________ > > > 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 10/06/2009 05:35 PM, Matt Wringe wrote: > On Tue, 2009-10-06 at 17:08 +0200, Julien Viet wrote: > >> On Oct 6, 2009, at 4:59 PM, Matt Wringe wrote: >> >> >>> Portlet TLDs on the JBoss AS version of GateIn was not working, >>> so I >>> had >>> to renable the patch to specify the portlet war which contains the >>> portlet TLDs. [I don't know why the patch was missing, if there >>> was a >>> reason for its absence please let me know] >>> >>> >> It works differently in tomcat (to not say more conveniently), as >> tomcat takes any TLD that it finds in the lib directory. >> > yeah, I like how with tomcat it will find and use all tlds on the > classpath. > > >>> This means we have a patch to the deployers/jbossweb.deployers/ >>> web.xml >>> to specify the jar containing the tlds (see >>> http://www.jboss.org/community/wiki/GlobalTLDs) >>> >> it would be nice in JBoss AS to have a better way to add global TLD >> that do not require a patch of a file because we also have to keep >> the >> web.xml file in our JBoss patch directory. Would it be possible to >> have something that goes in that direction, like a deployment >> descriptor that would be found by JBoss deployers and we would only >> have to have the correct declaration in the JBoss patch directory. >> > We can create a custom jboss deployer that could do this for us > (and we > could just use the portlet.xml file as the triggering deployment > descriptor). > I already have one that was designed for now abandoned JBoss AS5 > version > of JBoss Portal. What this deployer does is modify the web.xml of the > portlet to do the exact same thing as the patch. JBoss deployers are > really limited at this point when it comes to modify things other > than > deployment descriptors. > There are a lot of things we can do with a JBoss deployer, we > wouldn't > even need to use the container specific wci implementation since the > deployer can easily add the servlets to the web.xml. > > I am not sure if we want to go this route (and we would need to > update > exobuild to allow deployment to the deployers directory instead of > the > deploy directory). > > Thoughts on this? > I was wondering about when having an AS5 deployer would provide some benefits, looks like it might be the time. Let's discuss this on the IRC. >>> >>>> <init-param> >>>> <description>Portlet standard tlds</description> >>>> <param-name>tagLibJar2</param-name> >>>> <param-value>../../deploy/exoplatform.ear/pc-portlet-2.1.0- >>>> Beta1.jar</param-value> >>>> </init-param> >>>> >>> Can we change the jar name to be unversioned so that when the >>> version >>> changes it doesn't break this? >>> >> you mean as a deploy time facility ? >> >> as this jar contains code, maybe it would be best to copy the TLD in >> another jar file at deploy time that would have a constant name. >> > hmm, I guess we could do that and just have it as an exploded war > in the > patch. If we want to be able to deploy an actual war from the maven > repo, we would still need to figure out how remove the versioning > from > its name (I don't know if exopackaging can do that or not). > > >>> Or can we specify a token instead of >>> hardcoding the jar name? >>> >>> Or does anyone know a better way to add the tlds to the portlets on >>> JBoss AS? >>> >>> _______________________________________________ >>> 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 >