How about the existing
org.jboss.net.protocol.URLStreamHandlerFactory
david jencks
On 2002.05.02 11:12:55 -0400 Dan Christopherson wrote:
> Jung , Dr. Christoph wrote:
> > Hi there,
>
> <snip />
>
> >
> > *Bummer* I�m thinking about that classloading stuff ALL THE TIME. There
>
> > must be something else in Java than classloading. *Sigh*
>
> I have faith that once enough of the JDK has been rewritten for
> classloading to actually work right, we'll find something else ;^})
>
>
> >
> >
> > Now we have a workaround, but we do not want to type new
> > URL("https","localhost",42,"myFile",new
> > com.sun.net.ssl.internal.www.protocol.https.Handler()) and
>
> right. gack.
>
> >
> > depending our code agains jsse.jar instead of simply writing new
> > URL("https://localhost:42/myFile").
> >
> >
> >
> > Has anyone already seen this problem and knows how to resolve it?
> >
> >
> >
> > Should we write and install a JBoss-specific URLStreamHandlerFactory
> in
> > the spine such that we can do the protocol extensions by ourselves and
> > using Thread.currentThread().getContextClassLoader().loadClass()
> > approach once for all modules?
> >
>
> org.jboss.util.URLStreamHandlerFactoryThatLoadsTheDamnClassesRight ?
>
> I'd imagine it'll be needed in other places, too.
>
> -danch
>
>
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We
> supply
> the hardware. You get the recognition. Email Us:
> [EMAIL PROTECTED]
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development