[jsr-314-open] Fwd: Allow multiple taglib.xml files for the same namespace

Dan Allen dan.j.allen at gmail.com
Fri Nov 13 13:38:13 EST 2009


I think I started a thread with almost the same subject line in May.

"aggregating tag libraries under a common namespace"
http://archives.java.sun.com/cgi-bin/wa?A1=ind0905&L=JSR-314-OPEN&X=4F15AC05AE45097D70#3

Glad to see a patch.

-Dan

On Fri, Nov 13, 2009 at 10:10 AM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> Forwarded from dev list.
>
> Lincoln Baxter III
> http://ocpsoft.com
> http://scrumshark.com
> Keep it simple.
>
> ---------- Forwarded message ----------
> From: "Matthias Berndt" <matthias.berndt at systemtrap.net>
> Date: Nov 13, 2009 10:01 AM
> Subject: Allow multiple taglib.xml files for the same namespace
> To: <dev at javaserverfaces.dev.java.net>
>
> Hello,
>
> first I'd like to explain my intention. The scenario is writing multiple
> JSF components being bundled in more than one java archive. Each java
> archive has its own taglib.xml descriptor so you can use them
> separately. These components belong to the same project or organisation
> and should be published within the same namespace. This isn't possible
> with facelets at the moment and is a known issue to facelets. See:
> https://facelets.dev.java.net/issues/show_bug.cgi?id=118
>
> To support this scenario I'm aware of 3 possible solutions.
>
> The first one is merging the needed java archives especially the
> taglib.xml. I think this one is bad because the separation between the
> component projects is destroyed.
>
> The second one is merging the taglib definitions while being processed
> by FaceletTaglibConfigProcessor#processTagLibrary(). In line 308 a new
> TagLibraryImpl is created for every facelet-taglib element. This can be
> extended to use an already existing TagLibraryImpl for a specific
> namespace. This extension requires about 10 to 15 lines of code. As a
> result there will be one TagLibraryImpl for multiple facelet-taglib
> elements with the same namespace.
>
> The third one, my preferd one, is using the existing
> CompositeTagLibrary. As a result and in contrast to the second method
> each facelet-taglib element will be represented by a TagLibraryImpl and
> combined by CompositeTagLibrary. This requires only a minor change. In
> FaceletTaglibConfigProcessor#processTagLibrary() in line 318 the created
> TagLibraryImpl is added to the compiler. Compiler#addTagLibrary() tests
> if the given library is already known to the compiler. Subsequently this
> is done by using equals() and hashCode() in AbstractTagLibrary. At the
> moment hashCode() is implemented to use nothing except the namespace. If
> there are multiple TagLibraryImpl with the same namespace only one will
> be included in the compiler. The rest is thrown away. By extending
> hashCode() to use this.factories and this.functions in the calculation
> multiple TagLibraryImpl with different tags etc. can coexist. IMO it
> makes sense by reason taglibs are not equal only because they define the
> same namespace.
> CompositeTagLibrary handles this very well so no other changes are
> required.
>
> I attached a patch to modify AbstractTagLibrary#hashCode(). The
> algorithm is base on Joshua Bloch's Effective Java. The existing test
> cases are not harmed and apologize my self not writing a specific test
> case. I don't like to call it a patch because it's so stupidly simple,
> but I'd be glad if something like it could be shipped with JSF2 to
> provide this feature.
>
> kind regards,
> Matthias Berndt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help at javaserverfaces.dev.java.net
>
>


-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091113/7c7b7428/attachment.html 


More information about the jsr-314-open-mirror mailing list