Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-08-22 06:21:47
|
SGkgQ29saW4sDQogDQpBYnN0cmFjdEpuZGlMb2NhdG9yIG9ubHkgZG9lcyBzbyB3aGVuIHRoZSAi aW5Db250YWluZXIiIHByb3BlcnR5IGlzIHNldCB0byB0cnVlICh0aGUgZGVmYXVsdCkuIFNldHRp bmcgdGhpcyBwcm9wZXJ0eSB0byBmYWxzZSBzaG91bGQgcmVzdWx0IGluIGxvb2tpbmcgdXAgdGhl IEpOREkgbmFtZSBhcyBpcy4gSXQgY291bGQgbWFrZSBzZW5zZSB0byBhZGQgYSBjaGVjayBmb3Ig c2NoZW1lIHRob3VnaCwgZS5nLiBvbmx5IGFwcGx5ICJqYXZhOmNvbXAvZW52LyIgaWYgImluQ29u dGFpbmVyIiBpcyB0cnVlICphbmQqIHRoZSBKTkRJIG5hbWUgZG9lcyBub3QgY29udGFpbiBhICI6 Ii4gV2hhdCBkbyB5b3UgdGhpbms/DQogDQpKdWVyZ2VuDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xp Y2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogQ29saW4gU2FtcGFsZWFudSBbbWFpbHRvOmNvbGlu bWwxQGV4aXMuY29tXSANCglHZXNlbmRldDogRnIgMjIuMDguMjAwMyAwNTo0MyANCglBbjogc3By aW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0KCUJl dHJlZmY6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBBYnN0cmFjdEpuZGlMb2NhdG9yIHNo b3VsZCBub3QgYXNzdW1lIGphdmE6Y29tcC9lbnYgcHJlZml4IHdoaWxlIG5vdCBhbGxvd2luZyBv dGhlcnMNCgkNCgkNCg0KCUFic3RyYWN0Sm5kaUxvY2F0b3IgcmlnaHQgbm93IGxvb2tzIGF0IHRo ZSBqbmRpIG5hbWUgaXQgaXMgZ2l2ZW4sIGFuZCBpZg0KCWl0IGRvZXNuJ3Qgc3RhcnQgd2l0aA0K CSAgIGphdmE6Y29tcC9lbnYNCglwcmVwZW5kcyB0aGlzIHZhbHVlIGF1dG9tYXRpY2FsbHkuIFRo aXMgYmVoYXZpb3VyIGlzIG5vdCBjb3JyZWN0Lg0KCVNvbWVib2R5IHVzaW5nIHRoZSBiZWFuIHNo b3VsZCBiZSBhYmxlIHRvIGxvb2sgdXAgcmVzb3VyY2VzIGFueXdoZXJlLA0KCWFuZCBjdXJyZW50 bHkgeW91IGNhbid0LiBGb3IgZXhhbXBsZSwgaW4gamJvc3MsIHRoZSBtYWluIGRhdGFzb3VyY2Ug YnkNCglkZWZhdWx0IGlzIGJvdW5kIHRvDQoJICBqYXZhOkRlZmF1bHREUw0KCQ0KCUFzIHdlbGws IHlvdSBtYXkgd2FudCB0byBsb29rIHVwIHNvbWV0aGluZyBvbiBKTkRJIHVzaW5nIGFub3RoZXIg c2NoZW1lDQoJZW50aXJlbHkuLi4NCgkNCglXaGF0IHRoZSBjb2RlIHNob3VsZCBwcm9iYWJseSBk byBpcyBzZWUgaWYgdGhlIGlzIGEgc2NoZW1lDQoJICAgeHh4eHg6DQoJYXQgdGhlIGJlZ2lubmlu ZyBvZiB0aGUgam5kaSBuYW1lLiBJZiB0aGVyZSBpc24ndCwgdGhlbiBpdCBpcyBwcm9iYWJseQ0K CXJlYXNvbmFibGUgdG8gYXNzdW1lICdqYXZhOmNvbXAvZW52LiBvciAnamF2YTonIElmIHRoZXJl IGlzIGEgc2NoZW1lLCBpdA0KCXNob3VsZCBsZWF2ZSB0aGUgbmFtZSBhbG9uZS4NCgkNCglJIHdv dWxkIGhhdmUgc3VwcGxpZWQgYSBwYXRjaCwgYnV0IHRoZSBmaXggaXMgdHJpdmlhbCwgYW5kIEkg ZG9uJ3Qga25vdw0KCWhvdyBleGFjdGx5IHlvdSB3YW50IHRvIGhhbmRsZSB0aGlzLCBidXQgaXQn cyBwcmV0dHkgY3JpdGljYWwgdG8gbWUuDQoJDQoJUmlnaHQgbm93IHdpdGggSkJvc3MgaXQncyBw cmV0dHkgbmFzdHkuIEkgY2FuIG5vdCB1c2UgSkJvc3MncyBuYW1pbmcNCglhbGlhcyBzZXJ2aWNl IHRvIGFsaWFzDQoJICBqYXZhOmNvbXAvZW52L0RlZmF1bHREUw0KCXRvDQoJICBqYXZhOkRlZmF1 bHREUw0KCWJlY2F1c2UgaXQgYXBwYXJlbnRseSBkb2Vzbid0IGxldCB5b3UgYWxpYXMgc3R1ZmYg dW5kZXIgY29tcC9lbnYuICBJIGNhbg0KCXByb2JhYmx5IG1vZGlmeSBteSByZXNvdXJjZSBlbnRy aWVzIGluIHRoZSB3YXIgZmlsZSBJIHVzZSB0byBkbyBhDQoJcmVzb3VyY2UgcmVmIHRvIHRoZSBy aWdodCBsb2NhdGlvbiwgYnV0IEkgd291bGQgcmVhbGx5IHJhdGhlciBub3QgZG8NCgl0aGF0LCBz aW5jZSB0aGUgd2FyIGlzIGZpbmUgdGhlIHdheSBpdCBpcy4NCgkNCglSZWdhcmRzLA0KCUNvbGlu DQoJDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogVk0g V2FyZQ0KCVdpdGggVk13YXJlIHlvdSBjYW4gcnVuIG11bHRpcGxlIG9wZXJhdGluZyBzeXN0ZW1z IG9uIGEgc2luZ2xlIG1hY2hpbmUuDQoJV0lUSE9VVCBSRUJPT1RJTkchIE1peCBMaW51eCAvIFdp bmRvd3MgLyBOb3ZlbGwgdmlydHVhbCBtYWNoaW5lcw0KCWF0IHRoZSBzYW1lIHRpbWUuIEZyZWUg dHJpYWwgY2xpY2sgaGVyZTpodHRwOi8vd3d3LnZtd2FyZS5jb20vd2wvb2ZmZXIvMzU4LzANCglf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNwcmluZ2Zy YW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl ckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9s aXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoNCg== |
|
From: <jue...@we...> - 2003-08-22 14:53:58
|
SnVzdCBmaXhlZDogaW5Db250YWluZXI9dHJ1ZSBkb2VzIG5vdCBwcmVwZW5kIHRoZSBjb250YWlu ZXIgcHJlZml4IGlmIGEgc2NoZW1lIGlzIGdpdmVuIChpLmUuIGEgIjoiIGNvbnRhaW5lZCkuDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENvbGluIFNhbXBhbGVhbnUgW21h aWx0bzpjb2xpbm1sMUBleGlzLmNvbV0NClNlbnQ6IEZyaWRheSwgQXVndXN0IDIyLCAyMDAzIDE6 MzMgUE0NClRvOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdDQpDYzogc3ByaW5nZnJhbWV3b3Jr LWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1YmplY3Q6IFJlOiBbU3ByaW5nZnJh bWV3b3JrLWRldmVsb3Blcl0gQWJzdHJhY3RKbmRpTG9jYXRvciBzaG91bGQgbm90DQphc3N1bWUg amF2YTpjb21wL2VudiBwcmVmaXggd2hpbGUgbm90IGFsbG93aW5nIG90aGVycw0KDQoNCkkgc29t ZWhvdyBtaXNzZWQgdGhlIGluQ29udGFpbmVyIHByb3BlcnR5LCBldmVuIHRob3VnaCBJIGxvb2tl ZCBhdCB0aGUgDQpzb3VyY2UhICAgSSB0aGluayBpdCBkb2VzIG1ha2Ugc2Vuc2UgdGhvdWdoIHRv IGFkZCB0aGUgY2hlY2sgZm9yIHRoZSANCnNjaGVtZSBhcyBwZXIgeW91ciBhbmQgbWluZSBzdWdn ZXN0aW9uOyBldmVuIGluIGEgY29udGFpbmVyIHlvdSBzdGlsbCANCm5lZWQgdG8gYmUgYWJsZSB0 byBvdmVycmlkZSB0aGlzLi4uDQoNClJlZ2FyZHMsDQpDb2xpbg0KDQpqw7xyZ2VuIGjDtmxsZXIg W3dlcmszQVRdIHdyb3RlOg0KDQo+SGkgQ29saW4sDQo+IA0KPkFic3RyYWN0Sm5kaUxvY2F0b3Ig b25seSBkb2VzIHNvIHdoZW4gdGhlICJpbkNvbnRhaW5lciIgcHJvcGVydHkgaXMgc2V0IHRvIHRy dWUgKHRoZSBkZWZhdWx0KS4gU2V0dGluZyB0aGlzIHByb3BlcnR5IHRvIGZhbHNlIHNob3VsZCBy ZXN1bHQgaW4gbG9va2luZyB1cCB0aGUgSk5ESSBuYW1lIGFzIGlzLiBJdCBjb3VsZCBtYWtlIHNl bnNlIHRvIGFkZCBhIGNoZWNrIGZvciBzY2hlbWUgdGhvdWdoLCBlLmcuIG9ubHkgYXBwbHkgImph dmE6Y29tcC9lbnYvIiBpZiAiaW5Db250YWluZXIiIGlzIHRydWUgKmFuZCogdGhlIEpOREkgbmFt ZSBkb2VzIG5vdCBjb250YWluIGEgIjoiLiBXaGF0IGRvIHlvdSB0aGluaz8NCj4gDQo+SnVlcmdl bg0KPiANCj4NCj4JLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCj4JVm9uOiBD b2xpbiBTYW1wYWxlYW51IFttYWlsdG86Y29saW5tbDFAZXhpcy5jb21dIA0KPglHZXNlbmRldDog RnIgMjIuMDguMjAwMyAwNTo0MyANCj4JQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlz dHMuc291cmNlZm9yZ2UubmV0IA0KPglDYzogDQo+CUJldHJlZmY6IFtTcHJpbmdmcmFtZXdvcmst ZGV2ZWxvcGVyXSBBYnN0cmFjdEpuZGlMb2NhdG9yIHNob3VsZCBub3QgYXNzdW1lIGphdmE6Y29t cC9lbnYgcHJlZml4IHdoaWxlIG5vdCBhbGxvd2luZyBvdGhlcnMNCj4JDQo+CQ0KPg0KPglBYnN0 cmFjdEpuZGlMb2NhdG9yIHJpZ2h0IG5vdyBsb29rcyBhdCB0aGUgam5kaSBuYW1lIGl0IGlzIGdp dmVuLCBhbmQgaWYNCj4JaXQgZG9lc24ndCBzdGFydCB3aXRoDQo+CSAgIGphdmE6Y29tcC9lbnYN Cj4JcHJlcGVuZHMgdGhpcyB2YWx1ZSBhdXRvbWF0aWNhbGx5LiBUaGlzIGJlaGF2aW91ciBpcyBu b3QgY29ycmVjdC4NCj4JU29tZWJvZHkgdXNpbmcgdGhlIGJlYW4gc2hvdWxkIGJlIGFibGUgdG8g bG9vayB1cCByZXNvdXJjZXMgYW55d2hlcmUsDQo+CWFuZCBjdXJyZW50bHkgeW91IGNhbid0LiBG b3IgZXhhbXBsZSwgaW4gamJvc3MsIHRoZSBtYWluIGRhdGFzb3VyY2UgYnkNCj4JZGVmYXVsdCBp cyBib3VuZCB0bw0KPgkgIGphdmE6RGVmYXVsdERTDQo+CQ0KPglBcyB3ZWxsLCB5b3UgbWF5IHdh bnQgdG8gbG9vayB1cCBzb21ldGhpbmcgb24gSk5ESSB1c2luZyBhbm90aGVyIHNjaGVtZQ0KPgll bnRpcmVseS4uLg0KPgkNCj4JV2hhdCB0aGUgY29kZSBzaG91bGQgcHJvYmFibHkgZG8gaXMgc2Vl IGlmIHRoZSBpcyBhIHNjaGVtZQ0KPgkgICB4eHh4eDoNCj4JYXQgdGhlIGJlZ2lubmluZyBvZiB0 aGUgam5kaSBuYW1lLiBJZiB0aGVyZSBpc24ndCwgdGhlbiBpdCBpcyBwcm9iYWJseQ0KPglyZWFz b25hYmxlIHRvIGFzc3VtZSAnamF2YTpjb21wL2Vudi4gb3IgJ2phdmE6JyBJZiB0aGVyZSBpcyBh IHNjaGVtZSwgaXQNCj4Jc2hvdWxkIGxlYXZlIHRoZSBuYW1lIGFsb25lLg0KPgkNCj4JSSB3b3Vs ZCBoYXZlIHN1cHBsaWVkIGEgcGF0Y2gsIGJ1dCB0aGUgZml4IGlzIHRyaXZpYWwsIGFuZCBJIGRv bid0IGtub3cNCj4JaG93IGV4YWN0bHkgeW91IHdhbnQgdG8gaGFuZGxlIHRoaXMsIGJ1dCBpdCdz IHByZXR0eSBjcml0aWNhbCB0byBtZS4NCj4JDQo+CVJpZ2h0IG5vdyB3aXRoIEpCb3NzIGl0J3Mg cHJldHR5IG5hc3R5LiBJIGNhbiBub3QgdXNlIEpCb3NzJ3MgbmFtaW5nDQo+CWFsaWFzIHNlcnZp Y2UgdG8gYWxpYXMNCj4JICBqYXZhOmNvbXAvZW52L0RlZmF1bHREUw0KPgl0bw0KPgkgIGphdmE6 RGVmYXVsdERTDQo+CWJlY2F1c2UgaXQgYXBwYXJlbnRseSBkb2Vzbid0IGxldCB5b3UgYWxpYXMg c3R1ZmYgdW5kZXIgY29tcC9lbnYuICBJIGNhbg0KPglwcm9iYWJseSBtb2RpZnkgbXkgcmVzb3Vy Y2UgZW50cmllcyBpbiB0aGUgd2FyIGZpbGUgSSB1c2UgdG8gZG8gYQ0KPglyZXNvdXJjZSByZWYg dG8gdGhlIHJpZ2h0IGxvY2F0aW9uLCBidXQgSSB3b3VsZCByZWFsbHkgcmF0aGVyIG5vdCBkbw0K Pgl0aGF0LCBzaW5jZSB0aGUgd2FyIGlzIGZpbmUgdGhlIHdheSBpdCBpcy4NCj4JDQo+CVJlZ2Fy ZHMsDQo+CUNvbGluDQo+CQ0KPgkNCj4JDQo+CQ0KPgkNCj4JLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPglUaGlzIFNGLm5ldCBlbWFpbCBp cyBzcG9uc29yZWQgYnk6IFZNIFdhcmUNCj4JV2l0aCBWTXdhcmUgeW91IGNhbiBydW4gbXVsdGlw bGUgb3BlcmF0aW5nIHN5c3RlbXMgb24gYSBzaW5nbGUgbWFjaGluZS4NCj4JV0lUSE9VVCBSRUJP T1RJTkchIE1peCBMaW51eCAvIFdpbmRvd3MgLyBOb3ZlbGwgdmlydHVhbCBtYWNoaW5lcw0KPglh dCB0aGUgc2FtZSB0aW1lLiBGcmVlIHRyaWFsIGNsaWNrIGhlcmU6aHR0cDovL3d3dy52bXdhcmUu Y29tL3dsL29mZmVyLzM1OC8wDQo+CV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+CVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQo+ CVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+CWh0dHBz Oi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1k ZXZlbG9wZXINCj4JDQo+DQo+ICANCj4NCg0KDQoNCg== |
|
From: Colin S. <col...@ex...> - 2004-02-15 22:45:42
|
I think we should revisit the decision to make inContainer=true the default for the AbstractJndiLocator. While most people will of course be running in a container, having a default value of inContainer=true will not help them, and will make their config work harder. inContainer=true helps only if by default your code is something like an EJB or WebApp, and you want to save typing 'java:comp/env/' at the beginning of your resource names, _and_ you have gone to the pain of doing a resource mapping to bring resources into the local java:comp/env/ namespace, something that most people don't bother doing. If I deploy an EJB in JBoss for example, it gets deployed into the global (not even 'java:') namspace. Unless I do the resource-ref mapping for the client code that needs to access it, it needs to be accessed via the global namespace. Since there is no prefix at all, that's completely impossible to do unless inContainer=false, otherwise the code will add the java:comp/env/. That means that for every EJB proxy I need to add inContainer=false as a property. If false was the default, then people accessing resources for which there was a local resource mapping (again, people don't usually do this) would still have the choice of either using the full java:/comp/env/ prefix, and leaving inContainer unset, or just setting inContainer=true. I think this change makes sense because locally mapped resources (to java:/comp/env) are less common than non-mapped resources. What do you think? Regards, Colin jürgen höller [werk3AT] wrote: >Just fixed: inContainer=true does not prepend the container prefix if a scheme is given (i.e. a ":" contained). > > >-----Original Message----- >From: Colin Sampaleanu [mailto:col...@ex...] >Sent: Friday, August 22, 2003 1:33 PM >To: jürgen höller [werk3AT] >Cc: spr...@li... >Subject: Re: [Springframework-developer] AbstractJndiLocator should not >assume java:comp/env prefix while not allowing others > > >I somehow missed the inContainer property, even though I looked at the >source! I think it does make sense though to add the check for the >scheme as per your and mine suggestion; even in a container you still >need to be able to override this... > >Regards, >Colin > >jürgen höller [werk3AT] wrote: > > > >>Hi Colin, >> >>AbstractJndiLocator only does so when the "inContainer" property is set to true (the default). Setting this property to false should result in looking up the JNDI name as is. It could make sense to add a check for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is true *and* the JNDI name does not contain a ":". What do you think? >> >>Juergen >> >> >> -----Ursprüngliche Nachricht----- >> Von: Colin Sampaleanu [mailto:col...@ex...] >> Gesendet: Fr 22.08.2003 05:43 >> An: spr...@li... >> Cc: >> Betreff: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others >> >> >> >> AbstractJndiLocator right now looks at the jndi name it is given, and if >> it doesn't start with >> java:comp/env >> prepends this value automatically. This behaviour is not correct. >> Somebody using the bean should be able to look up resources anywhere, >> and currently you can't. For example, in jboss, the main datasource by >> default is bound to >> java:DefaultDS >> >> As well, you may want to look up something on JNDI using another scheme >> entirely... >> >> What the code should probably do is see if the is a scheme >> xxxxx: >> at the beginning of the jndi name. If there isn't, then it is probably >> reasonable to assume 'java:comp/env. or 'java:' If there is a scheme, it >> should leave the name alone. >> >> I would have supplied a patch, but the fix is trivial, and I don't know >> how exactly you want to handle this, but it's pretty critical to me. >> >> Right now with JBoss it's pretty nasty. I can not use JBoss's naming >> alias service to alias >> java:comp/env/DefaultDS >> to >> java:DefaultDS >> because it apparently doesn't let you alias stuff under comp/env. I can >> probably modify my resource entries in the war file I use to do a >> resource ref to the right location, but I would really rather not do >> that, since the war is fine the way it is. >> >> Regards, >> Colin >> >> |
|
From: <jue...@we...> - 2004-02-16 07:34:59
|
Colin, =20 While I generally agree that it's more appropriate to have "inContainer" = default to false, I'm a bit worried that such a change would break all = bean definition files that currently rely on accessing container = DataSources with that implicit prefix. =20 A further option would be to change "inContainer"'s semantics to: check = for "java:comp/env/myJndiName" first, then try "myJndiName" directly if = the former was not found. That would catch both cases, being fully = backward-compatible, with just minimal overhead at startup. = "inContainer" turned off would solely try the latter case. =20 Juergen =20 ________________________________ Von: Colin Sampaleanu [mailto:col...@ex...] Gesendet: So 15.02.2004 23:44 An: j=FCrgen h=F6ller [werk3AT] Cc: spr...@li... Betreff: Re: [Springframework-developer] AbstractJndiLocator should not = assume java:comp/env prefix while not allowing others I think we should revisit the decision to make inContainer=3Dtrue the default for the AbstractJndiLocator. While most people will of course be running in a container, having a default value of inContainer=3Dtrue will not help them, and will make their config work harder. inContainer=3Dtrue helps only if by default = your code is something like an EJB or WebApp, and you want to save typing 'java:comp/env/' at the beginning of your resource names, _and_ you have gone to the pain of doing a resource mapping to bring resources into the local java:comp/env/ namespace, something that most people don't bother doing. If I deploy an EJB in JBoss for example, it gets deployed into the global (not even 'java:') namspace. Unless I do the resource-ref mapping for the client code that needs to access it, it needs to be accessed via the global namespace. Since there is no prefix at all, that's completely impossible to do unless inContainer=3Dfalse, otherwise the code will add the java:comp/env/. That means that for every EJB proxy I need to add inContainer=3Dfalse as a property. If false was the default, then people accessing resources for which there was a local resource mapping (again, people don't usually do this) would still have the choice of either using the full java:/comp/env/ prefix, and leaving inContainer unset, or just setting inContainer=3Dtrue. I think this change makes sense because locally mapped resources (to java:/comp/env) are less common than non-mapped resources. What do you think? Regards, Colin j=FCrgen h=F6ller [werk3AT] wrote: >Just fixed: inContainer=3Dtrue does not prepend the container prefix if = a scheme is given (i.e. a ":" contained). > > >-----Original Message----- >From: Colin Sampaleanu [mailto:col...@ex...] >Sent: Friday, August 22, 2003 1:33 PM >To: j=FCrgen h=F6ller [werk3AT] >Cc: spr...@li... >Subject: Re: [Springframework-developer] AbstractJndiLocator should not >assume java:comp/env prefix while not allowing others > > >I somehow missed the inContainer property, even though I looked at the >source! I think it does make sense though to add the check for the >scheme as per your and mine suggestion; even in a container you still >need to be able to override this... > >Regards, >Colin > >j=FCrgen h=F6ller [werk3AT] wrote: > >=20 > >>Hi Colin, >> >>AbstractJndiLocator only does so when the "inContainer" property is = set to true (the default). Setting this property to false should result = in looking up the JNDI name as is. It could make sense to add a check = for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is = true *and* the JNDI name does not contain a ":". What do you think? >> >>Juergen >> >> >> -----Urspr=FCngliche Nachricht----- >> Von: Colin Sampaleanu [mailto:col...@ex...] >> Gesendet: Fr 22.08.2003 05:43 >> An: spr...@li... >> Cc: >> Betreff: [Springframework-developer] AbstractJndiLocator should = not assume java:comp/env prefix while not allowing others >> =20 >> =20 >> >> AbstractJndiLocator right now looks at the jndi name it is = given, and if >> it doesn't start with >> java:comp/env >> prepends this value automatically. This behaviour is not = correct. >> Somebody using the bean should be able to look up resources = anywhere, >> and currently you can't. For example, in jboss, the main = datasource by >> default is bound to >> java:DefaultDS >> =20 >> As well, you may want to look up something on JNDI using another = scheme >> entirely... >> =20 >> What the code should probably do is see if the is a scheme >> xxxxx: >> at the beginning of the jndi name. If there isn't, then it is = probably >> reasonable to assume 'java:comp/env. or 'java:' If there is a = scheme, it >> should leave the name alone. >> =20 >> I would have supplied a patch, but the fix is trivial, and I = don't know >> how exactly you want to handle this, but it's pretty critical to = me. >> =20 >> Right now with JBoss it's pretty nasty. I can not use JBoss's = naming >> alias service to alias >> java:comp/env/DefaultDS >> to >> java:DefaultDS >> because it apparently doesn't let you alias stuff under = comp/env. I can >> probably modify my resource entries in the war file I use to do = a >> resource ref to the right location, but I would really rather = not do >> that, since the war is fine the way it is. >> =20 >> Regards, >> Colin >> =20 >> |
|
From: Colin S. <col...@ex...> - 2004-02-16 12:45:51
|
What I don't like about checking both locations is that you then end up doing two checks every single time really, for one of the most common cases. I'm also not sure it's that correct to check in two places when you tell it one... It would certainly work though. I'm curious just how much existing usage would break. I don't think it's much of an issue for EJB access. Most people don't map their EJBs to the local namespace. For datasource access, JBoss puts those into 'java:xxxxx', not just 'xxxxx', no choice in the matter, so JBoss users would not be affected at all. It's been a while since I've used WebLogic so I don't remember where WebLogic datasources end up. It's unfortunate that it's this late in the game, since it's pretty clear to me that the best default state for this optimization (default adding of java:comp/env) is best off, if we didn't have the compatibility concern... We could perhaps try to get an idea of how many users actually have configs where they are relying on this. The answer we get back would probably be scalable towards the whole user base.... Colin jürgen höller [werk3AT] wrote: >Colin, > >While I generally agree that it's more appropriate to have "inContainer" default to false, I'm a bit worried that such a change would break all bean definition files that currently rely on accessing container DataSources with that implicit prefix. > >A further option would be to change "inContainer"'s semantics to: check for "java:comp/env/myJndiName" first, then try "myJndiName" directly if the former was not found. That would catch both cases, being fully backward-compatible, with just minimal overhead at startup. "inContainer" turned off would solely try the latter case. > >Juergen > > >________________________________ > >Von: Colin Sampaleanu [mailto:col...@ex...] >Gesendet: So 15.02.2004 23:44 >An: jürgen höller [werk3AT] >Cc: spr...@li... >Betreff: Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others > > > >I think we should revisit the decision to make inContainer=true the >default for the AbstractJndiLocator. > >While most people will of course be running in a container, having a >default value of inContainer=true will not help them, and will make >their config work harder. inContainer=true helps only if by default your >code is something like an EJB or WebApp, and you want to save typing >'java:comp/env/' at the beginning of your resource names, _and_ you have >gone to the pain of doing a resource mapping to bring resources into the >local java:comp/env/ namespace, something that most people don't bother >doing. > >If I deploy an EJB in JBoss for example, it gets deployed into the >global (not even 'java:') namspace. Unless I do the resource-ref mapping >for the client code that needs to access it, it needs to be accessed via >the global namespace. Since there is no prefix at all, that's completely >impossible to do unless inContainer=false, otherwise the code will add >the java:comp/env/. That means that for every EJB proxy I need to add >inContainer=false as a property. > >If false was the default, then people accessing resources for which >there was a local resource mapping (again, people don't usually do this) >would still have the choice of either using the full > java:/comp/env/ >prefix, and leaving inContainer unset, or just setting > inContainer=true. > >I think this change makes sense because locally mapped resources (to >java:/comp/env) are less common than non-mapped resources. What do you >think? > >Regards, >Colin > >jürgen höller [werk3AT] wrote: > > > >>Just fixed: inContainer=true does not prepend the container prefix if a scheme is given (i.e. a ":" contained). >> >> >>-----Original Message----- >>From: Colin Sampaleanu [mailto:col...@ex...] >>Sent: Friday, August 22, 2003 1:33 PM >>To: jürgen höller [werk3AT] >>Cc: spr...@li... >>Subject: Re: [Springframework-developer] AbstractJndiLocator should not >>assume java:comp/env prefix while not allowing others >> >> >>I somehow missed the inContainer property, even though I looked at the >>source! I think it does make sense though to add the check for the >>scheme as per your and mine suggestion; even in a container you still >>need to be able to override this... >> >>Regards, >>Colin >> >>jürgen höller [werk3AT] wrote: >> >> >> >> >> >>>Hi Colin, >>> >>>AbstractJndiLocator only does so when the "inContainer" property is set to true (the default). Setting this property to false should result in looking up the JNDI name as is. It could make sense to add a check for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is true *and* the JNDI name does not contain a ":". What do you think? >>> >>>Juergen >>> >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Colin Sampaleanu [mailto:col...@ex...] >>> Gesendet: Fr 22.08.2003 05:43 >>> An: spr...@li... >>> Cc: >>> Betreff: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others >>> >>> >>> >>> AbstractJndiLocator right now looks at the jndi name it is given, and if >>> it doesn't start with >>> java:comp/env >>> prepends this value automatically. This behaviour is not correct. >>> Somebody using the bean should be able to look up resources anywhere, >>> and currently you can't. For example, in jboss, the main datasource by >>> default is bound to >>> java:DefaultDS >>> >>> As well, you may want to look up something on JNDI using another scheme >>> entirely... >>> >>> What the code should probably do is see if the is a scheme >>> xxxxx: >>> at the beginning of the jndi name. If there isn't, then it is probably >>> reasonable to assume 'java:comp/env. or 'java:' If there is a scheme, it >>> should leave the name alone. >>> >>> I would have supplied a patch, but the fix is trivial, and I don't know >>> how exactly you want to handle this, but it's pretty critical to me. >>> >>> Right now with JBoss it's pretty nasty. I can not use JBoss's naming >>> alias service to alias >>> java:comp/env/DefaultDS >>> to >>> java:DefaultDS >>> because it apparently doesn't let you alias stuff under comp/env. I can >>> probably modify my resource entries in the war file I use to do a >>> resource ref to the right location, but I would really rather not do >>> that, since the war is fine the way it is. >>> >>> Regards, >>> Colin >>> >>> |
|
From: <jue...@we...> - 2004-02-16 13:21:48
|
I agree that such a double check is not too desirable - a bit too much = magic behind the scenes. On second thought, I'm not sure if "inContainer" defaulting to true is = so inappropriate after all. Standard J2EE requires <resource-ref> = declarations in web.xml, expecting "jdbc/myds"-style names relative to = "java:comp/env"; the default AbstractJndiLocator accepts the same name = syntax. I can imagine that quite a few users consider this intuitive - = and I tend to agree... Remember that if you use "xxx:"-style JNDI prefixes, you won't get the = "inContainer" behavior in any case. So I'm not sure how many scenarios = actually require setting "inContainer" to false currently. Even JBoss = JNDI locations for JDBC DataSources (in "-ds.xml" files) are = automatically relative to the "java:" prefix. So is it just about = default EJB locations in JBoss? Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Monday, February 16, 2004 1:44 PM To: spr...@li... Subject: Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others What I don't like about checking both locations is that you then end up=20 doing two checks every single time really, for one of the most common=20 cases. I'm also not sure it's that correct to check in two places when=20 you tell it one... It would certainly work though. I'm curious just how much existing usage would break. I don't think it's = much of an issue for EJB access. Most people don't map their EJBs to the = local namespace. For datasource access, JBoss puts those into=20 'java:xxxxx', not just 'xxxxx', no choice in the matter, so JBoss users=20 would not be affected at all. It's been a while since I've used WebLogic = so I don't remember where WebLogic datasources end up. It's unfortunate that it's this late in the game, since it's pretty=20 clear to me that the best default state for this optimization (default=20 adding of java:comp/env) is best off, if we didn't have the=20 compatibility concern... We could perhaps try to get an idea of how many = users actually have configs where they are relying on this. The answer=20 we get back would probably be scalable towards the whole user base.... Colin j=FCrgen h=F6ller [werk3AT] wrote: >Colin, >=20 >While I generally agree that it's more appropriate to have = "inContainer" default to false, I'm a bit worried that such a change = would break all bean definition files that currently rely on accessing = container DataSources with that implicit prefix. >=20 >A further option would be to change "inContainer"'s semantics to: check = for "java:comp/env/myJndiName" first, then try "myJndiName" directly if = the former was not found. That would catch both cases, being fully = backward-compatible, with just minimal overhead at startup. = "inContainer" turned off would solely try the latter case. >=20 >Juergen >=20 > >________________________________ > >Von: Colin Sampaleanu [mailto:col...@ex...] >Gesendet: So 15.02.2004 23:44 >An: j=FCrgen h=F6ller [werk3AT] >Cc: spr...@li... >Betreff: Re: [Springframework-developer] AbstractJndiLocator should not = assume java:comp/env prefix while not allowing others > > > >I think we should revisit the decision to make inContainer=3Dtrue the >default for the AbstractJndiLocator. > >While most people will of course be running in a container, having a >default value of inContainer=3Dtrue will not help them, and will make >their config work harder. inContainer=3Dtrue helps only if by default = your >code is something like an EJB or WebApp, and you want to save typing >'java:comp/env/' at the beginning of your resource names, _and_ you = have >gone to the pain of doing a resource mapping to bring resources into = the >local java:comp/env/ namespace, something that most people don't bother >doing. > >If I deploy an EJB in JBoss for example, it gets deployed into the >global (not even 'java:') namspace. Unless I do the resource-ref = mapping >for the client code that needs to access it, it needs to be accessed = via >the global namespace. Since there is no prefix at all, that's = completely >impossible to do unless inContainer=3Dfalse, otherwise the code will = add >the java:comp/env/. That means that for every EJB proxy I need to add >inContainer=3Dfalse as a property. > >If false was the default, then people accessing resources for which >there was a local resource mapping (again, people don't usually do = this) >would still have the choice of either using the full > java:/comp/env/ >prefix, and leaving inContainer unset, or just setting > inContainer=3Dtrue. > >I think this change makes sense because locally mapped resources (to >java:/comp/env) are less common than non-mapped resources. What do you >think? > >Regards, >Colin > >j=FCrgen h=F6ller [werk3AT] wrote: > > =20 > >>Just fixed: inContainer=3Dtrue does not prepend the container prefix = if a scheme is given (i.e. a ":" contained). >> >> >>-----Original Message----- >>From: Colin Sampaleanu [mailto:col...@ex...] >>Sent: Friday, August 22, 2003 1:33 PM >>To: j=FCrgen h=F6ller [werk3AT] >>Cc: spr...@li... >>Subject: Re: [Springframework-developer] AbstractJndiLocator should = not >>assume java:comp/env prefix while not allowing others >> >> >>I somehow missed the inContainer property, even though I looked at the >>source! I think it does make sense though to add the check for the >>scheme as per your and mine suggestion; even in a container you still >>need to be able to override this... >> >>Regards, >>Colin >> >>j=FCrgen h=F6ller [werk3AT] wrote: >> >> >> >> =20 >> >>>Hi Colin, >>> >>>AbstractJndiLocator only does so when the "inContainer" property is = set to true (the default). Setting this property to false should result = in looking up the JNDI name as is. It could make sense to add a check = for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is = true *and* the JNDI name does not contain a ":". What do you think? >>> >>>Juergen >>> >>> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Colin Sampaleanu [mailto:col...@ex...] >>> Gesendet: Fr 22.08.2003 05:43 >>> An: spr...@li... >>> Cc: >>> Betreff: [Springframework-developer] AbstractJndiLocator should = not assume java:comp/env prefix while not allowing others >>> =20 >>> =20 >>> >>> AbstractJndiLocator right now looks at the jndi name it is = given, and if >>> it doesn't start with >>> java:comp/env >>> prepends this value automatically. This behaviour is not = correct. >>> Somebody using the bean should be able to look up resources = anywhere, >>> and currently you can't. For example, in jboss, the main = datasource by >>> default is bound to >>> java:DefaultDS >>> =20 >>> As well, you may want to look up something on JNDI using another = scheme >>> entirely... >>> =20 >>> What the code should probably do is see if the is a scheme >>> xxxxx: >>> at the beginning of the jndi name. If there isn't, then it is = probably >>> reasonable to assume 'java:comp/env. or 'java:' If there is a = scheme, it >>> should leave the name alone. >>> =20 >>> I would have supplied a patch, but the fix is trivial, and I = don't know >>> how exactly you want to handle this, but it's pretty critical to = me. >>> =20 >>> Right now with JBoss it's pretty nasty. I can not use JBoss's = naming >>> alias service to alias >>> java:comp/env/DefaultDS >>> to >>> java:DefaultDS >>> because it apparently doesn't let you alias stuff under = comp/env. I can >>> probably modify my resource entries in the war file I use to do = a >>> resource ref to the right location, but I would really rather = not do >>> that, since the war is fine the way it is. >>> =20 >>> Regards, >>> Colin >>> =20 >>> ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-02-17 03:01:01
|
Nobody forces resource-ref declarations on you, lots of people run without them. They are a way to ensure that a particular component can actually be found in a know location as far as another component is concerned, given that the default binding location may be container specific. But for a lot of people it's easier to just configure for the specific location in the app server, instead of setting up all these resource-ref declarations... What I don't like about it is the idea that a default setting is playing around with the path you feed the function, and short of adding the extra property you can't even override it with another path format, wheras the reverse is not true; if the default was off, even without setting the property to on you could still just use the full path to get the local binding. The JBoss JMS queue is also bound without any prefix. I just took a look at an old config of mine from when I was running WebLogic, and my datasources were bound in the global namespace, e.g. jdbc/Certification with no java: prefix. Same deal for the JMS queue, and same for the mail. Probably the thing to do is pose a question on the user list and see how many people are even relying on the inContainer=true auto-prefixing... Regards, Colin jürgen höller [werk3AT] wrote: >I agree that such a double check is not too desirable - a bit too much magic behind the scenes. > >On second thought, I'm not sure if "inContainer" defaulting to true is so inappropriate after all. Standard J2EE requires <resource-ref> declarations in web.xml, expecting "jdbc/myds"-style names relative to "java:comp/env"; the default AbstractJndiLocator accepts the same name syntax. I can imagine that quite a few users consider this intuitive - and I tend to agree... > >Remember that if you use "xxx:"-style JNDI prefixes, you won't get the "inContainer" behavior in any case. So I'm not sure how many scenarios actually require setting "inContainer" to false currently. Even JBoss JNDI locations for JDBC DataSources (in "-ds.xml" files) are automatically relative to the "java:" prefix. So is it just about default EJB locations in JBoss? > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Colin Sampaleanu >Sent: Monday, February 16, 2004 1:44 PM >To: spr...@li... >Subject: Re: [Springframework-developer] AbstractJndiLocator should not >assume java:comp/env prefix while not allowing others > > >What I don't like about checking both locations is that you then end up >doing two checks every single time really, for one of the most common >cases. I'm also not sure it's that correct to check in two places when >you tell it one... It would certainly work though. > >I'm curious just how much existing usage would break. I don't think it's >much of an issue for EJB access. Most people don't map their EJBs to the >local namespace. For datasource access, JBoss puts those into >'java:xxxxx', not just 'xxxxx', no choice in the matter, so JBoss users >would not be affected at all. It's been a while since I've used WebLogic >so I don't remember where WebLogic datasources end up. > >It's unfortunate that it's this late in the game, since it's pretty >clear to me that the best default state for this optimization (default >adding of java:comp/env) is best off, if we didn't have the >compatibility concern... We could perhaps try to get an idea of how many >users actually have configs where they are relying on this. The answer >we get back would probably be scalable towards the whole user base.... > >Colin > >jürgen höller [werk3AT] wrote: > > > >>Colin, >> >>While I generally agree that it's more appropriate to have "inContainer" default to false, I'm a bit worried that such a change would break all bean definition files that currently rely on accessing container DataSources with that implicit prefix. >> >>A further option would be to change "inContainer"'s semantics to: check for "java:comp/env/myJndiName" first, then try "myJndiName" directly if the former was not found. That would catch both cases, being fully backward-compatible, with just minimal overhead at startup. "inContainer" turned off would solely try the latter case. >> >>Juergen >> >> >>________________________________ >> >>Von: Colin Sampaleanu [mailto:col...@ex...] >>Gesendet: So 15.02.2004 23:44 >>An: jürgen höller [werk3AT] >>Cc: spr...@li... >>Betreff: Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others >> >> >> >>I think we should revisit the decision to make inContainer=true the >>default for the AbstractJndiLocator. >> >>While most people will of course be running in a container, having a >>default value of inContainer=true will not help them, and will make >>their config work harder. inContainer=true helps only if by default your >>code is something like an EJB or WebApp, and you want to save typing >>'java:comp/env/' at the beginning of your resource names, _and_ you have >>gone to the pain of doing a resource mapping to bring resources into the >>local java:comp/env/ namespace, something that most people don't bother >>doing. >> >>If I deploy an EJB in JBoss for example, it gets deployed into the >>global (not even 'java:') namspace. Unless I do the resource-ref mapping >>for the client code that needs to access it, it needs to be accessed via >>the global namespace. Since there is no prefix at all, that's completely >>impossible to do unless inContainer=false, otherwise the code will add >>the java:comp/env/. That means that for every EJB proxy I need to add >>inContainer=false as a property. >> >>If false was the default, then people accessing resources for which >>there was a local resource mapping (again, people don't usually do this) >>would still have the choice of either using the full >> java:/comp/env/ >>prefix, and leaving inContainer unset, or just setting >> inContainer=true. >> >>I think this change makes sense because locally mapped resources (to >>java:/comp/env) are less common than non-mapped resources. What do you >>think? >> >>Regards, >>Colin >> >>jürgen höller [werk3AT] wrote: >> >> >> >> >> >>>Just fixed: inContainer=true does not prepend the container prefix if a scheme is given (i.e. a ":" contained). >>> >>> >>>-----Original Message----- >>>From: Colin Sampaleanu [mailto:col...@ex...] >>>Sent: Friday, August 22, 2003 1:33 PM >>>To: jürgen höller [werk3AT] >>>Cc: spr...@li... >>>Subject: Re: [Springframework-developer] AbstractJndiLocator should not >>>assume java:comp/env prefix while not allowing others >>> >>> >>>I somehow missed the inContainer property, even though I looked at the >>>source! I think it does make sense though to add the check for the >>>scheme as per your and mine suggestion; even in a container you still >>>need to be able to override this... >>> >>>Regards, >>>Colin >>> >>>jürgen höller [werk3AT] wrote: >>> >>> >>> >>> >>> >>> >>> >>>>Hi Colin, >>>> >>>>AbstractJndiLocator only does so when the "inContainer" property is set to true (the default). Setting this property to false should result in looking up the JNDI name as is. It could make sense to add a check for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is true *and* the JNDI name does not contain a ":". What do you think? >>>> >>>>Juergen >>>> >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Colin Sampaleanu [mailto:col...@ex...] >>>> Gesendet: Fr 22.08.2003 05:43 >>>> An: spr...@li... >>>> Cc: >>>> Betreff: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others >>>> >>>> >>>> >>>> AbstractJndiLocator right now looks at the jndi name it is given, and if >>>> it doesn't start with >>>> java:comp/env >>>> prepends this value automatically. This behaviour is not correct. >>>> Somebody using the bean should be able to look up resources anywhere, >>>> and currently you can't. For example, in jboss, the main datasource by >>>> default is bound to >>>> java:DefaultDS >>>> >>>> As well, you may want to look up something on JNDI using another scheme >>>> entirely... >>>> >>>> What the code should probably do is see if the is a scheme >>>> xxxxx: >>>> at the beginning of the jndi name. If there isn't, then it is probably >>>> reasonable to assume 'java:comp/env. or 'java:' If there is a scheme, it >>>> should leave the name alone. >>>> >>>> I would have supplied a patch, but the fix is trivial, and I don't know >>>> how exactly you want to handle this, but it's pretty critical to me. >>>> >>>> Right now with JBoss it's pretty nasty. I can not use JBoss's naming >>>> alias service to alias >>>> java:comp/env/DefaultDS >>>> to >>>> java:DefaultDS >>>> because it apparently doesn't let you alias stuff under comp/env. I can >>>> probably modify my resource entries in the war file I use to do a >>>> resource ref to the right location, but I would really rather not do >>>> that, since the war is fine the way it is. >>>> >>>> Regards, >>>> Colin >>>> >>>> >>>> >>>> |
|
From: Colin S. <col...@ex...> - 2003-08-22 11:33:34
|
I somehow missed the inContainer property, even though I looked at the source! I think it does make sense though to add the check for the scheme as per your and mine suggestion; even in a container you still need to be able to override this... Regards, Colin jürgen höller [werk3AT] wrote: >Hi Colin, > >AbstractJndiLocator only does so when the "inContainer" property is set to true (the default). Setting this property to false should result in looking up the JNDI name as is. It could make sense to add a check for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is true *and* the JNDI name does not contain a ":". What do you think? > >Juergen > > > -----Ursprüngliche Nachricht----- > Von: Colin Sampaleanu [mailto:col...@ex...] > Gesendet: Fr 22.08.2003 05:43 > An: spr...@li... > Cc: > Betreff: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others > > > > AbstractJndiLocator right now looks at the jndi name it is given, and if > it doesn't start with > java:comp/env > prepends this value automatically. This behaviour is not correct. > Somebody using the bean should be able to look up resources anywhere, > and currently you can't. For example, in jboss, the main datasource by > default is bound to > java:DefaultDS > > As well, you may want to look up something on JNDI using another scheme > entirely... > > What the code should probably do is see if the is a scheme > xxxxx: > at the beginning of the jndi name. If there isn't, then it is probably > reasonable to assume 'java:comp/env. or 'java:' If there is a scheme, it > should leave the name alone. > > I would have supplied a patch, but the fix is trivial, and I don't know > how exactly you want to handle this, but it's pretty critical to me. > > Right now with JBoss it's pretty nasty. I can not use JBoss's naming > alias service to alias > java:comp/env/DefaultDS > to > java:DefaultDS > because it apparently doesn't let you alias stuff under comp/env. I can > probably modify my resource entries in the war file I use to do a > resource ref to the right location, but I would really rather not do > that, since the war is fine the way it is. > > Regards, > Colin > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines > at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |
