Install your own java.rmi.server.RMIClassLoaderSpi instance by setting
the "java.rmi.server.RMIClassLoaderSpi" system property to an implementation
of RMIClassLoaderSpi, and you can choose to load classes from the codebase
passed in to loadClass even if there is no security manager. You
can maintai
On 11/10/03 8:18 AM, "Scott M Stark" <[EMAIL PROTECTED]> wrote:
> In order to load the org.jboss.mail.userrepository.MetaInfoImpl
> class from the codebase, you are going to have to catch the
> UndeclaredThrowableException and check the nested type since
> the RMIAdaptor interface does not allow f
In order to load the org.jboss.mail.userrepository.MetaInfoImpl
class from the codebase, you are going to have to catch the
UndeclaredThrowableException and check the nested type since
the RMIAdaptor interface does not allow for ClassNotFoundExceptions.
--
Scott Stark
Chi
On 11/6/03 8:32 PM, "Adrian Brock" <[EMAIL PROTECTED]> wrote:
>
> pseudo rmi code:
>
> try
> {
> return invokeServer()
> }
> catch (ClassNotFoundException e)
> {
> if (System.getSecurityManager() == null)
> throw new "No RMI Security Manager etc.";
> else
> tryToLoadClassFromRMICodeB
I meant an xml doc and the corresponding xsd which allows for all this
blah blah you just wrote here.
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Holger Baxmann wrote:
On Wed, 05 Nov 2003 06:36:33 -0800, Scott M Stark
<[EMAIL PROTECTED
On Fri, 2003-11-07 at 00:19, Andrew C. Oliver wrote:
> >
> > Why don't we start different threads for different issues?
> > This thread start out as discussing making management easier.
> >
> > e.g. Joe Windows Admin wants a GUI Wizard entitled
> > "Configure datasource" preferably one that does
>
> Why don't we start different threads for different issues?
> This thread start out as discussing making management easier.
>
> e.g. Joe Windows Admin wants a GUI Wizard entitled
> "Configure datasource" preferably one that does not ask if he writing
> letter :-)
> How does Joe hates-GUIs prog
On Wed, 05 Nov 2003 06:36:33 -0800, Scott M Stark <[EMAIL PROTECTED]>
wrote:
Give me an example of this meaningful description of an applied security
model
that needs to be mapped into a declarative j2ee security descriptor.
The security of the whole system, where j2ee is only a part of, is les
Give me an example of this meaningful description of an applied security model
that needs to be mapped into a declarative j2ee security descriptor.
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Holger Baxmann @ mac wrote:
...
And, again:
Thanks for pointing me at this :)
I rather think of the special JBoss.org (in my case the
not-JAAS-JavaSecurity, JMX, Service and Adapter parts) metamodel
additions. Maybe sometimes a XSLT of the spec xsd will do the trick
;-)))
thanks
bax
When does JBoss.org have the meta-model of the whol
The problem is not writing the right code or using the right OM. The
problem is applying the right code with a appropriate OM at the right
time to the right understanding, taxonomy and onthology of the USER.
Code doesn't sell, the "right" functionalities at the "right" times
will sell.
Today w
Am 05.11.2003 um 04:07 schrieb Scott M Stark:
Its required for j2ee1.4, but you don't need an xsd to use xsl
to transform and xml document.
... as we all know. But this is only one side of the mirror.
The question is: What if you use XSLT on XSD?
The answer is: You are applying different semantic
Holger Baxmann - bitwind wrote:
Am 05.11.2003 um 02:53 schrieb Juha Lindfors:
On Wed, 5 Nov 2003, Holger Baxmann - bitwind wrote:
Bill Burke wrote:
LETS TAKE THESE DISCUSSIONS TO JBOSS-DEV PLEASE!
Yes, IMO, migration should be a separate distinct tool/step. We
should not be maintaining pas
Explain how xsd is actually the object model in terms of what
the metadata handling code is using. Its directly manipulating
xml instances that conform to the xsd or is there is a binding of
the xsd to a java object model? If there is a binding, then that
is the object model, not the xsd as that is
Its required for j2ee1.4, but you don't need an xsd to use xsl
to transform and xml document.
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Holger Baxmann - bitwind wrote:
When does JBoss.org have the meta-model of the whole stuff defi
Am 05.11.2003 um 03:25 schrieb Adrian Brock:
On Wed, 2003-11-05 at 02:22, Holger Baxmann @ mac wrote:
Am 05.11.2003 um 03:11 schrieb Adrian Brock:
On Wed, 2003-11-05 at 02:08, Holger Baxmann @ mac wrote:
When does JBoss.org have the meta-model of the whole stuff defined
in
XSD and throuw the ugly
Am 05.11.2003 um 03:08 schrieb Adrian Brock:
On Wed, 2003-11-05 at 01:53, Juha Lindfors wrote:
On Wed, 5 Nov 2003, Holger Baxmann - bitwind wrote:
Bill Burke wrote:
LETS TAKE THESE DISCUSSIONS TO JBOSS-DEV PLEASE!
Yes, IMO, migration should be a separate distinct tool/step. We
should not be m
On Wed, 5 Nov 2003, Adrian Brock wrote:
> How does Joe hates-GUIs programmer (i.e. me) maintain that wizard
> and other management interfaces when I add configuration options
> to the jdbc rars or db specifc plugins?
You don't. That's the fundamental problem with a rich GUI ;-)
-- Juha
---
On Wed, 5 Nov 2003, Adrian Brock wrote:
> > >> When does JBoss.org have the meta-model of the whole stuff defined in
> > >> XSD and throuw the ugly DTD's away?
> > >> Then one is able to appy XSLT on the XSD's and all migration things
> > >> belonging to the meta-level are handled by the meta-level
On Wed, 2003-11-05 at 02:22, Holger Baxmann @ mac wrote:
> Am 05.11.2003 um 03:11 schrieb Adrian Brock:
>
> > On Wed, 2003-11-05 at 02:08, Holger Baxmann @ mac wrote:
> When does JBoss.org have the meta-model of the whole stuff defined
> in
> XSD and throuw the ugly DTD's away?
> >
Am 05.11.2003 um 03:11 schrieb Adrian Brock:
On Wed, 2003-11-05 at 02:08, Holger Baxmann @ mac wrote:
When does JBoss.org have the meta-model of the whole stuff defined
in
XSD and throuw the ugly DTD's away?
Then one is able to appy XSLT on the XSD's and all migration things
belonging to the meta
Am 05.11.2003 um 02:53 schrieb Juha Lindfors:
On Wed, 5 Nov 2003, Holger Baxmann - bitwind wrote:
Bill Burke wrote:
LETS TAKE THESE DISCUSSIONS TO JBOSS-DEV PLEASE!
Yes, IMO, migration should be a separate distinct tool/step. We
should not be maintaining past versions of deployment descriptors
On Wed, 2003-11-05 at 02:08, Holger Baxmann @ mac wrote:
> Am 05.11.2003 um 02:53 schrieb Juha Lindfors:
> > On Wed, 5 Nov 2003, Holger Baxmann - bitwind wrote:
> >>> Bill Burke wrote:
> LETS TAKE THESE DISCUSSIONS TO JBOSS-DEV PLEASE!
> Yes, IMO, migration should be a separate distin
On Wed, 2003-11-05 at 01:53, Juha Lindfors wrote:
> On Wed, 5 Nov 2003, Holger Baxmann - bitwind wrote:
> > > Bill Burke wrote:
> > >> LETS TAKE THESE DISCUSSIONS TO JBOSS-DEV PLEASE!
> > >> Yes, IMO, migration should be a separate distinct tool/step. We
> > >> should not be maintaining past v
Am 05.11.2003 um 02:53 schrieb Juha Lindfors:
On Wed, 5 Nov 2003, Holger Baxmann - bitwind wrote:
Bill Burke wrote:
LETS TAKE THESE DISCUSSIONS TO JBOSS-DEV PLEASE!
Yes, IMO, migration should be a separate distinct tool/step. We
should not be maintaining past versions of deployment descriptors
On Wed, 5 Nov 2003, Holger Baxmann - bitwind wrote:
> > Bill Burke wrote:
> >> LETS TAKE THESE DISCUSSIONS TO JBOSS-DEV PLEASE!
> >> Yes, IMO, migration should be a separate distinct tool/step. We
> >> should not be maintaining past versions of deployment descriptors in
> >> 4.0, 3.2, or 3.0.
Am 04.11.2003 um 17:22 schrieb Bill Burke:
Posting to jbosxs-dev. Let's keep it there please!
Bill
Bill Burke wrote:
LETS TAKE THESE DISCUSSIONS TO JBOSS-DEV PLEASE!
Yes, IMO, migration should be a separate distinct tool/step. We
should not be maintaining past versions of deployment descr
27 matches
Mail list logo
