[gatein-dev] JBoss AS and TLDs

[Dimitri BAELI]

../../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, 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 at redhat.com> 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20091006/63c55471/attachment.html