November 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by anil.saldhana＠jboss.com

DML, we install the http://anonsvn.jboss.org/repos/common/common-core/trunk/src/main/java/org... in AbstractServerImpl http://anonsvn.jboss.org/repos/jbossas/trunk/bootstrap/src/main/org/jboss... right in the server bootstrap in Main.java View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188613#4188613 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188613

17 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[Design of JBoss Identity] - Re: SAML Assertions (JBossESB)

by jkurtz.wa＠gmail.com

Anil I was using smooks to go from the Assertion to the model and then would have used it to back to XML again. The Assertion would have mapped to and from model. However, if you think OpenSAML is better, I can use that instead. Its examples are not that organized. so it is a bit more of a challenge. I still want to model the assertion to facilitate the data processing and will check out OpenSAML John View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188607#4188607 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188607

17 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by david.lloyd＠jboss.com

OK, just tested - it works reliably in Sun, Apple, and IBM JDKs. I don't have JRockit handy to test with. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188599#4188599 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188599

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by david.lloyd＠jboss.com

Yeah, I got that. But my point was that by having stub URL handlers at VM startup, we *can* specify VFS URLs in security.policy, and the whole dirty mess can be avoided. Still checking to see if the behavior is consistent across various JVMs though. One hopes that this behavior is verified by the TCK, but there's only one way to find out... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188595#4188595 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188595

17 years, 5 months

1
0
0 / 0

[Design of JBoss Identity] - Re: SAML Assertions (JBossESB)

by anil.saldhana＠jboss.com

"jkurtz.wa(a)gmail.com" wrote : hi | | Will also get that SAML class diagram and smooks program to write an Assertion into a model. Great way to learn! | | John Understand your learning intentions. But I have no idea why you want to do smooks (to go from assertion into a model), why not just use opensaml2 api to construct the assertions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188593#4188593 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188593

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: xml persistent format for attachments

by scott.stark＠jboss.org

We need the option to have a AttachmentSerializer per attachment type, but for our own metadata using jaxb, we should fix the marshalling/unmarshalling so its consistent. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188592#4188592 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188592

17 years, 5 months

1
0
0 / 0

[Design of JBoss Labs] - Feeds not working

by sacha.labourey＠jboss.com

Hello, I've written several recent blog entries and none of them seem to have been picked up by the main jboss.org feed. Any idea why? Also: - when trying to register to the "all content" feed on www.jboss.org, it asks me for a clearspace username+password !?! We need to drop this - why don't we provide an e-mail address to raise issues like those? The link at the bottom of the page refers to these forums instead - but they might be... the broken thing! having an e-mail for those issues seems much simpler to me cheers, sacha View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188589#4188589 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188589

17 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2008