|
From: Guido S. <Gui...@tr...> - 2004-05-12 23:05:28
Attachments:
spring-oracle.jar
|
SGVsbG8NCiANCkF0dGFjaGVkIGEgZmlyc3QgdmVyc2lvbiBvZiBhIHNwZWNpYWwgT3JhY2xlIERh dGFTb3VyY2UgaW1wbGVtZW50YXRpb24gZm9yIHVzaW5nIHRoZSBPcmFjbGUgcHJveHkgY29ubmVj dGlvbiBmZWF0dXJlIGFzIHdlbGwgYXMgdGhlIENsaWVudCBJZGVudGlmaWVyICh0byBtYXAgZ2xv YmFsIGFwcGxpY2F0aW9uIGNvbnRleHRzKS4gSXQgdXNlcyBhbiBPcmFjbGVPQ0lDb25uZWN0aW9u UG9vbCB0byBjcmVhdGUgY29ubmVjdGlvbnMsIGFzIHRoaXMgaXMgdGhlIG9ubHkgY2xhc3Mgc3Vw cG9ydGluZyBwcm94eSBjb25uZWN0aW9ucy4gWW91IGNhbm5vdCBhY2hpZXZlIHRoaXMgdmlhIGEg Im5vcm1hbCIgT3JhY2xlIEpEQkMgZHJpdmVyIGltcGxlbWVudGF0aW9uLg0KIA0KSXQncyBhbiBh bnN3ZXIgdG8gYSBxdWVzdGlvbiBvbiB0aGUgZm9ydW0uIEkndmUganVzdCBoYWNrZWQgdG9nZXRo ZXIgYSBmaXJzdCB2ZXJzaW9uLCBJIHdpbGwgbmVlZCBpdCBsYXRlciBpbiBhIHByb2plY3QgYXMg d2VsbC4gQXMgSSdtIHF1aXRlIG5ldyB0byBTcHJpbmcsIGFueSBmZWVkYmFjayBpcyBhcHByZWNp YXRlZC4NCiANCkknbSB1c2luZyBhIFRocmVhZExvY2FsIChPcmFjbGVPQ0lDb25uZWN0aW9uU3Ry YXRlZ3kpIHRvIHBhc3MgdGhlIHByb3h5IHVzZXIgdG8gdGhlIERhdGFTb3VyY2UuIFRvIGNvbmZv cm0gdG8gU3ByaW5nLCB0aGUgVGhyZWFkTG9jYWwgb2JqZWN0IGlzIG5vdCBpbXBsZW1lbnRlZCBh cyBhIFNpbmdsZXRvbiwgYnV0IGhhcyB0byBiZSBjb25maWd1cmVkIGluIHRoZSBhcHBsaWNhdGlv biBjb250ZXh0IGFzIGEgbm9ybWFsIFBPSk8uDQogDQpJdCB0aGVuIG5lZWRzIHRvIGJlIHBhc3Nl ZCB0byB0aGUgT3JhY2xlT0NJQ29ubmVjdGlvblBvb2xEYXRhU291cmNlIGJ5IGRlcGVuZGVuY3kg aW5qZWN0aW9uLg0KIA0KWW91IGNhbiBjaGVjayB0aGUgdGVzdCBjYXNlcyB0byBzZWUgaXQgd29y ay4gVGhlIG5lY2Vzc2FyeSBkYXRhYmFzZSBzY2hlbWEgY2FuIGJlIGNyZWF0ZWQgdmlhIHRoZSBB bnQgYnVpbGQgZmlsZS4NCiANClNvIGZhciBpdCBoYXMgb25seSBiZWVuIHVzZWQgdmlhIHRoZSBK REJDIERBTyBzdXBwb3J0IG9mIFNwcmluZywgYnV0IEkgdGhpbmsgaXQgc2hvdWxkIGFsc28gd29y ayB3aXRoIEhpYmVybmF0ZS4gSSBoYXZlbid0IHRyaWVkIHlldCBpbiBhbiBBcHBsaWNhdGlvbiBT ZXJ2ZXIgZW52aXJvbm1lbnQgdmlhIEpOREkuDQogDQpHdWlkbw0KDQogDQoNCg== |
|
From: <tho...@tr...> - 2004-05-13 14:32:16
|
Guido, Thanks for taking the time to put this together. From a brief look it looks like an excellent solution. I'm hoping to be able to try it out fairly soon and I would also like to see it tested in an app server environment and with Hibernate. If you or anybody else get a chance to test it further, please keep us posted. Thanks, Thomas Risberg Quoting Guido Schmutz <Gui...@tr...>: > Hello > > Attached a first version of a special Oracle DataSource implementation for > using the Oracle proxy connection feature as well as the Client Identifier > (to map global application contexts). It uses an OracleOCIConnectionPool to > create connections, as this is the only class supporting proxy connections. > You cannot achieve this via a "normal" Oracle JDBC driver implementation. > > It's an answer to a question on the forum. I've just hacked together a first > version, I will need it later in a project as well. As I'm quite new to > Spring, any feedback is appreciated. > > I'm using a ThreadLocal (OracleOCIConnectionStrategy) to pass the proxy user > to the DataSource. To conform to Spring, the ThreadLocal object is not > implemented as a Singleton, but has to be configured in the application > context as a normal POJO. > > It then needs to be passed to the OracleOCIConnectionPoolDataSource by > dependency injection. > > You can check the test cases to see it work. The necessary database schema > can be created via the Ant build file. > > So far it has only been used via the JDBC DAO support of Spring, but I think > it should also work with Hibernate. I haven't tried yet in an Application > Server environment via JNDI. > > Guido > > > > |
|
From: Ben A. <ben...@ac...> - 2004-05-14 01:16:52
|
Hi everyone
I was just wondering why Log4jWebConfigurer includes the
WebUtils.setWebAppRootSystemProperty(servletContext) line. AFAIK, it enables
properties such as ${webapp.root} to be used in log4j.properties. However,
as the JavaDocs explain, it conflicts in some containers (in my case Jetty)
unless an explicit "webAppRootKey" is specified for each webapp in web.xml.
This is a bit of a problem for those of us trying to deploy multiple web
applications in the same container for different clients, as we'd need to
generate a different web.xml for each (just to set the webAppRootKey to
something unique). I've spent a lot of time writing adapters and other
classes so client-specific properties can be held in the application context
and configured via PropertyPlaceholderConfigurer. It would therefore be
unfortunate to have to generate client-specific web.xml files, simply to set
a unique webAppRootKey.
To overcome the above, I've copied Log4jWebConfigurer and
Log4jConfigListener into a new package, simply commenting out the
WebUtils.setWebAppRootSystemProperty line. It seems to work, as I don't use
${webapp.root} in log4j.properties. I was therefore wondering if anyone has
any concerns with me providing a patch that skips over the
WebUtils.setWebAppRootSystemProperty if Log4jConfigListener detects an
initialization parameter named "log4jDoNotCreateWebAppRootSystemProperty"?
Cheers
Ben
|