[Design the new POJO MicroContainer] - Re: java.util.logging Bridge Component
by david.lloyd@jboss.com
Ah, nice.
On the conflict problem - surely having proper classloader isolation will mitigate that a lot? I mean if we do this right then it won't matter whether the backend framework is log4j or j.u.l or some other thing. I guess the following points would be most important:
1) Apps and components which use any of JUL, log4j, clogging, slf4j, etc should all have their output going to the same log system in the end
1a) log4j emulation API? (#3 above)
2) Whatever framework we use (if it is other than JUL) should be hidden (classloader-wise) from the application
3) We should support old log4j.xml deployments (#2 above)
4) It would save a lot of work if we could provide a way to use log4j formatters and appenders in any case (also #2 above)
>From the perspective of #1/1a and #2, I don't think it matters at all (to the user) what framework we ultimately choose. I just think it's important to remember that there are two aspects of a logging framework - the backend logger structure and the user logging API. And every project on the planet is likely to use a different user logging API, so we should be prepared to accommodate that. We just need to make sure that our backend logger supports everything the users want (formats, appenders, filtering, so-called MDC, i18n, etc).
I just hate that feeling of rewriting something that already works. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188609#4188609
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188609
17 years, 5 months
[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149
by anil.saldhana@jboss.com
IRC with DML.
| (02:18:46 PM) asaldhan: ping
| (02:18:54 PM) dmlloyd: hey
| (02:19:03 PM) dmlloyd: writing the test now :)
| (02:19:11 PM) asaldhan: :) thx for that
| (02:19:25 PM) asaldhan: how to inject the stub handlers into the bootstrap. can we do it via endorsed?
| (02:19:35 PM) dmlloyd: easy, just add them to main.jar
| (02:19:48 PM) dmlloyd: don't need endorsed at all
| (02:19:54 PM) dmlloyd: we'll need to set a system property too
| (02:20:18 PM) dmlloyd: but that's better than rewriting VFS at the last minute :) if it works anyway
| (02:20:20 PM) asaldhan: u mean the pkgs sys property. right?
| (02:20:58 PM) dmlloyd: yeah java.protocol.handler.pkgs
| (02:21:04 PM) asaldhan: currently I think one of the vfs beans does the system.setprop(pkgs)
| (02:21:09 PM) asaldhan: not done in the command line
| (02:21:33 PM) dmlloyd: yeah, I think that's not the right approach - we should be using a URLStreamHandlerFactory instead
| (02:21:44 PM) dmlloyd: once the container is bootstrapped I mean
| (02:21:51 PM) asaldhan: right.
| (02:22:18 PM) dmlloyd: I guess as a temp hack we could just plug in a URLStreamHandlerFactory that always returns null which will just effectively clear the cache
| (02:22:26 PM) dmlloyd: then reset the sys property...
| (02:22:39 PM) dmlloyd: I'd be a lot less sure of that working though
| (02:24:28 PM) asaldhan: give it a shot with various jdk implementations.
| (02:26:33 PM) dmlloyd: ok, well it definitely works on sun jdk (of course)
| (02:26:39 PM) dmlloyd: next: apple...
| (02:26:54 PM) asaldhan: jrockit is quite close to sun
| (02:27:03 PM) asaldhan: so check with ibm if possible
| (02:27:26 PM) dmlloyd: yeah I just downloaded IBM this morning
| (02:31:35 PM) dmlloyd: works on apple...
| (02:31:37 PM) dmlloyd: next IBM
| (02:31:44 PM) asaldhan: good.
| (02:38:16 PM) dmlloyd: works in IBM
| (02:38:22 PM) dmlloyd: I don't have jrockit handy
| (02:38:23 PM) asaldhan: sweet
| (02:39:14 PM) dmlloyd: it's just a simple class, let me put it in a pastebin
| (02:39:28 PM) asaldhan: do put it on the dev forum man
| (02:39:31 PM) asaldhan: forget paste bin
| (02:39:41 PM) asaldhan: just put it in the thread.
| (02:40:54 PM) asaldhan: I peeked at the source of URL class and can see what u preach
| (02:41:01 PM) asaldhan: handlers.clear()
| (02:41:11 PM) dmlloyd: done
| (02:41:43 PM) dmlloyd: yeah, I think it's all implied in the javadoc for URL.setStreamHandlerFactory()
| (02:43:26 PM) asaldhan: yeah. Let me give this a shot.
| (02:51:08 PM) asaldhan: dml
| (02:51:17 PM) asaldhan: let me understand this:
| (02:51:40 PM) asaldhan: we call this setSHF method at most ONCE
| (02:51:43 PM) dmlloyd: right
| (02:51:47 PM) asaldhan: so we install this factory.
| (02:51:53 PM) asaldhan: which clears the handlers.
| (02:52:14 PM) dmlloyd: yes
| (02:52:22 PM) asaldhan: after that. we install the handlers?
| (02:52:37 PM) dmlloyd: once it's installed, we could do it one of two or three ways
| (02:53:29 PM) dmlloyd: (1) the handler could just be a dummy that always returns null - this will cause the default mechanism to be used. But if we do it this way, we'd have to change the value of the java.protocol.handler.pkgs property first (and I"m not 100% sure it won't just reuse the old cached ones in some cases - seems iffy to me)
| (02:54:14 PM) dmlloyd: (2) we could install a handler that emulates the existing URL resolution behavior by looking up the classes by package name, taking into account the *real* VFS url handlers
| (02:55:16 PM) dmlloyd: (3) we could design a URL handler loader POJO component which specifies an API for in-container URL handlers (most flexible but requires a new API for URLStreamHandlers - not a big deal but more work than (2))
| (02:55:33 PM) dmlloyd: the safest & easiest would be (2) imo
| (02:56:19 PM) dmlloyd: the URLSHF should be installed at the time when the MC would ordinarily set the "java.protocol.handler.pkgs" sys property
| (02:56:35 PM) asaldhan: yeah, we can make this the first bean
| (02:57:28 PM) asaldhan: if we have installed a SM, then the setSHF call go through the sm check, which means we have read the policy file (and the vfs entries thrown out)
| (02:57:40 PM) dmlloyd: yes and no
| (02:57:46 PM) dmlloyd: the vfs entries won't be thrown out
| (02:57:52 PM) dmlloyd: that's the beauty of the whole idea :)
| (02:58:05 PM) asaldhan: will give it a shot.
| (02:58:27 PM) asaldhan: explain why the entries will not be thrown out
| (02:58:34 PM) dmlloyd: why would they be?
| (02:58:59 PM) asaldhan: because we have not installed the handlers
| (02:59:06 PM) dmlloyd: the handlers don't need to be there
| (02:59:15 PM) dmlloyd: the policy never uses them when loading the file
| (02:59:18 PM) dmlloyd: it just checks that it's there
| (02:59:33 PM) asaldhan: can I paste this chat into the forums?
| (02:59:40 PM) dmlloyd: yeah, I was just going to do that :)
| (02:59:43 PM) asaldhan: for archival purposes.
| (02:59:51 PM) dmlloyd: go ahead
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188603#4188603
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188603
17 years, 5 months
[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149
by david.lloyd@jboss.com
Here's my little test:
import java.net.URL;
| import java.net.URLConnection;
| import java.net.URLStreamHandlerFactory;
| import java.net.URLStreamHandler;
| import java.io.IOException;
|
| public final class Main {
|
| public static void main(String[] args) throws IOException {
| final URL urlOne = new URL("http", "www.google.com", "/");
| final URLConnection conn = urlOne.openConnection();
| final Class<? extends URLConnection> origClass = conn.getClass();
| URL.setURLStreamHandlerFactory(new URLStreamHandlerFactory() {
| public URLStreamHandler createURLStreamHandler(final String protocol) {
| if (protocol.equals("http")) {
| return new URLStreamHandler() {
| @Override
| protected URLConnection openConnection(final URL u) throws IOException {
| return new URLConnection(u) {
| @Override
| public void connect() throws IOException {
| }
| };
| }
| };
| } else {
| return null;
| }
| }
| });
| final URL urlTwo = new URL("http", "www.google.com", "/");
| final URLConnection conn2 = urlTwo.openConnection();
| final Class<? extends URLConnection> newClass = conn2.getClass();
| System.out.println("First: " + origClass.getName() + ", second: " + newClass.getName());
| }
| }
The expected result is that the two classes printed are different, which demonstrates that the cache does not survive the setURLStreamHandlerFactory call.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188601#4188601
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188601
17 years, 5 months