[
http://jira.jboss.com/jira/browse/JBSEAM-2775?page=comments#action_12409263 ]
Norman Richards commented on JBSEAM-2775:
-----------------------------------------
Ok, I've integrated something based on this. I spent a good amount of time
researching how other systems handle namespace to package mapping and thinking about how
we can do something that is reasonable but not confusing. What I checked in allows two
kinds of mappings.
The first, and what I think should be the java:packageName URIs. I found a couple
precedents for using URIs of this form, so I'm quite comfortable with that one.
It's about as clear and as terse as can be.
I've also decided to include the http: URL mappings, but I'm not really happy with
it. It's not as clear what is going on and I really don't think it's very
likely to be a meaningful URL. However, since I'm sure some people will just feel
better with a http URL, I guess it's ok. I'd really like to discourage people
from using this form. I didn't allow in arbitrary non-HTTP schemes. If there's
a reason to allow them, we can add it back in. However, if the user is inventing an
arbitrary URL for their namespaces, why not just use the java URI?
The third consideration was of using a seam: URI. What we proposed here would have been
identical to the java: URI, so I'm not including it now. I think there is a LOT of
merit in creating new seam URIs that look like seam:core, seam:framework, etc... For
example:
<components xmlns="seam:components">
<init xmlns="seam:core" debug="true" />
...
</components>
or
<components xmlns="seam:components" xmlns:core="seam:core>
<core:init debug="true" />
...
</components>
The only problem is that the change would have a big effect on users, and it would be
difficult to support the http namespaces for easier migration. Each XSD is defined for a
single namespace, and so we'd be forcing everyone to do a lot more than just bump
references like components-2.0.xsd to components-2.1.xsd. It would clean up the XML
considerably though, so it's definitely worth considering.
Back to the specific changes here. Let me know if what is checked in meets your needs. I
really tried to trim it back because the use case isn't mapping existing URLs to java
package names. The goal is to allow the user to construct specific new URLs that seam can
understand easily.
package-info.java should be optional:"convention over
configuration"
--------------------------------------------------------------------
Key: JBSEAM-2775
URL:
http://jira.jboss.com/jira/browse/JBSEAM-2775
Project: Seam
Issue Type: Feature Request
Reporter: Eric Jung
Assigned To: Norman Richards
Fix For: 2.1.0.BETA1
Attachments: JBSEAM-2775-v3.diff, JBSEAM-2775.diff, JBSEAM-2775.diff
Currently, package-info.java is required when referring to custom Seam components in
components.xml. However, to further align Seam with the "convention over
configuration" philosophy, this file can be optional by making some assumptions:
1. In the absence of package-info.java , the XML namespace in components.xml for custom
components has a well-defined mapping to a Java package
2. This mapping can be defined as:
a. The XML namespace must be parsable by java.net.URI otherwise automatic mapping is
aborted
a. Protocol (scheme), the www/ subdomain, port, query parameters, anchors (references),
and userInfo are ignored, if present.
b. The top-level domain becomes the root Java package
c. Subdomains become Java packages under the root package, applied in right-to-left
order as specified in the URI.
d. The path, as returned by URI.getPath(), is mapped to further Java packages such that
each path element becomes another Java package appended in left-to-right order
Examples:
http://www.company.com/department/product ==> com.company.department.product
https://company.com/department/product ==> com.company.department.product
ftp://www.company.org/department/product ==> org.company.department.product
abc://company.org/department/product ==> org.company.department.product
company.net/foo/bar/baz ==> net.company.foo.bar.baz
JIRA isn't displaying my last example correctly. See
http://pastebin.mozilla.org/375878 for the last example.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira