Re: Is resource-ref really needed?
On Wed, Sep 2, 2009 at 1:22 AM, Martin Gainty wrote: > > the fellow who wrote it was writing code for at least 2 other projects > it may have been a case of where he accomplished 75% of what was needed then > some other task got moved to his front burner I hear you, we've all been there a couple of times I think ;) > still it is *unusual* that web.xml resource-ref is'nt read I remember digging up some more of that unusual stuff in the Tomcat source, like the null java:comp/UserTransaction that's inserted by Tomcat into JNDI (might have some use, but the code wasn't clear about this) and several of the Java EE injection annotations that were handled in code but all different ones ended up doing exactly the same thing. Anyway, I have to say that the entire resource-ref element in web.xml has been poorly understood and documented anyway. Just by itself the element doesn't really do anything. The way I now understand this element to work is that it's some sort of hint to the container processing the deployment descriptor that it should go looking for a magical (vendor specific) mapping of the resource name declared by the resource-ref element to some global resource somewhere. E.g. web.xml jdbc/myDs Container now goes looking for a vendor specific mapping file, that resides within the web module (.war) or is at least directly associated with the web module, that contains a mapping of what "jdbc/myDs" should resolve to. So, there might be a separate file myvendor.xml containing: The effect of this line would be that java:comp/jdbc/myDs becomes a link to java:somectx/someDS. Of course, you still have to define java:somectx/someDS somewhere, which happens in yet another vendor specific file, say resources.xml: To me this seems overly silly. If the myvendor.xml file is local to the web module anyway, then the container implementation can just read and process this directly without needing the hint in web.xml that it should process this. In the end, all we want is an entry in JDNI. It's interesting to note that there's an element with the same name (resource-ref) and mostly same attributes in the EJB deployment descriptor. Only there it does make sense, since it has this little extra attribute that the web version lacks: mappedName. mappedName does exactly what this intermediate mapping file in the web container does; linking a local JDNI name to a global JNDI name. The entire idea of declaring a dependency, which the vendor should then magically resolve to a specific intermediate mapping file is just vague and confusing. Maybe I misunderstood, but I think I have spent more time in trying to understand this element than the average programmer does, so I wonder whether this average programmer has any idea of the exact use of this element. As in EJB3, resource-ref should be truly optional; if you want your code to use the global names, don't use it. If you want an extra indirection mechanism for the JNDI names, use it. If you use it, let the mapping of local to global names be specified directly in the resource-ref element and don't require some awkward vendor specific mapping file. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is resource-ref really needed?
On Tue, Sep 1, 2009 at 5:07 AM, Martin Gainty wrote:
> both the entries and web.xml reference
> ContextResource
>
> //WebAnnotationSet.java
> protected static void addResource(Context context, Resource annotation)
> {
>
> //if the annotation is
> DataSource,ConnectionFactory,QueueConnectionFactory,TopicConnectionFactory,Session,URL
> // then reference from applicationContext
> if
> (annotation.type().getCanonicalName().equals("javax.sql.DataSource") ||
>
> annotation.type().getCanonicalName().equals("javax.jms.ConnectionFactory")
> ||
> annotation.type().getCanonicalName()
> .equals("javax.jms.QueueConnectionFactory") ||
> annotation.type().getCanonicalName()
> .equals("javax.jms.TopicConnectionFactory") ||
>
> annotation.type().getCanonicalName().equals("javax.mail.Session") ||
> annotation.type().getCanonicalName().equals("java.net.URL")
> ||
> annotation.type().getCanonicalName()
> .equals("javax.resource.cci.ConnectionFactory") ||
>
> annotation.type().getCanonicalName().equals("org.omg.CORBA_2_3.ORB") ||
>
> annotation.type().getCanonicalName().endsWith("ConnectionFactory")) {
>
> //Construct from annotation input
> ContextResource resource = new ContextResource();
>
> /*The input annotation is used to populate the
> parameters */
>
> resource.setName(annotation.name());
> resource.setType(annotation.type().getCanonicalName());
>
> if (annotation.authenticationType()
> == Resource.AuthenticationType.CONTAINER) {
> resource.setAuth("Container");
> }
> else if (annotation.authenticationType()
> == Resource.AuthenticationType.APPLICATION) {
> resource.setAuth("Application");
> }
> resource.setScope(annotation.shareable() ? "Shareable" :
> "Unshareable");
> resource.setProperty("mappedName", annotation.mappedName());
> resource.setDescription(annotation.description());
>
> //finally add it to ApplicationContext.xml here
> context.getNamingResources().addResource(resource);
>
> ///web.xml
> ///
> web.xml is created here on config init()
> called in ContextConfiguration init()
> protected void init() {
> // Called from StandardContext.init()
>
> if (webDigester == null){
> webDigester = createWebDigester();
> webDigester.getParser();
> }
>
> if (contextDigester == null){
> contextDigester = createContextDigester();
> contextDigester.getParser();
> }
>
> if (log.isDebugEnabled())
> log.debug(sm.getString("contextConfig.init"));
> context.setConfigured(false);
> ok = true;
>
> contextConfig();
>
> try {
> fixDocBase();
> } catch (IOException e) {
> log.error(sm.getString("contextConfig.fixDocBase"), e);
> }
>
> }
>
> Digester.java calls CreateContextDigester
> /**
> * Create (if necessary) and return a Digester configured to process the
> * context configuration descriptor for an application.
> */
> protected Digester createContextDigester() {
> Digester digester = new Digester();
> digester.setValidating(false);
> RuleSet contextRuleSet = new ContextRuleSet("", false);
> digester.addRuleSet(contextRuleSet);
> RuleSet namingRuleSet = new NamingRuleSet("Context/");
> digester.addRuleSet(namingRuleSet);
> return digester;
> }
>
> called in Digester calls addRuleSet
> public void addRuleSet(RuleSet ruleSet) {
>
> String oldNamespaceURI = getRuleNamespaceURI();
> String newNamespaceURI = ruleSet.getNamespaceURI();
> if (log.isDebugEnabled()) {
> if (newNamespaceURI == null) {
> log.debug("addRuleSet() with no namespace URI");
> } else {
> log.debug("addRuleSet() with namespace URI " +
> newNamespaceURI);
> }
> }
> setRuleNamespaceURI(newNamespaceURI);
> ruleSet.addRuleInstances(this);
> setRuleNamespaceURI(oldNamespaceURI);
> }
>
> org.apache.catalina.startup.WebRuleSet.java
> public void addRuleInstances(Digester digester) {
>
> digester.addObjectCreate(prefix + "web-app/resource-ref",
>
> "org.apache.catalina.deploy.ContextResource");
> digester.addRule(prefix + "web-app/resource-ref",
> new SetNextNamingRule("addResource",
> "org.apache.catalina.deploy.ContextResource"));
>
> digester.addCallMethod(prefix + "web-app/resource-ref/description",
> "setDescription", 0);
>
Re: Is resource-ref really needed?
On Tue, Sep 1, 2009 at 5:41 PM, Christopher Schultz wrote: >On 8/31/2009 6:19 PM, Robert Whane wrote: >> Okay, it's optional, so I don't HAVE to use, but if I DO use it, what >> possible advantage does it have? > > Adherence to the Servlet Specification? Which is what I indeed suspected what might be a possible function, but as Martin Gainty has found in Tomcat's source, Tomcat absolutely does not look at the resource-ref element. There's a digester rule defined for it, but that's it. So even if you make a typo in any of the data provided in the resource-ref element, Tomcat won't warn you about it. Maybe the documentation should very clearly state this, i.e. "Note: the resource-ref element is totally ignored by Tomcat. You can provide this element to be compatible with other servlet containers that adhere strictly to the Servlet spec(*) Also note that because Tomcat totally and utterly ignores the element, any faulty data provided by you won't be detected by Tomcat. In other words, your application may run perfectly on Tomcat, but fail on this other servlet container since the errors you made were never detected by Tomcat". - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is resource-ref really needed?
On Mon, Aug 31, 2009 at 1:50 PM, Martin Gainty wrote: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=47769 That's a very good start. Thanks! There is however still one vital piece of information missing in the proposed documentation update. It now clearly states that resource-ref in the web.xml deployment descriptor is optional, but it still doesn't explain what exactly it is that using resource-ref buys me. Okay, it's optional, so I don't HAVE to use, but if I DO use it, what possible advantage does it have? Don't get me wrong, I'm not trying to be clever, just honestly wondering about this. But consider the following analogy. Putting a file called 'nobody-reads-this.txt' in your root directory is obviously optional too. I mean, you -can- put this file there, but if you do that nothing happens. It's a filename I just made up and of course Tomcat doesn't know about it. To me, using resource-ref feels exactly like this. You -can- put this in your web.xml, but as far as I can see nothing changes. Now, maybe, just maybe, it has something to do with compatibility with other servlet containers? I have tried war archives with Jboss, and at least on Jboss resource-ref isn't needed either. DataSources appear in the java: JNDI space, just as in Tomcat. Only the exact location is different, but resource-ref does not seem capable of doing any name aliasing and thus can't be used for that purpose either. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is resource-ref really needed?
On Mon, Aug 31, 2009 at 2:27 AM, Martin Gainty wrote: > you can enter a documentation change to correct either > 1)duplicate behaviour of ApplicationContext.xml by web.xml > > 2)or make the documentation a bit clearer on what is required and what is > optional That's not a bad idea really, but before I feel qualified to make such a proposal I first need to understand it myself ;) > mg>i interpret this as parameter is mandatory Hmmm, now you're talking. IF those attributes on are mandatory, then what on earth is the use of resource-ref? Does Tomcat even look at that element? I guess so, but if resource-ref is completely optional and contains no new information in no possible use-cases, then you could just as well be instructed to put a file called "nobody-reads-this.txt" in your root and enter those values there in free-format, couldn't you? There has to be some use of that resource-ref element. All the Tomcat examples and tutorials instruct you to create this element. Someone really badly wants you to use it, yet it seemingly has not function whatsoever. Something just doesn't add up, or maybe it's just me... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is resource-ref really needed?
Hi, On Mon, Aug 31, 2009 at 1:12 AM, Martin Gainty wrote: > > mandatory: define the attributes in in > applicationContext.xml > OR > optionally define the resource attributes or > in web.xml > > http://proteinbank.vbi.vt.edu/tomcat-docs/config/context.html#Resource%20Definitions Thanks for the reply, I was just looking at the same information here: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Resource%20Definitions But aren't all examples uhm, a bit wrong then? Since they all define those attributes in in context.xml (applicationContext.xml?) as well as in in web.xml. But if I understand correctly you can leave out the attributes auth, description and type from and put just these 3 in in web.xml? If you put all of those in in context.xml then indeed no resource-ref is needed? I still find this a little awkward, even 'authoritative' documentation like this one: http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html uses both resource-ref or resource-env-ref in web.xml but uses the attributes auth and type anyway in context.xml. Only description is consistently only used in web.xml for all examples, but it seems a bit silly to teach developers to create and maintain those entries in web.xml, only for this description element that 99% of the actual code doesn't see nor uses. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Is resource-ref really needed?
Hi, I'm using Tomcat 6.20 and have configured a datasource in META-INF/context.xml, which looks basically like this: For brevity I have removed some attributes, but this is basically my definition. I can now just directly look up this DataSource using JDNI under the java:comp/env/jdbc/mydb name. However according to http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html I need to add a resource-ref element to my web.xml. I didn't do that and it still works. Am I missing something? What's the purpose of resource-ref anyway? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
