[ http://jira.jboss.com/jira/browse/JBSEAM-2775?page=comments#action_12404310 ] Pete Muir commented on JBSEAM-2775: ----------------------------------- Patch? -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2775?page=comments#action_12404462 ] Pete Muir commented on JBSEAM-2775: ----------------------------------- The idea is good, and I would certainly consider applying such a patch. So, just depends on whether I like the implementation ;-) But it's not on our roadmap, so if you want it in, you'll have to write it... -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2775?page=comments#action_12405031 ] Pete Muir commented on JBSEAM-2775: ----------------------------------- Probably some transient problem, try again later... -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2775?page=comments#action_12405190 ] Pete Muir commented on JBSEAM-2775: ----------------------------------- "Originally we thought (or at least I did) that we'd end up with more package-level metadata" Actually, I was thinking about using it to specify default interceptors for the package, though it may be simpler to just scan for @Interceptor, not sure. But there is still no reason why we can't do the standard convention over configuration, and make the file optional with sensible defaults. -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2775?page=all ] Eric Jung updated JBSEAM-2775: ------------------------------ Attachment: JBSEAM-2775.diff Patch to the trunk attached. Self-contained unit tests are commented out at the end of the new class, org.jboss.seam.init.NamespacePackageResolver. Simply uncomment and run the class to execute them. As an integration test, I've deleted org.jboss.seam.example.seampay.package-info.java. and modified the example's components.xml with a new XML namespace. You can run the seampay example to see the new code in action. If you like the patch, let me know, and I'll make another patch for the seam manual describing this new feature. -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2775?page=all ] Eric Jung updated JBSEAM-2775: ------------------------------ Description: 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. was: 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.URL, 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 URL.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

[ http://jira.jboss.com/jira/browse/JBSEAM-2775?page=comments#action_12407382 ] Eric Jung commented on JBSEAM-2775: ----------------------------------- Note: please use the 22kb patch. The 18kb patch is the original which doesn't quite work. -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2775?page=comments#action_12407395 ] Norman Richards commented on JBSEAM-2775: ----------------------------------------- Definitely -- 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

[ 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. -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2775?page=comments#action_12409459 ] Norman Richards commented on JBSEAM-2775: ----------------------------------------- We can worry about docs once the functionality is settled. I'm happy to support default mappings for HTTP URLs, but I think the key here really is to be clear about why the functionality is being introduced. Again, it's not important that we provide mappings for many different kinds of URLs. It's only important that a Seam user can construct a URL that maps clearly to a Java package and that the user would be happy with that URL. I didn't mean to remove the ability to strip WWW from the code. I haven't checked, but I thought that was still there. But, to consider whether this is wise, I am drawn back to considering that a namespace URL should generally be a canonical simple URL. Take "http://jboss.com/products/seam/core" for instance. There really should not be a www in there, even if we might generally consider http://www.jboss.com/ to be the "correct" URL in a web browser. Putting the www in a namespace creates an entirely new namespace, potentially causing problems with XML tools. (the XML namespaces must match EXACTLY) It seems quite reasonable, to me, to instruct users to construct a reasonable URL without the www. Nonetheless, I intended to leave the www stripping in there because in general I don't think it's going to harm anything. I think it's fine for us to have a user use http://company.com/dept/product if they wish. I would prefer they use java:com.company.dept.product, but I can see enough value in the HTTP version that supporting it is reasonable. Trying to do anything fancier than that seems like a waste of time. If you want something fancier that isn't mapped automatically, use @Namespace. Finally, I got rid of some of the validating because it didn't seem to serve a useful purpose. Someone uses an invalid namespace, they'll get warnings and failures either way. Why should we trouble ourselves with a static list of java keywords? I did like the "_" for "-" replacement, as that seems quite reasonable, as do most of the mapping recommendations from sun. (But, if you were class.com, would you really be likely to use _class.com as your java package?) Feel free to continue to submit improvements here. I'm not against further changes, but we do need to justify the features in terms of what we really want users to do with it. -- 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