1:16 a.m.
Hey guys,
javaserverfaces.org and javaserverfaces.com now officially redirect to
http://www.javaserverfaces.org. It's old-school: the JSF Central web app has
a filter that just does a redirect for those two domains. It's good enough
for now, though. Once we're running on a more flexible platform, we can just
point the CNAME record directly at the correct IP.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3
Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
12:24 p.m.
New subject: [jsr-314-open] Maven dependencies on javaserverfaces.org
Wonderful news. Glad that's settled out.
While I'm thinking of it, there's a change that I'd like to see on the
dependencies section at http://www.javaserverfaces.org/download
The dependencies aren't nearly as clearcut as you have listed, sadly.
In particular, they don't work for Tomcat.
For the demos, I used the following code block:
<repositories>
<repository>
<id>java.net.m2</id>
<name>java.net m2 repo</name>
<url>http://download.java.net/maven/2</url>
</repository>
<repository>
<id>glassfish-repo-archive</id>
<name>Nexus repository collection for Glassfish</name>
<url>http://maven.glassfish.org/content/groups/glassfish</url>
</repository>
<repository>
<id>ibiblio.mirrors</id>
<url>http://mirrors.ibiblio.org/pub/mirrors/maven2</url>
</repository>
<repository>
<id>codehaus</id>
<name>codehaus</name>
<url>http://repository.codehaus.org</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.0</version>
<scope>provided</scope>
</dependency>
<!--
Uncomment these dependencies and comment out the one above to use
a simple servlet container instead of a Java EE Application
Server
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>[2.0.1,)</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>[2.0.1,)</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp.jstl</groupId>
<artifactId>jstl-api</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jstl-impl</artifactId>
<version>1.2</version>
</dependency>
-->
</dependencies>
Yeah, Sun's repos are a mess. The complexity is really only needed for
Tomcat/Jetty deployments.
You can find the demo's pom.xml at
https://mojarra.dev.java.net/source/browse/*checkout*/mojarra/trunk/jsf-d...
Jim
On 1/25/10 11:16 PM, Kito Mann wrote:
Hey guys,
javaserverfaces.org <http://javaserverfaces.org> and javaserverfaces.com
<http://javaserverfaces.com> now officially redirect to
http://www.javaserverfaces.org. It's old-school: the JSF Central web app
has a filter that just does a redirect for those two domains. It's good
enough for now, though. Once we're running on a more flexible platform,
we can just point the CNAME record directly at the correct IP.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
twitter: jsfcentral
+1 203-404-4848 x3
Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
6:36 p.m.
New subject: [jsr-314-open] Maven dependencies on javaserverfaces.org
I think I've been able to do JSF 2.0 and Tomcat with the following:
<dependencies>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.0.2</version>
</dependency>
</dependencies>
<repositories>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Repository for Maven</name>
<url>http://download.java.net/maven/2</url>
</repository>
</repositories>
On Jan 26, 2010, at 1:24 PM, Jim Driscoll wrote:
Wonderful news. Glad that's settled out.
While I'm thinking of it, there's a change that I'd like to see on the
dependencies section at http://www.javaserverfaces.org/download
The dependencies aren't nearly as clearcut as you have listed, sadly. In particular,
they don't work for Tomcat.
For the demos, I used the following code block:
<repositories>
<repository>
<id>java.net.m2</id>
<name>java.net m2 repo</name>
<url>http://download.java.net/maven/2</url>
</repository>
<repository>
<id>glassfish-repo-archive</id>
<name>Nexus repository collection for Glassfish</name>
<url>http://maven.glassfish.org/content/groups/glassfish</url>
</repository>
<repository>
<id>ibiblio.mirrors</id>
<url>http://mirrors.ibiblio.org/pub/mirrors/maven2</url>
</repository>
<repository>
<id>codehaus</id>
<name>codehaus</name>
<url>http://repository.codehaus.org</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.0</version>
<scope>provided</scope>
</dependency>
<!--
Uncomment these dependencies and comment out the one above to use
a simple servlet container instead of a Java EE Application Server
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>[2.0.1,)</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>[2.0.1,)</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp.jstl</groupId>
<artifactId>jstl-api</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jstl-impl</artifactId>
<version>1.2</version>
</dependency>
-->
</dependencies>
Yeah, Sun's repos are a mess. The complexity is really only needed for Tomcat/Jetty
deployments.
You can find the demo's pom.xml at
https://mojarra.dev.java.net/source/browse/*checkout*/mojarra/trunk/jsf-d...
Jim
On 1/25/10 11:16 PM, Kito Mann wrote:
> Hey guys,
>
> javaserverfaces.org <http://javaserverfaces.org> and javaserverfaces.com
> <http://javaserverfaces.com> now officially redirect to
> http://www.javaserverfaces.org. It's old-school: the JSF Central web app
> has a filter that just does a redirect for those two domains. It's good
> enough for now, though. Once we're running on a more flexible platform,
> we can just point the CNAME record directly at the correct IP.
> ---
> Kito D. Mann | twitter: kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> twitter: jsfcentral
> +1 203-404-4848 x3
>
> Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
>
12:26 p.m.
New subject: [jsr-314-open] Maven dependencies on javaserverfaces.org
That "Should" be all you need... A friend of mine verified on Tomcat as
well. Perhaps you did something different, Jim?
On Wed, Jan 27, 2010 at 7:36 PM, Neil Griffin <neil.griffin(a)portletfaces.org
wrote:
I think I've been able to do JSF 2.0 and Tomcat with the
following:
<dependencies>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.0.2</version>
</dependency>
</dependencies>
<repositories>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Repository for Maven</name>
<url>http://download.java.net/maven/2</url>
</repository>
</repositories>
On Jan 26, 2010, at 1:24 PM, Jim Driscoll wrote:
> Wonderful news. Glad that's settled out.
>
> While I'm thinking of it, there's a change that I'd like to see on the
dependencies section at http://www.javaserverfaces.org/download
>
> The dependencies aren't nearly as clearcut as you have listed, sadly. In
particular, they don't work for Tomcat.
>
> For the demos, I used the following code block:
>
> <repositories>
> <repository>
> <id>java.net.m2</id>
> <name>java.net m2 repo</name>
> <url>http://download.java.net/maven/2</url>
> </repository>
> <repository>
> <id>glassfish-repo-archive</id>
> <name>Nexus repository collection for Glassfish</name>
> <url>http://maven.glassfish.org/content/groups/glassfish
</url>
> </repository>
> <repository>
> <id>ibiblio.mirrors</id>
> <url>http://mirrors.ibiblio.org/pub/mirrors/maven2</url>
> </repository>
> <repository>
> <id>codehaus</id>
> <name>codehaus</name>
> <url>http://repository.codehaus.org</url>
> </repository>
> </repositories>
>
> <dependencies>
> <dependency>
> <groupId>javax.faces</groupId>
> <artifactId>jsf-api</artifactId>
> <version>2.0</version>
> <scope>provided</scope>
> </dependency>
>
> <!--
> Uncomment these dependencies and comment out the one above to
use
> a simple servlet container instead of a Java EE Application
Server
> <dependency>
> <groupId>com.sun.faces</groupId>
> <artifactId>jsf-api</artifactId>
> <version>[2.0.1,)</version>
> </dependency>
> <dependency>
> <groupId>com.sun.faces</groupId>
> <artifactId>jsf-impl</artifactId>
> <version>[2.0.1,)</version>
> </dependency>
> <dependency>
> <groupId>javax.servlet</groupId>
> <artifactId>servlet-api</artifactId>
> <version>2.5</version>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>javax.servlet.jsp</groupId>
> <artifactId>jsp-api</artifactId>
> <version>2.1</version>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>javax.servlet.jsp.jstl</groupId>
> <artifactId>jstl-api</artifactId>
> <version>1.2</version>
> </dependency>
> <dependency>
> <groupId>org.glassfish.web</groupId>
> <artifactId>jstl-impl</artifactId>
> <version>1.2</version>
> </dependency>
> -->
>
> </dependencies>
>
>
> Yeah, Sun's repos are a mess. The complexity is really only needed for
Tomcat/Jetty deployments.
>
> You can find the demo's pom.xml at
>
https://mojarra.dev.java.net/source/browse/*checkout*/mojarra/trunk/jsf-d...
>
> Jim
>
> On 1/25/10 11:16 PM, Kito Mann wrote:
>> Hey guys,
>>
>> javaserverfaces.org <http://javaserverfaces.org> and
javaserverfaces.com
>> <http://javaserverfaces.com> now officially redirect to
>> http://www.javaserverfaces.org. It's old-school: the JSF Central web
app
>> has a filter that just does a redirect for those two domains. It's good
>> enough for now, though. Once we're running on a more flexible platform,
>> we can just point the CNAME record directly at the correct IP.
>> ---
>> Kito D. Mann | twitter: kito99 | Author, JSF in Action
>> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
consulting
>> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
>> twitter: jsfcentral
>> +1 203-404-4848 x3
>>
>> Sign up for the JSFCentral newsletter:
http://oi.vresp.com/?fid=ac048d0e17
>>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
5:23 p.m.
New subject: [jsr-314-open] Slashes in resource library names?
I have been trying to understand whether the spec allows slashes in
resource library names. For example, is it within the spec to have a
composite component with library name components/util?
It works fine in Mojarra: Place components into
resources/components/util and use a namespace alias
xmlns:util="http://java.sun.com/jsf/composite/components/util
But there is a catch--it won't locate a backing component in the
components.util package.
And per the API docs for Application#createComponent, I have no right to
expect that: "Create a fully qualified Java class name by removing any
file extension from resource-name and let fqcn be library-name + "." +
resource-name".
So, I tried to read the spec for clarification. 3.6.1.4 states: The
occurrence of the string “http://java.sun.com/jsf/composite/” in a
Facelet XML namespace declaration means that *whatever follows that last
“/”* is taken to be the name of a resource library.
"Whatever follows" is pretty clear. In my example, components/util would
be the library name. But is it a legal library name?
2.6.1.3 states "Every character in a resource identifier must be a valid
character suitable for use in a string passed to the constructor
of java.io.File that takes a single String argument."
I don't understand this statement. In Windows, can you make files
containing / symbols? If so, will slashes be treated as directory
separators? What about colons? Will they be drive letters?
Or are we saying it doesn't matter--we just feed the library name into
the File constructor, and whatever happens, happens? Then you could have
a situation where a WAR file works fine on Linux but not on Windows.
Before I file an issue, could one of you tell me whether you intended to
support hierarchical library names (such as components/util), or whether
you envisioned only one level?
Thanks,
Cay
--
Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com
9:13 a.m.
New subject: [jsr-314-open] Slashes in resource library names?
There was a discussion about nested resource library names last year. I
would say to search the archives, but I don't know if that's possible.
Anyway, here was the outcome:
Ed:
> It works fine in Mojarra: Place components into
resources/components/util
> and use a namespace alias
> xmlns:util="http://java.sun.com/jsf/composite/components/util
> But there is a catch--it won't locate a backing
component in the
> components.util package.
> And per the API docs for Application#createComponent, I
have no right to
> expect that: "Create a fully qualified Java class name by removing any file
> extension from resource-name and let fqcn be library-name + "." +
> resource-name".
> So, I tried to read the spec for clarification. 3.6.1.4
states: The
> occurrence of the string “http://java.sun.com/jsf/composite/” in a Facelet
> XML namespace declaration means that *whatever follows that last “/”* is
> taken to be the name of a resource library.
> "Whatever follows" is pretty clear. In my
example, components/util would be
> the library name. But is it a legal library name?
> 2.6.1.3 states "Every character in a resource
identifier must be a valid
> character suitable for use in a string passed to the constructor
> of java.io.File that takes a single String argument."
> I don't understand this statement. In Windows, can you
make files
> containing / symbols? If so, will slashes be treated as directory
> separators? What about colons? Will they be drive letters?
> Or are we saying it doesn't matter--we just feed the
library name into the
> File constructor, and whatever happens, happens? Then you could have a
> situation where a WAR file works fine on Linux but not on Windows.
> Before I file an issue, could one of you tell me whether
you intended to
> support hierarchical library names (such as components/util), or whether you
> envisioned only one level?
> Thanks,
> Cay
> --
> Cay S. Horstmann | http://horstmann.com |
mailto:cay@horstmann.com
Yes, you are correct that the resource naming scheme prevents nested
resource libraries. Nested resource libraries were not on the list of
requirements when we designed this feature back in November of 2007. We
will not accept this requirement change at this point.
Dan:
So the spec needs to at least be clear that it's not permitted and suggest
the alternative. Several people reading it didn't understand what to do in
this case.
IMHO, it's a shame that we can't use the nested structure. Seems like a
pretty obvious convention instead of configuration thing. I don't know how
that got missed in the design process.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3
Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
On Sat, Jan 30, 2010 at 6:23 PM, Cay Horstmann <cay(a)horstmann.com> wrote:
> I have been trying to understand whether the spec allows slashes in
> resource library names. For example, is it within the spec to have a
> composite component with library name components/util?
10:07 a.m.
New subject: [jsr-314-open] Slashes in resource library names?
On 2/1/10 9:13 AM, Kito Mann wrote:
There was a discussion about nested resource library names last year.
I would say to search the archives, but I don't know if that's
possible. Anyway, here was the outcome:
Ed:
Yes, you are correct that the resource naming scheme prevents nested
resource libraries. Nested resource libraries were not on the list of
requirements when we designed this feature back in November of
2007. We
will not accept this requirement change at this point.
Dan:
So the spec needs to at least be clear that it's not permitted and
suggest the alternative. Several people reading it didn't understand
what to do in this case.
IMHO, it's a shame that we can't use the nested structure. Seems like
a pretty obvious convention instead of configuration thing. I don't
know how that got missed in the design process.
It would be interesting to find out
why that was left out. Was it
simply an oversight, or are there technical reasons for disallowing
that? On the surface, it sounds like it would be easy to implement and
support, but I've not thought too deeply on the topic. Maybe that's
something we should fix, if we can, for 2.1.
--
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com
11:23 p.m.
New subject: [jsr-314-open] Slashes in resource library names?
On Mon, Feb 1, 2010 at 11:07 AM, Jason Lee <jason(a)steeplesoft.com> wrote:
On 2/1/10 9:13 AM, Kito Mann wrote:
There was a discussion about nested resource library names last year. I
would say to search the archives, but I don't know if that's possible.
Anyway, here was the outcome:
Ed:
>
> Yes, you are correct that the resource naming scheme prevents nested
> resource libraries. Nested resource libraries were not on the list of
> requirements when we designed this feature back in November of 2007. We
> will not accept this requirement change at this point.
Dan:
So the spec needs to at least be clear that it's not permitted and suggest
the alternative. Several people reading it didn't understand what to do in
this case.
IMHO, it's a shame that we can't use the nested structure. Seems like a
pretty obvious convention instead of configuration thing. I don't know how
that got missed in the design process.
It would be interesting to find out why that was left out. Was it simply
an oversight, or are there technical reasons for disallowing that? On the
surface, it sounds like it would be easy to implement and support, but I've
not thought too deeply on the topic. Maybe that's something we should fix,
if we can, for 2.1.
We never got to the bottom of why this was left out, but I think there was a
general agreement that it should be fixed. Let's discuss when and get an
issue report filed.
Here is the (not-so-pretty) link to the original discussion:
http://archives.java.sun.com/cgi-bin/wa?A1=ind0904&L=JSR-314-OPEN&...
(that reminds me I have some leaning on the JCP PMO to get to).
-Dan
--
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
10:18 a.m.
New subject: [jsr-314-open] Slashes in resource library names?
+1. This should definitely be fixed.
david
2010/2/3 Dan Allen <dan.j.allen(a)gmail.com>
On Mon, Feb 1, 2010 at 11:07 AM, Jason Lee
<jason(a)steeplesoft.com> wrote:
> On 2/1/10 9:13 AM, Kito Mann wrote:
>
> There was a discussion about nested resource library names last year. I
> would say to search the archives, but I don't know if that's possible.
> Anyway, here was the outcome:
>
> Ed:
>>
>
>
>> Yes, you are correct that the resource naming scheme prevents nested
>> resource libraries. Nested resource libraries were not on the list of
>> requirements when we designed this feature back in November of 2007. We
>> will not accept this requirement change at this point.
>
>
> Dan:
>
> So the spec needs to at least be clear that it's not permitted and suggest
> the alternative. Several people reading it didn't understand what to do in
> this case.
>
> IMHO, it's a shame that we can't use the nested structure. Seems like a
> pretty obvious convention instead of configuration thing. I don't know how
> that got missed in the design process.
>
> It would be interesting to find out why that was left out. Was it simply
> an oversight, or are there technical reasons for disallowing that? On the
> surface, it sounds like it would be easy to implement and support, but I've
> not thought too deeply on the topic. Maybe that's something we should fix,
> if we can, for 2.1.
>
We never got to the bottom of why this was left out, but I think there was
a general agreement that it should be fixed. Let's discuss when and get an
issue report filed.
Here is the (not-so-pretty) link to the original discussion:
http://archives.java.sun.com/cgi-bin/wa?A1=ind0904&L=JSR-314-OPEN&...
(that reminds me I have some leaning on the JCP PMO to get to).
-Dan
--
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
11:12 a.m.
New subject: [jsr-314-open] Slashes in resource library names?
Cay, could you organize your comments into a spec issue?
Thx,
-Dan
On Wed, Feb 3, 2010 at 11:18 AM, David Geary <clarity.training(a)gmail.com>wrote:
+1. This should definitely be fixed.
david
2010/2/3 Dan Allen <dan.j.allen(a)gmail.com>
On Mon, Feb 1, 2010 at 11:07 AM, Jason Lee <jason(a)steeplesoft.com> wrote:
>
>> On 2/1/10 9:13 AM, Kito Mann wrote:
>>
>> There was a discussion about nested resource library names last year. I
>> would say to search the archives, but I don't know if that's possible.
>> Anyway, here was the outcome:
>>
>> Ed:
>>>
>>
>>
>>> Yes, you are correct that the resource naming scheme prevents nested
>>> resource libraries. Nested resource libraries were not on the list of
>>> requirements when we designed this feature back in November of 2007. We
>>> will not accept this requirement change at this point.
>>
>>
>> Dan:
>>
>> So the spec needs to at least be clear that it's not permitted and
>> suggest the alternative. Several people reading it didn't understand what to
>> do in this case.
>>
>> IMHO, it's a shame that we can't use the nested structure. Seems like a
>> pretty obvious convention instead of configuration thing. I don't know how
>> that got missed in the design process.
>>
>> It would be interesting to find out why that was left out. Was it simply
>> an oversight, or are there technical reasons for disallowing that? On the
>> surface, it sounds like it would be easy to implement and support, but I've
>> not thought too deeply on the topic. Maybe that's something we should fix,
>> if we can, for 2.1.
>>
>
> We never got to the bottom of why this was left out, but I think there was
> a general agreement that it should be fixed. Let's discuss when and get an
> issue report filed.
>
> Here is the (not-so-pretty) link to the original discussion:
>
>
>
http://archives.java.sun.com/cgi-bin/wa?A1=ind0904&L=JSR-314-OPEN&...
>
> (that reminds me I have some leaning on the JCP PMO to get to).
>
> -Dan
>
> --
> 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
>
--
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
5:10 p.m.
New subject: [jsr-314-open] Slashes in resource library names?
It's at
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=740.
What a mess!
At least it paves the way towards handling hierarchical library names in
the future, should you choose to do so.
On 02/03/2010 09:12 AM, Dan Allen wrote:
Cay, could you organize your comments into a spec issue?
Thx,
-Dan
On Wed, Feb 3, 2010 at 11:18 AM, David Geary <clarity.training(a)gmail.com
<mailto:clarity.training@gmail.com>> wrote:
+1. This should definitely be fixed.
david
2010/2/3 Dan Allen <dan.j.allen(a)gmail.com
<mailto:dan.j.allen@gmail.com>>
On Mon, Feb 1, 2010 at 11:07 AM, Jason Lee
<jason(a)steeplesoft.com <mailto:jason@steeplesoft.com>> wrote:
On 2/1/10 9:13 AM, Kito Mann wrote:
> There was a discussion about nested resource library names
> last year. I would say to search the archives, but I don't
> know if that's possible. Anyway, here was the outcome:
>
> Ed:
>
> Yes, you are correct that the resource naming scheme
> prevents nested
> resource libraries. Nested resource libraries were not
> on the list of
> requirements when we designed this feature back in
> November of 2007. We
> will not accept this requirement change at this point.
>
>
> Dan:
>
> So the spec needs to at least be clear that it's not
> permitted and suggest the alternative. Several people
> reading it didn't understand what to do in this case.
>
> IMHO, it's a shame that we can't use the nested structure.
> Seems like a pretty obvious convention instead of
> configuration thing. I don't know how that got missed in
> the design process.
It would be interesting to find out why that was left out.
Was it simply an oversight, or are there technical reasons
for disallowing that? On the surface, it sounds like it
would be easy to implement and support, but I've not thought
too deeply on the topic. Maybe that's something we should
fix, if we can, for 2.1.
We never got to the bottom of why this was left out, but I think
there was a general agreement that it should be fixed. Let's
discuss when and get an issue report filed.
Here is the (not-so-pretty) link to the original discussion:
http://archives.java.sun.com/cgi-bin/wa?A1=ind0904&L=JSR-314-OPEN&...
<http://archives.java.sun.com/cgi-bin/wa?A1=ind0904&L=JSR-314-OPEN&...
(that reminds me I have some leaning on the JCP PMO to get to).
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinuxcom <http://mojavelinux.com>
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
--
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
--
Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com
5:32 p.m.
New subject: [jsr-314-open] Slashes in resource library names?
Thank Cay.
Let's get it done.
-Dan
On Thu, Feb 4, 2010 at 6:10 PM, Cay Horstmann <cay(a)horstmann.com> wrote:
It's at
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=740.
What a mess!
At least it paves the way towards handling hierarchical library names in
the future, should you choose to do so.
On 02/03/2010 09:12 AM, Dan Allen wrote:
> Cay, could you organize your comments into a spec issue?
>
> Thx,
>
> -Dan
>
> On Wed, Feb 3, 2010 at 11:18 AM, David Geary <clarity.training(a)gmail.com
> <mailto:clarity.training@gmail.com>> wrote:
>
> +1. This should definitely be fixed.
>
>
> david
>
> 2010/2/3 Dan Allen <dan.j.allen(a)gmail.com
> <mailto:dan.j.allen@gmail.com>>
>
>
> On Mon, Feb 1, 2010 at 11:07 AM, Jason Lee
> <jason(a)steeplesoft.com <mailto:jason@steeplesoft.com>> wrote:
>
> On 2/1/10 9:13 AM, Kito Mann wrote:
>
>> There was a discussion about nested resource library names
>> last year. I would say to search the archives, but I don't
>> know if that's possible. Anyway, here was the outcome:
>>
>> Ed:
>>
>> Yes, you are correct that the resource naming scheme
>> prevents nested
>> resource libraries. Nested resource libraries were not
>> on the list of
>> requirements when we designed this feature back in
>> November of 2007. We
>> will not accept this requirement change at this point.
>>
>>
>> Dan:
>>
>> So the spec needs to at least be clear that it's not
>> permitted and suggest the alternative. Several people
>> reading it didn't understand what to do in this case.
>>
>> IMHO, it's a shame that we can't use the nested structure.
>> Seems like a pretty obvious convention instead of
>> configuration thing. I don't know how that got missed in
>> the design process.
>>
> It would be interesting to find out why that was left out.
> Was it simply an oversight, or are there technical reasons
> for disallowing that? On the surface, it sounds like it
> would be easy to implement and support, but I've not thought
> too deeply on the topic. Maybe that's something we should
> fix, if we can, for 2.1.
>
>
> We never got to the bottom of why this was left out, but I think
> there was a general agreement that it should be fixed. Let's
> discuss when and get an issue report filed.
>
> Here is the (not-so-pretty) link to the original discussion:
>
>
>
http://archives.java.sun.com/cgi-bin/wa?A1=ind0904&L=JSR-314-OPEN&...
> <
>
http://archives.java.sun.com/cgi-bin/wa?A1=ind0904&L=JSR-314-OPEN&...
> >
>
> (that reminds me I have some leaning on the JCP PMO to get to).
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinuxcom <http://mojavelinux.com>
>
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
>
>
>
>
>
> --
> 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
>
--
Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com
--
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
3:14 p.m.
Thanks a lot Kito! We really appreciate your efforts. The extra redirects
should help eliminate any confusion that remained over the domain names.
-Dan
On Tue, Jan 26, 2010 at 2:16 AM, Kito Mann <kito.mann(a)virtua.com> wrote:
Hey guys,
javaserverfaces.org and javaserverfaces.com now officially redirect to
http://www.javaserverfaces.org. It's old-school: the JSF Central web app
has a filter that just does a redirect for those two domains. It's good
enough for now, though. Once we're running on a more flexible platform, we
can just point the CNAME record directly at the correct IP.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
twitter: jsfcentral
+1 203-404-4848 x3
Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
--
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
12:03 a.m.
Thanks Kito!
I'm going to keep looking in to the DNS stuff :/ having a hard time finding
what we need. Come to think of it, I believe we went the other direction...
www.ocpsoft.com may forward to http://ocpsoft.com, but I'll have to check
with my partner Derek.
--Lincoln
On Tue, Jan 26, 2010 at 4:14 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Thanks a lot Kito! We really appreciate your efforts. The extra
redirects
should help eliminate any confusion that remained over the domain names.
-Dan
On Tue, Jan 26, 2010 at 2:16 AM, Kito Mann <kito.mann(a)virtua.com> wrote:
> Hey guys,
>
> javaserverfaces.org and javaserverfaces.com now officially redirect to
> http://www.javaserverfaces.org. It's old-school: the JSF Central web app
> has a filter that just does a redirect for those two domains. It's good
> enough for now, though. Once we're running on a more flexible platform, we
> can just point the CNAME record directly at the correct IP.
> ---
> Kito D. Mann | twitter: kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
> consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> twitter: jsfcentral
> +1 203-404-4848 x3
>
> Sign up for the JSFCentral newsletter:
> http://oi.vresp.com/?fid=ac048d0e17
>
>
--
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
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
9:57 a.m.
On Wed, Jan 27, 2010 at 1:03 AM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
Thanks Kito!
I'm going to keep looking in to the DNS stuff :/ having a hard time finding
what we need. Come to think of it, I believe we went the other direction...
www.ocpsoft.com may forward to http://ocpsoft.com, but I'll have to check
with my partner Derek.
No worries. This solution works for now. From what I can tell, the A record
(which is javaserverfaces.org) needs to point to an IP address, which Google
Sites doesn't provide.
--Lincoln
On Tue, Jan 26, 2010 at 4:14 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> Thanks a lot Kito! We really appreciate your efforts. The extra redirects
> should help eliminate any confusion that remained over the domain names.
>
> -Dan
>
>
> On Tue, Jan 26, 2010 at 2:16 AM, Kito Mann <kito.mann(a)virtua.com> wrote:
>
>> Hey guys,
>>
>> javaserverfaces.org and javaserverfaces.com now officially redirect to
>> http://www.javaserverfaces.org. It's old-school: the JSF Central web app
>> has a filter that just does a redirect for those two domains. It's good
>> enough for now, though. Once we're running on a more flexible platform, we
>> can just point the CNAME record directly at the correct IP.
>> ---
>> Kito D. Mann | twitter: kito99 | Author, JSF in Action
>> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>> consulting
>> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
>> twitter: jsfcentral
>> +1 203-404-4848 x3
>>
>> Sign up for the JSFCentral newsletter:
>> http://oi.vresp.com/?fid=ac048d0e17
>>
>>
>
>
> --
> 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
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
5434
days inactive
5443
days old
jsr-314-open-mirror@lists.jboss.org
14 comments
8 participants
participants (8)
-
Cay Horstmann -
Dan Allen -
David Geary -
Jason Lee -
Jim Driscoll -
Kito Mann -
Lincoln Baxter, III -
Neil Griffin