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 maintain
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 for
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
tryToLoadClassFromRMICodeBase();
}
Thanks.
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
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
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 programmer
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 not ask if he
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
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 we
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
b/readingax
When does JBoss.org have the meta-model of
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,
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 less
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 descriptors in 4.0, 3.2,
or 3.0. Anybody know
Posting to jboss dev
Juha Lindfors wrote:
Getting the scripts done would be the first step and itself helpful for
most current admins, regardless of the language used in the script.
Once those exist, it should not be a huge step to integrate the scripts
with a new MigrationSubDeployer that
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
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. Anybody know
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
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 versions of
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 distinct tool/step.
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
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
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?
Then one is able to
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.
EJB 2.1
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
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
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
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
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
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
29 matches
Mail list logo
