RE: [JBoss-dev] Nested JMX Service Groups...??!
|
|The MLet class should not need the MBeanServer created before it so
|I think simply changing Main.java
|
|from:
| // Create MBeanServer
| final MBeanServer server = MBeanServerFactory.createMBeanServer();
| ...
| // Create MLet
| MLet mlet = new MLet(urls);
| server.registerMBean(mlet, new
|ObjectName(server.getDefaultDomain(), "service", "MLet"));
|
| // Set MLet as classloader for this app
| Thread.currentThread().setContextClassLoader(mlet);
|
|to this:
| // Create MLet
| MLet mlet = new MLet(urls);
| // Set MLet as classloader for this app
| Thread.currentThread().setContextClassLoader(mlet);
| // Create MBeanServer
| final MBeanServer server = MBeanServerFactory.createMBeanServer();
| server.registerMBean(mlet, new
|ObjectName(server.getDefaultDomain(), "service", "MLet"));
|
|will result in the MBeanServer implementation being loaded by the
|JBoss server
|class loader. The com.sun.management.jmx.MBeanServerImpl class is using
|its ClassLoader to locate classes rather the then context class loader:
|
|/**
| * Gets the class for the specified class name
| */
|private Class findClass(String className)
|throws ClassNotFoundException {
|
|Class theClass = null;
|ClassLoader myLoader = this.getClass().getClassLoader();
|if (myLoader != null) {
|theClass = myLoader.loadClass(className);
|} else {
|theClass = Class.forName(className);
|}
|return theClass;
|}
rgght
the idea of "test the domain *name*" doesn't sound soo bad after all.
The reason is that it is a simple place to define the integration (by
scoping your domain in JBoss's). Therefore JBoss will assume that you are
"JBoss" aware and that your management is in place... working on String will
for sure be safe :)
hehe, I guess the second solution will have its problems too. That is when
you know your codebase is too big, a simple change triggers hell
marc
|
|- Original Message -
|From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
|To: <[EMAIL PROTECTED]>
|Sent: Wednesday, April 11, 2001 7:30 PM
|Subject: RE: [JBoss-dev] Nested JMX Service Groups...??!
|
|
|> Oh-oh,
|>
|> Classloaders. So I happely planned my night to add those two
|lines and go
|> out with friends but then I realized how deep the rabbit hole goes.
|>
|> I was stunned to realize that:
|>
|> server.isInstanceOf(mbeanName,"org.jboss.util.Service") always returns
|> false and here is why.
|>
|> MBeanServerImpl implementation of this method obviously has to load our
|> service class to do type check. It uses classloader that loaded
|> MBeanServerImpl which in our case is AppClassLoader. AppClassLoader in
|> turn can't "see" any of our jboss classes since they were loaded with
|> Mlet.
|>
|> I can't see no way to tell to MBeanServer to use other
|classloader nor did
|> JMX engineers hooked wires for CCLs. So as soon ClassNotFoundException is
|> caught (inside MbeanServer.isInstanceOf) false is returnd :(
|>
|> Feedback?
|>
|> vlada
|>
|>
|> On Wed, 11 Apr 2001, marc fleury wrote:
|>
|> > Bla enough talk, add the f*cking line already
|> >
|> > ||I still don't see anything wrong with type check for
|> > ||org.jboss.util.Service.
|> > ||Vladimir
|> >
|> > "code with your balls on the keyboard"
|> >
|> > ___
|> > Jboss-development mailing list
|> > [EMAIL PROTECTED]
|> > http://lists.sourceforge.net/lists/listinfo/jboss-development
|> >
|>
|>
|> ___
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
User: starksm
Date: 01/04/11 21:50:03
Modified:src/main/org/jboss Tag: Branch_2_2 Main.java
Log:
Drop the unwanted FINAL element of the version string
Revision ChangesPath
No revision
No revision
1.30.2.3 +2 -2 jboss/src/main/org/jboss/Main.java
Index: Main.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v
retrieving revision 1.30.2.2
retrieving revision 1.30.2.3
diff -u -r1.30.2.2 -r1.30.2.3
--- Main.java 2001/04/12 02:29:33 1.30.2.2
+++ Main.java 2001/04/12 04:50:03 1.30.2.3
@@ -32,13 +32,13 @@
* @see
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]">Daniel O'Connor.
- * @version $Revision: 1.30.2.2 $
+ * @version $Revision: 1.30.2.3 $
*/
public class Main
{
// Constants -
- String versionIdentifier = "2.2.1 FINAL";
+ String versionIdentifier = "2.2.1";
// Attributes
// Static
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
Ok, fine by me. - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 11, 2001 9:07 PM Subject: RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java > Again legacy... > > 2.odd 2.even serves the purpose better, so go with that, drop "FINAL"... > > It serves no purpose at this point, > > marc ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
The MLet class should not need the MBeanServer created before it so
I think simply changing Main.java
from:
// Create MBeanServer
final MBeanServer server = MBeanServerFactory.createMBeanServer();
...
// Create MLet
MLet mlet = new MLet(urls);
server.registerMBean(mlet, new ObjectName(server.getDefaultDomain(),
"service", "MLet"));
// Set MLet as classloader for this app
Thread.currentThread().setContextClassLoader(mlet);
to this:
// Create MLet
MLet mlet = new MLet(urls);
// Set MLet as classloader for this app
Thread.currentThread().setContextClassLoader(mlet);
// Create MBeanServer
final MBeanServer server = MBeanServerFactory.createMBeanServer();
server.registerMBean(mlet, new ObjectName(server.getDefaultDomain(),
"service", "MLet"));
will result in the MBeanServer implementation being loaded by the JBoss server
class loader. The com.sun.management.jmx.MBeanServerImpl class is using
its ClassLoader to locate classes rather the then context class loader:
/**
* Gets the class for the specified class name
*/
private Class findClass(String className)
throws ClassNotFoundException {
Class theClass = null;
ClassLoader myLoader = this.getClass().getClassLoader();
if (myLoader != null) {
theClass = myLoader.loadClass(className);
} else {
theClass = Class.forName(className);
}
return theClass;
}
- Original Message -
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 11, 2001 7:30 PM
Subject: RE: [JBoss-dev] Nested JMX Service Groups...??!
> Oh-oh,
>
> Classloaders. So I happely planned my night to add those two lines and go
> out with friends but then I realized how deep the rabbit hole goes.
>
> I was stunned to realize that:
>
> server.isInstanceOf(mbeanName,"org.jboss.util.Service") always returns
> false and here is why.
>
> MBeanServerImpl implementation of this method obviously has to load our
> service class to do type check. It uses classloader that loaded
> MBeanServerImpl which in our case is AppClassLoader. AppClassLoader in
> turn can't "see" any of our jboss classes since they were loaded with
> Mlet.
>
> I can't see no way to tell to MBeanServer to use other classloader nor did
> JMX engineers hooked wires for CCLs. So as soon ClassNotFoundException is
> caught (inside MbeanServer.isInstanceOf) false is returnd :(
>
> Feedback?
>
> vlada
>
>
> On Wed, 11 Apr 2001, marc fleury wrote:
>
> > Bla enough talk, add the f*cking line already
> >
> > ||I still don't see anything wrong with type check for
> > ||org.jboss.util.Service.
> > ||Vladimir
> >
> > "code with your balls on the keyboard"
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
Again legacy... 2.odd 2.even serves the purpose better, so go with that, drop "FINAL"... It serves no purpose at this point, marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Wednesday, April 11, 2001 11:29 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java | | |Can't say that I care either way but that is the convention that has been |in use. | |> What's the purpose of the "FINAL" designation? I assume that it |means that |> this is a stable, tested release, but the word "final" doesn't make sense |> to me. Perhaps it's just me, though. |> |> Toby. |> | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Nested JMX Service Groups...??!
Oh-oh, Classloaders. So I happely planned my night to add those two lines and go out with friends but then I realized how deep the rabbit hole goes. I was stunned to realize that: server.isInstanceOf(mbeanName,"org.jboss.util.Service") always returns false and here is why. MBeanServerImpl implementation of this method obviously has to load our service class to do type check. It uses classloader that loaded MBeanServerImpl which in our case is AppClassLoader. AppClassLoader in turn can't "see" any of our jboss classes since they were loaded with Mlet. I can't see no way to tell to MBeanServer to use other classloader nor did JMX engineers hooked wires for CCLs. So as soon ClassNotFoundException is caught (inside MbeanServer.isInstanceOf) false is returnd :( Feedback? vlada On Wed, 11 Apr 2001, marc fleury wrote: > Bla enough talk, add the f*cking line already > > ||I still don't see anything wrong with type check for > ||org.jboss.util.Service. > ||Vladimir > > "code with your balls on the keyboard" > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
Can't say that I care either way but that is the convention that has been in use. > What's the purpose of the "FINAL" designation? I assume that it means that > this is a stable, tested release, but the word "final" doesn't make sense > to me. Perhaps it's just me, though. > > Toby. > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
It is legacy at this point. We used to run 2.0 BETA and then move to 2.0 FINAL. marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Toby |Allsopp |Sent: Wednesday, April 11, 2001 11:11 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java | | |On Wed, Apr 11, 2001 at 07:29:33PM -0700, |[EMAIL PROTECTED] wrote: |> User: starksm |> Date: 01/04/11 19:29:33 |> |> Modified:src/main/org/jboss Tag: Branch_2_2 Main.java |> Log: |> Update the version string to "2.2.1 FINAL" in prepration for |the release. | |What's the purpose of the "FINAL" designation? I assume that it means that |this is a stable, tested release, but the word "final" doesn't make sense |to me. Perhaps it's just me, though. | |Toby. | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: newsite index.html
ah yeah... I should get back on the news. marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |[EMAIL PROTECTED] |Sent: Wednesday, April 11, 2001 11:02 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] CVS update: newsite index.html | | | User: starksm | Date: 01/04/11 20:02:19 | | Modified:.index.html | Log: | Update latest release to 2.2 | | Revision ChangesPath | 1.9 +2 -2 newsite/index.html | | Index: index.html | === | RCS file: /cvsroot/jboss/newsite/index.html,v | retrieving revision 1.8 | retrieving revision 1.9 | diff -u -r1.8 -r1.9 | --- index.html 2001/04/10 17:35:04 1.8 | +++ index.html 2001/04/12 03:02:19 1.9 | @@ -79,9 +79,9 @@ | | | | - FEBRUARY 26 - MARCH 4 2001: |TRAINING AVAILABLE, JBOSS 2.1 RELEASED | + APRIL 8 - APRIL 14 2001: TRAINING |AVAILABLE, JBOSS 2.2 RELEASED | JBoss Training available |Marc Fleury will be giving classes on JBoss technology. Get your |http://www.jbossgroup.com:999/jbossgroup/training.php">knowle |dge from the source. | - JBoss 2.1 released |Rickard Oberg finds time to package the latest 2.1 version for all |to download. Go check it out here. | + JBoss 2.2 |releasedGo check it out here. | | | | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Object Unique Id Generator
|So lets say this is an "honorable defeat". I will just have to find |something else! :-) It is an "elegant" one at least, something we are not used to... my mistake actually I was the one to ask you to pitch your "servserside" pattern to this list. Thanks for proposing and arguing, maybe next time, |Have fun indeed, marc ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
On Wed, Apr 11, 2001 at 07:29:33PM -0700, [EMAIL PROTECTED] wrote: > User: starksm > Date: 01/04/11 19:29:33 > > Modified:src/main/org/jboss Tag: Branch_2_2 Main.java > Log: > Update the version string to "2.2.1 FINAL" in prepration for the release. What's the purpose of the "FINAL" designation? I assume that it means that this is a stable, tested release, but the word "final" doesn't make sense to me. Perhaps it's just me, though. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS client/ssh
|Cool, I'm vindicated! | |When Simone imparts his knowledge, I'd be happy to |update the web page if Marc thinks it a good idea... To have updated and precise doco on the management of the project? You kiddin' me? marc ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite index.html
User: starksm Date: 01/04/11 20:02:19 Modified:.index.html Log: Update latest release to 2.2 Revision ChangesPath 1.9 +2 -2 newsite/index.html Index: index.html === RCS file: /cvsroot/jboss/newsite/index.html,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- index.html2001/04/10 17:35:04 1.8 +++ index.html2001/04/12 03:02:19 1.9 @@ -79,9 +79,9 @@ - FEBRUARY 26 - MARCH 4 2001: TRAINING AVAILABLE, JBOSS 2.1 RELEASED + APRIL 8 - APRIL 14 2001: TRAINING AVAILABLE, JBOSS 2.2 RELEASED JBoss Training available Marc Fleury will be giving classes on JBoss technology. Get your http://www.jbossgroup.com:999/jbossgroup/training.php">knowledge from the source. - JBoss 2.1 released Rickard Oberg finds time to package the latest 2.1 version for all to download. Go check it out here. + JBoss 2.2 releasedGo check it out here. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Nested JMX Service Groups...??!
Bla enough talk, add the f*cking line already ||I still don't see anything wrong with type check for ||org.jboss.util.Service. ||Vladimir "code with your balls on the keyboard" ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/spi ProxyLoginModule.java UsersRolesLoginModule.java
User: starksm
Date: 01/04/11 19:53:56
Modified:src/main/org/jboss/security/auth/spi
UsersRolesLoginModule.java
Added: src/main/org/jboss/security/auth/spi ProxyLoginModule.java
Log:
Rename org.jboss.security.plugins.ProxyLoginModule
Integrate JaasServerLoginModule fix and missing unit test.
Revision ChangesPath
1.2 +4 -0
jbosssx/src/main/org/jboss/security/auth/spi/UsersRolesLoginModule.java
Index: UsersRolesLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/UsersRolesLoginModule.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- UsersRolesLoginModule.java2001/04/11 02:04:21 1.1
+++ UsersRolesLoginModule.java2001/04/12 02:53:56 1.2
@@ -111,6 +111,7 @@
*/
protected Group[] getRoleSets() throws LoginException
{
+String targetUser = getUsername();
Enumeration users = _roles.propertyNames();
SimpleGroup rolesGroup = new SimpleGroup("Roles");
ArrayList groups = new ArrayList();
@@ -119,6 +120,9 @@
{
String user = (String) users.nextElement();
String value = _roles.getProperty(user);
+if( user.startsWith(targetUser) == false )
+continue;
+
// Check for username.RoleGroup pattern
int index = user.indexOf('.');
if( index > 0 )
1.1
jbosssx/src/main/org/jboss/security/auth/spi/ProxyLoginModule.java
Index: ProxyLoginModule.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.security.auth.spi;
import java.io.IOException;
import java.io.InputStream;
import java.util.Map;
import java.util.Set;
import javax.security.auth.Subject;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.Callback;
import javax.security.auth.login.LoginException;
import javax.security.auth.spi.LoginModule;
/** A proxy LoginModule that loads a delegate LoginModule using
the current thread context class loader. The purpose of this
module is to work around the current JAAS class loader limitation
that requires LoginModules to be on the classpath. Some LoginModules
use core JBoss classes that would have to be moved into the jboss-jaas.jar
and packaging becomes a mess. Instead, these LoginModules are left
in the jbosssx.jar and the ProxyLoginModule is used to bootstrap
the non-classpath LoginModule.
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
public class ProxyLoginModule implements LoginModule
{
private String moduleName;
private LoginModule delegate;
public ProxyLoginModule()
{
}
// --- Begin LoginModule interface methods
/** Initialize this LoginModule. This method loads the LoginModule
specified by the moduleName option using the current thread
context class loader and then delegates the initialize call
to it.
@param options, include:
moduleName: the classname of the module that this proxy module
delegates all calls to.
*/
public void initialize(Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options)
{
moduleName = (String) options.get("moduleName");
if( moduleName == null )
{
System.out.println("Required moduleName option not given");
return;
}
// Load the delegate module using the thread class loader
ClassLoader loader = Thread.currentThread().getContextClassLoader();
try
{
Class clazz = loader.loadClass(moduleName);
delegate = (LoginModule) clazz.newInstance();
}
catch(Throwable t)
{
System.out.println("ProxyLoginModule failed to load: "+moduleName);
t.printStackTrace();
return;
}
delegate.initialize(subject, callbackHandler, sharedState, options);
}
/** Perform the login. If either the moduleName option was not
specified or the module could not be loaded in initalize(),
this method throws a LoginException.
@exception LoginException, throw in the delegate login module failed.
*/
public boolean login() throws LoginException
{
if( moduleName == null )
throw new LoginException("Required moduleName option not given");
if( delegate == null )
throw new LoginException("Failed to load LoginModule: "+moduleName);
return dele
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins AbstractServerLoginModule.java ProxyLoginModule.java
User: starksm
Date: 01/04/11 19:53:57
Modified:src/main/org/jboss/security/plugins
AbstractServerLoginModule.java
ProxyLoginModule.java
Log:
Rename org.jboss.security.plugins.ProxyLoginModule
Integrate JaasServerLoginModule fix and missing unit test.
Revision ChangesPath
1.5 +5 -205
jbosssx/src/main/org/jboss/security/plugins/AbstractServerLoginModule.java
Index: AbstractServerLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/AbstractServerLoginModule.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AbstractServerLoginModule.java2001/03/29 02:28:38 1.4
+++ AbstractServerLoginModule.java2001/04/12 02:53:56 1.5
@@ -4,217 +4,17 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
-
package org.jboss.security.plugins;
-
-import java.util.*;
-import java.io.*;
-
-import java.security.Principal;
-import java.security.acl.Group;
-import javax.security.auth.Subject;
-import javax.security.auth.callback.Callback;
-import javax.security.auth.callback.CallbackHandler;
-import javax.security.auth.callback.NameCallback;
-import javax.security.auth.callback.PasswordCallback;
-import javax.security.auth.callback.UnsupportedCallbackException;
-import javax.security.auth.login.LoginException;
-import javax.security.auth.login.FailedLoginException;
-import javax.security.auth.spi.LoginModule;
-
-import org.jboss.security.NestableGroup;
-import org.jboss.security.SimpleGroup;
-
-/** This class implements the common functionality required for a JAAS
-server side LoginModule and implements the JBossSX standard Subject usage
-pattern of storing identities and roles. Subclass this module to create your
-own custom LoginModule and override the getRoles() and getIdentity()
-methods.
-You may also wish to override
-public void initialize(Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options)
+/** This module has been renamed to
org.jboss.security.auth.spi.AbstractServerLoginModule
-In which case the first line of your initialize() method should be:
-super.initialize(subject, callbackHandler, sharedState, options);
-You may also wish to override
-public boolean login() throws LoginException
-In which case the last line of your login() method should be
-return super.login();
+@deprecated See {@link org.jboss.security.auth.spi.AbstractServerLoginModule }
which has replaced this module.
@author Edward Kenworthy, 12th Dec
2000
@author [EMAIL PROTECTED]
-@version $Revision: 1.4 $
+@version $Revision: 1.5 $
*/
-public abstract class AbstractServerLoginModule implements LoginModule
+public abstract class AbstractServerLoginModule
+ extends org.jboss.security.auth.spi.AbstractServerLoginModule
{
-protected Subject subject;
-protected CallbackHandler callbackHandler;
-protected Map sharedState;
-protected Map options;
-
-/** Flag indicating if the shared credential should be used */
-protected boolean useFirstPass;
-
-//--- Begin LoginModule interface methods
-/** Initialize the login module. This stores the subject, callbackHandler
-and sharedState and options for the login session.
-@param options,
-@option
-@option password-stacking: if true, the login identity will be taken from
the
-javax.security.auth.login.name value of the sharedState map, and
-the proof of identity from the javax.security.auth.login.password
-value sharedState map.
-*/
-public void initialize(Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options)
-{
-this.subject = subject;
-this.callbackHandler = callbackHandler;
-this.sharedState = sharedState;
-this.options = options;
-
-/* Check for password sharing options. Any non-null value for
-password_stacking sets useFirstPass as this module has no way to
-validate any shared password.
- */
-String passwordStacking = (String) options.get("password-stacking");
-if( passwordStacking != null &&
passwordStacking.equalsIgnoreCase("useFirstPass") )
- useFirstPass = true;
-}
-
-/** Looks for javax.security.auth.login.name and
javax.security.auth.login.password
-values in the sharedState map if the useFirstPass option was true and
returns
-true if they exist. If they do not or are null this method returns false.
-*/
-public boolean login() throws LoginException
-{
-// If useFirstPass is true, look for the shared password
-if( useFirs
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/test LoginModulesTest.java SRPLoginTest.java TestSRPLogin.java
User: starksm
Date: 01/04/11 19:53:57
Modified:src/main/org/jboss/test LoginModulesTest.java
SRPLoginTest.java TestSRPLogin.java
Log:
Rename org.jboss.security.plugins.ProxyLoginModule
Integrate JaasServerLoginModule fix and missing unit test.
Revision ChangesPath
1.4 +47 -4 jbosssx/src/main/org/jboss/test/LoginModulesTest.java
Index: LoginModulesTest.java
===
RCS file: /cvsroot/jboss/jbosssx/src/main/org/jboss/test/LoginModulesTest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- LoginModulesTest.java 2001/04/04 21:39:02 1.3
+++ LoginModulesTest.java 2001/04/12 02:53:57 1.4
@@ -28,13 +28,13 @@
import org.jboss.security.SimpleGroup;
import org.jboss.security.SimplePrincipal;
-import org.jboss.security.auth.UsernamePasswordHandler;
-import org.jboss.security.plugins.samples.UsernamePasswordLoginModule;
+import org.jboss.security.auth.callback.UsernamePasswordHandler;
+import org.jboss.security.auth.spi.UsernamePasswordLoginModule;
/** Tests of the sample LoginModule classes.
@author [EMAIL PROTECTED]
-@version $Revision: 1.3 $
+@version $Revision: 1.4 $
*/
public class LoginModulesTest extends TestCase
{
@@ -121,6 +121,14 @@
AppConfigurationEntry[] entry = {ace};
return entry;
}
+AppConfigurationEntry[] testJaasServer()
+{
+String name =
"org.jboss.security.plugins.samples.JaasServerLoginModule";
+AppConfigurationEntry ace = new AppConfigurationEntry(name,
+AppConfigurationEntry.LoginModuleControlFlag.REQUIRED, new
HashMap());
+AppConfigurationEntry[] entry = {ace};
+return entry;
+}
AppConfigurationEntry[] testUsernamePassword()
{
return other();
@@ -198,6 +206,33 @@
lc.logout();
}
+public void testJaasServer() throws Exception
+{
+System.out.println("testJaasServer");
+UsernamePasswordHandler handler = new UsernamePasswordHandler("scott",
"echoman".toCharArray());
+LoginContext lc = new LoginContext("testJaasServer", handler);
+lc.login();
+Subject subject = lc.getSubject();
+Set groups = subject.getPrincipals(Group.class);
+assert("Principals contains scott", subject.getPrincipals().contains(new
SimplePrincipal("scott")));
+assert("Principals contains Roles", groups.contains(new
SimplePrincipal("Roles")));
+Group roles = (Group) groups.iterator().next();
+assert("Echo is a role", roles.isMember(new SimplePrincipal("Echo")));
+lc.logout();
+
+handler = new UsernamePasswordHandler("stark", "javaman".toCharArray());
+lc = new LoginContext("testJaasServer", handler);
+lc.login();
+subject = lc.getSubject();
+groups = subject.getPrincipals(Group.class);
+assert("Principals contains stark", subject.getPrincipals().contains(new
SimplePrincipal("stark")));
+assert("Principals contains Roles", groups.contains(new
SimplePrincipal("Roles")));
+roles = (Group) groups.iterator().next();
+assert("Echo is NOT a role", roles.isMember(new SimplePrincipal("Echo")) ==
false);
+assert("Java is a role", roles.isMember(new SimplePrincipal("Java")));
+assert("Coder is a role", roles.isMember(new SimplePrincipal("Coder")));
+lc.logout();
+}
public void testIdentity() throws Exception
{
System.out.println("testIdentity");
@@ -281,7 +316,15 @@
public void testJdbc() throws Exception
{
System.out.println("testJdbc");
-Class.forName ("org.enhydra.instantdb.jdbc.idbDriver");
+try
+{
+Class.forName ("org.enhydra.instantdb.jdbc.idbDriver");
+}
+catch(ClassNotFoundException e)
+{ // Skip the test
+System.out.println("Skipping test because
org.enhydra.instantdb.jdbc.idbDriver was not found");
+return;
+}
DataSource ds = new TestDS();
Properties env = new Properties();
org.jnp.server.Main naming = new org.jnp.server.Main();
1.2 +1 -1 jbosssx/src/main/org/jboss/test/SRPLoginTest.java
Index: SRPLoginTest.java
===
RCS file: /cvsroot/jboss/jbosssx/src/main/org/jboss/test/SRPLoginTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SRPLoginTest.java 2001/04/04 21:39:02 1.1
+++ SRPLoginTest.java 2001/04/12 02:53:57 1.2
@@ -11,14 +11,14 @@
import org.jboss.security.SimplePrincipal;
import org.jboss.securit
RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??!
As opposed to the current Configuration Service that already pases the MLet semantics to XML??? why? marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Lemoine David-dlemoi01 |Sent: Wednesday, April 11, 2001 11:05 AM |To: '[EMAIL PROTECTED]' |Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX |Service Groups...??! | | |Hi, | |Whatever solution you decide on for this problem, I think it could |be a good idea to replace the current MLet MBean-loader with |Stacy's XML-based XMLet. | |Just my 2 irish cents, | |David. | |-Original Message- |From: Stacy Curl [mailto:[EMAIL PROTECTED]] |Sent: 11 April 2001 15:33 |To: '[EMAIL PROTECTED]' |Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX |Service Groups...??! | | |Ok, sorry for the misunderstanding. I think that putting extra methods onto |JBoss MBeans is one technique, but this is an example of meta-data. I think |a better technique would be to do something like: | |// My XML is rusty | | | |&JbossServiceEntry; | | | | | | | |&JettyEntry; | | | | | |&JbossServiceEntry; |&FlibbleLifeCycleEntry; | | | |where JBossServiceEntry is: | | | JBossService | true | | ]]> | | | | life-cycle-start | | | | | init | | | start | | | | | ]]> | |This moves the burden from MBean's to the config, and it gives you the |ability to change what is considered to be a JBossService without changing |code. | |-Original Message- |From: Julian Gosnell [mailto:[EMAIL PROTECTED]] |Sent: 11 April 2001 12:00 |To: [EMAIL PROTECTED] |Cc: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX |Service Groups...??! | | |Stacy, | |I like your idea of abstracting the lifecycle mapping. |However, as I understand your description here, it |still does not address my problem. | |You suggest that in the absence of valid metadata, you |would assume the default lifecycle (I assume you mean |default JBoss Service lifecycle). | |The problem is that not all MBeans that may wish to |publish their interface via the JBoss JMX agent |necessarily want their lifecycle managed by |ServiceControl. They may not be a Service. | |I suggest that the default behaviour should be _NOT_ |to assume that every registered MBean is a Service. | |Services should publish a method - e.g. |isAJBossService(), which can be looked for by |ServiceControl. This could be added to Service, |implemented in MBeanServiceSupport etc, bringing most |MBeans used in JBoss into the fold. | |3rd party MBeans developed outside JBoss, but finding |themselves running inside JBoss would then be free to |share the JBoss JMX Agent, without fear of being |tampered with by ServiceControl. | |I am asking for a clear division between JMX and JBoss |Services. JBoss Services may be MBeans, but not all |MBeans are JBoss Services. | |I hope this makes sense, | | |Jules | |--- Stacy Curl <[EMAIL PROTECTED]> wrote: |> I think that having an abstract life cycle of: init, |> start, ping, stop, |> destroy |> is ok, but constraining MBeans to implement init(), |> start(), ping(), stop(), |> destroy() |> methods is not ok. So I think replacing a service is |> a mistake but |> abstracting parts |> of it isn't. So the ServiceControl would continue to |> listen for registration |> of MBeans |> and be responsible for doing init, etc but would |> first obtain the actual |> methods to |> call from the MetaDataService, in the absence of any |> life-cycle meta-data |> the ServiceControl |> would default to the standard methods, at present |> there are work arounds |> such as catching |> ReflectionExceptions after invoking 'start' and |> assuming (rightly or |> wrongly) that this means |> the MBean doesn't have a start method. |> |> I think that ServiceControl doesn't manage |> dependancies, it just aggregates |> MBeans. The dependancies |> seem to be implicit in the order in the MLet |> resource file. This is ok if |> you want to start/stop all |> the mbeans but not if you want to start/stop a |> subset. I think we should be |> following the style in ant |> and do something like: |> |> depends="really-important"/> |> |> -Original Message- |> From: Scott M Stark |> [mailto:[EMAIL PROTECTED]] |> Sent: 10 April 2001 23:57 |> To: [EMAIL PROTECTED] |> Subject: Re: [JBoss-dev] Custom startup solved !? |> was: Nested JMX |> Service Groups...??! |> |> |> Are you talking about a new service that replaces |> org.jboss.util.ServiceControl or |> a new service? The ServiceControl MBean that manages |> service lifecyle also |> manages service dependencies and the invocation of |> init() and start() are |> distinct |> phases. When start is called on a service you know |> that every service has |> received an init() and every service you depend on |> has received a sta
[JBoss-dev] CVS update: jbosssx/src/build build.bat build.sh build.xml
User: starksm Date: 01/04/11 19:53:56 Modified:src/build build.bat build.sh build.xml Log: Rename org.jboss.security.plugins.ProxyLoginModule Integrate JaasServerLoginModule fix and missing unit test. Revision ChangesPath 1.3 +2 -0 jbosssx/src/build/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jbosssx/src/build/build.bat,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- build.bat 2001/04/04 21:16:13 1.2 +++ build.bat 2001/04/12 02:53:56 1.3 @@ -7,5 +7,7 @@ set CP=%CP%;..\..\lib\jaxp.jar set CP=%CP%;..\..\lib\crimson.jar set CP=%CP%;..\..\lib\javac.jar +set CP=%CP%;..\..\lib\junit.jar +set CP=%CP%;..\..\lib\optional.jar java -classpath "%CP%" org.apache.tools.ant.Main %1 %2 %3 %4 %5 1.3 +2 -0 jbosssx/src/build/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jbosssx/src/build/build.sh,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- build.sh 2001/04/04 21:16:13 1.2 +++ build.sh 2001/04/12 02:53:56 1.3 @@ -6,5 +6,7 @@ CP=$CP:../../lib/jaxp.jar CP=$CP:../../lib/crimson.jar CP=$CP:../../lib/javac.jar +CP=$CP:../../lib/junit.jar +CP=$CP:../../lib/optional.jar java -classpath "$CP" org.apache.tools.ant.Main $* 1.3 +17 -3 jbosssx/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosssx/src/build/build.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- build.xml 2001/04/04 21:16:13 1.2 +++ build.xml 2001/04/12 02:53:56 1.3 @@ -1,6 +1,6 @@ @@ -87,7 +88,7 @@ - +
RE: [JBoss-dev] Nested JMX Service Groups...??!
|I still don't see anything wrong with type check for
|org.jboss.util.Service.
It is the simplest (and your first call) good for you kid!
marc
|
|Vladimir
|
|
|> You could use naming, but then you constrain naming
|> conventions, which may upset someone else.
|>
|> Just my 1p's-worth,
|>
|> Jules
|>
|> --- Scott M Stark <[EMAIL PROTECTED]>
|> wrote:
|> > The Jetty mbean is logging the exception itself as a
|> > warning and then it
|> > is throwing the proper ReflectionException. The
|> > issue is that ServiceControl
|> > is invoking JBoss Service methods on any mbean that
|> > registers with the
|> > MBeanServer. There needs to be a way to tell
|> > ServiceControl that categories
|> > of mbean should not be treated as candidate JBoss
|> > services. I'm saying this
|> > is trivial to do using a domain naming convention
|> > and a configurable NotificationFilter
|> > based on mbean domain names.
|> >
|> > If anyone has a better way achieving this speak up.
|> >
|> >
|> > - Original Message -
|> > From: "David Jencks" <[EMAIL PROTECTED]>
|> > To: <[EMAIL PROTECTED]>
|> > Sent: Tuesday, April 10, 2001 10:30 PM
|> > Subject: Re: [JBoss-dev] Nested JMX Service
|> > Groups...??!
|> >
|> >
|> > > Hi,
|> > >
|> > > Well, it looks to me like he has thrown the
|> > NoSuchMethodException himself
|> > > in his ModelMBeanImpl. This exception dexcends
|> > from Exception, thus is not
|> > > a reflection exception, and isn't caught by any of
|> > the exception
|> > > handlers/ignorers.
|> > >
|> > > I don't yet understand what ModelMBeans are for...
|> > but if he changed the
|> > > missing method handling to match that of line 1620
|> > of the MBeanServerImpl,
|> > > the problems might go away.
|> > >
|> > >
|> > > Further posts from Scott Stark and Marc Fleury
|> > make me think this may be
|> > > difficult to impossible. If so, we could instead
|> > change ServiceControl to
|> > > ignore MethodNotFoundExceptions as well as
|> > ReflectionExceptions. e.g.
|> > > around line 67
|> > >
|> > > } catch (ReflectionException e)
|> > > {
|> > >// Not a service - ok
|> > > }
|> > > catch (NoSuchMethodException e) {
|> > >//Not a service - also ok
|> > > } catch (RuntimeMBeanException e)
|> > >
|> > >
|> > > Personally I am inclined to suggest putting empty
|> > methods for the
|> > > nonexistent operations in every mbean. I don't
|> > entirely understand why
|> > > this isn't in the mbean spec.
|> > >
|> > > David Jencks
|> > >
|> >
|> >
|> >
|> > ___
|> > Jboss-development mailing list
|> > [EMAIL PROTECTED]
|> >
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|>
|> __
|> Do You Yahoo!?
|> Get email at your own domain with Yahoo! Mail.
|> http://personal.mail.yahoo.com/
|>
|> ___
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/lib jbossmq-client.jar
User: peterbraswell Date: 01/04/11 19:30:34 Modified:src/lib jbossmq-client.jar Log: Fixed some failure messages. Revision ChangesPath 1.5 +167 -174 jbosstest/src/lib/jbossmq-client.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Added Rel_2_2_1 tag to Branch_2_2
I integrated the JBossSX patched jars and tagged everything under jboss with Rel_2_2_1 for now. If you have something that should be integrated into the 2.2.1 release I believe the correct proceedure is: 1. Check out the 2.2.1 version: cvs co -r Rel_2_2_1 jboss 2. Make your changes ... 3. Commit your changes cvs commit ... 4. Move the Rel_2_2_1 tag from within the jboss root directory cvs tag -F Rel_2_2_1 Simone please correct this if it is in error. I'm thinking of doing the 2.2.1 release next Monday night at which point we'll add a JBoss_2_2_1_Final tag. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/build build.xml
User: starksm Date: 01/04/11 19:31:04 Modified:src/build Tag: Branch_2_2 build.xml Log: Update the version property to 2.2.1 Revision ChangesPath No revision No revision 1.58.2.2 +1 -1 jboss/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/src/build/build.xml,v retrieving revision 1.58.2.1 retrieving revision 1.58.2.2 diff -u -r1.58.2.1 -r1.58.2.2 --- build.xml 2001/04/12 02:04:06 1.58.2.1 +++ build.xml 2001/04/12 02:31:04 1.58.2.2 @@ -19,7 +19,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
User: starksm
Date: 01/04/11 19:29:33
Modified:src/main/org/jboss Tag: Branch_2_2 Main.java
Log:
Update the version string to "2.2.1 FINAL" in prepration for the release.
Revision ChangesPath
No revision
No revision
1.30.2.2 +2 -2 jboss/src/main/org/jboss/Main.java
Index: Main.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v
retrieving revision 1.30.2.1
retrieving revision 1.30.2.2
diff -u -r1.30.2.1 -r1.30.2.2
--- Main.java 2001/04/04 20:21:36 1.30.2.1
+++ Main.java 2001/04/12 02:29:33 1.30.2.2
@@ -32,13 +32,13 @@
* @see
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]">Daniel O'Connor.
- * @version $Revision: 1.30.2.1 $
+ * @version $Revision: 1.30.2.2 $
*/
public class Main
{
// Constants -
- String versionIdentifier = "2.2.0 FINAL";
+ String versionIdentifier = "2.2.1 FINAL";
// Attributes
// Static
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/build build.xml
User: starksm Date: 01/04/11 19:04:06 Modified:src/build Tag: Branch_2_2 build.xml Log: Integrate the 2_2_1 JBossSX patch jars Revision ChangesPath No revision No revision 1.58.2.1 +1 -1 jboss/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/src/build/build.xml,v retrieving revision 1.58 retrieving revision 1.58.2.1 diff -u -r1.58 -r1.58.2.1 --- build.xml 2001/03/27 07:21:23 1.58 +++ build.xml 2001/04/12 02:04:06 1.58.2.1 @@ -94,7 +94,7 @@ http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jboss-jaas.jar jbosssx.jar
User: starksm Date: 01/04/11 19:04:06 Modified:src/lib Tag: Branch_2_2 jboss-jaas.jar jbosssx.jar Log: Integrate the 2_2_1 JBossSX patch jars Revision ChangesPath No revision No revision 1.2.2.2 +144 -152 jboss/src/lib/jboss-jaas.jar <> 1.2.2.2 +218 -359 jboss/src/lib/jbosssx.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/client jbosssx-client.jar
User: starksm Date: 01/04/11 19:04:06 Modified:src/client Tag: Branch_2_2 jbosssx-client.jar Log: Integrate the 2_2_1 JBossSX patch jars Revision ChangesPath No revision No revision 1.2.2.2 +71 -83jboss/src/client/jbosssx-client.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins/samples JaasServerLoginModule.java
User: starksm
Date: 01/04/11 18:25:15
Modified:src/main/org/jboss/security/plugins/samples Tag: Branch_2_2
JaasServerLoginModule.java
Log:
Fix bug with role mapping in JaasServerLoginModule(ID 415511).
Add missing unit test for the JaasServerLoginModule.
Revision ChangesPath
No revision
No revision
1.3.2.1 +4 -0
jbosssx/src/main/org/jboss/security/plugins/samples/JaasServerLoginModule.java
Index: JaasServerLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/samples/JaasServerLoginModule.java,v
retrieving revision 1.3
retrieving revision 1.3.2.1
diff -u -r1.3 -r1.3.2.1
--- JaasServerLoginModule.java2001/03/29 02:27:12 1.3
+++ JaasServerLoginModule.java2001/04/12 01:25:15 1.3.2.1
@@ -112,6 +112,7 @@
*/
protected Group[] getRoleSets() throws LoginException
{
+String targetUser = getUsername();
Enumeration users = _roles.propertyNames();
SimpleGroup rolesGroup = new SimpleGroup("Roles");
ArrayList groups = new ArrayList();
@@ -120,6 +121,9 @@
{
String user = (String) users.nextElement();
String value = _roles.getProperty(user);
+if( user.startsWith(targetUser) == false )
+continue;
+
// Check for username.RoleGroup pattern
int index = user.indexOf('.');
if( index > 0 )
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/lib optional.jar junit.jar
User: starksm Date: 01/04/11 18:33:08 Modified:lib Tag: Branch_2_2 junit.jar Added: lib Tag: Branch_2_2 optional.jar Log: Add the junit jars so they don't have to be in the classpath Revision ChangesPath No revision No revision 1.1.2.1 +504 -466 jbosssx/lib/junit.jar <> No revision No revision 1.1.2.1 +1001 -0 jbosssx/lib/Attic/optional.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/test LoginModulesTest.java TestSRPLogin.java
User: starksm
Date: 01/04/11 18:25:15
Modified:src/main/org/jboss/test Tag: Branch_2_2
LoginModulesTest.java TestSRPLogin.java
Log:
Fix bug with role mapping in JaasServerLoginModule(ID 415511).
Add missing unit test for the JaasServerLoginModule.
Revision ChangesPath
No revision
No revision
1.3.2.1 +44 -2 jbosssx/src/main/org/jboss/test/LoginModulesTest.java
Index: LoginModulesTest.java
===
RCS file: /cvsroot/jboss/jbosssx/src/main/org/jboss/test/LoginModulesTest.java,v
retrieving revision 1.3
retrieving revision 1.3.2.1
diff -u -r1.3 -r1.3.2.1
--- LoginModulesTest.java 2001/04/04 21:39:02 1.3
+++ LoginModulesTest.java 2001/04/12 01:25:15 1.3.2.1
@@ -34,7 +34,7 @@
/** Tests of the sample LoginModule classes.
@author [EMAIL PROTECTED]
-@version $Revision: 1.3 $
+@version $Revision: 1.3.2.1 $
*/
public class LoginModulesTest extends TestCase
{
@@ -121,6 +121,14 @@
AppConfigurationEntry[] entry = {ace};
return entry;
}
+AppConfigurationEntry[] testJaasServer()
+{
+String name =
"org.jboss.security.plugins.samples.JaasServerLoginModule";
+AppConfigurationEntry ace = new AppConfigurationEntry(name,
+AppConfigurationEntry.LoginModuleControlFlag.REQUIRED, new
HashMap());
+AppConfigurationEntry[] entry = {ace};
+return entry;
+}
AppConfigurationEntry[] testUsernamePassword()
{
return other();
@@ -195,7 +203,33 @@
Group roles = (Group) groups.iterator().next();
assert("TestRole is a role", roles.isMember(new
SimplePrincipal("TestRole")));
assert("Role2 is a role", roles.isMember(new SimplePrincipal("Role2")));
+lc.logout();
+}
+public void testJaasServer() throws Exception
+{
+System.out.println("testJaasServer");
+UsernamePasswordHandler handler = new UsernamePasswordHandler("scott",
"echoman".toCharArray());
+LoginContext lc = new LoginContext("testJaasServer", handler);
+lc.login();
+Subject subject = lc.getSubject();
+Set groups = subject.getPrincipals(Group.class);
+assert("Principals contains scott", subject.getPrincipals().contains(new
SimplePrincipal("scott")));
+assert("Principals contains Roles", groups.contains(new
SimplePrincipal("Roles")));
+Group roles = (Group) groups.iterator().next();
+assert("Echo is a role", roles.isMember(new SimplePrincipal("Echo")));
+lc.logout();
+handler = new UsernamePasswordHandler("stark", "javaman".toCharArray());
+lc = new LoginContext("testJaasServer", handler);
+lc.login();
+subject = lc.getSubject();
+groups = subject.getPrincipals(Group.class);
+assert("Principals contains stark", subject.getPrincipals().contains(new
SimplePrincipal("stark")));
+assert("Principals contains Roles", groups.contains(new
SimplePrincipal("Roles")));
+roles = (Group) groups.iterator().next();
+assert("Echo is NOT a role", roles.isMember(new SimplePrincipal("Echo")) ==
false);
+assert("Java is a role", roles.isMember(new SimplePrincipal("Java")));
+assert("Coder is a role", roles.isMember(new SimplePrincipal("Coder")));
lc.logout();
}
public void testIdentity() throws Exception
@@ -281,7 +315,15 @@
public void testJdbc() throws Exception
{
System.out.println("testJdbc");
-Class.forName ("org.enhydra.instantdb.jdbc.idbDriver");
+try
+{
+Class.forName("org.enhydra.instantdb.jdbc.idbDriver");
+}
+catch(ClassNotFoundException e)
+{
+System.out.println("Skipping due to missing
org.enhydra.instantdb.jdbc.idbDriver");
+return;
+}
DataSource ds = new TestDS();
Properties env = new Properties();
org.jnp.server.Main naming = new org.jnp.server.Main();
1.1.2.1 +1 -1 jbosssx/src/main/org/jboss/test/TestSRPLogin.java
Index: TestSRPLogin.java
===
RCS file: /cvsroot/jboss/jbosssx/src/main/org/jboss/test/TestSRPLogin.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- TestSRPLogin.java 2001/03/05 09:53:38 1.1
+++ TestSRPLogin.java 2001/04/12 01:25:15 1.1.2.1
@@ -11,14 +11,14 @@
import org.jboss.security.SimplePrincipal;
import org.jboss.security.SecurityPolicy;
import org.jboss.security.SecurityPolicyParser;
-import org.jboss.security.plugins.UsernamePa
[JBoss-dev] CVS update: jbosssx/src/build build.bat build.sh build.xml
User: starksm Date: 01/04/11 18:22:52 Modified:src/build Tag: Branch_2_2 build.bat build.sh build.xml Log: Update jars to include those required for unit-test target Revision ChangesPath No revision No revision 1.2.2.1 +2 -0 jbosssx/src/build/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jbosssx/src/build/build.bat,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- build.bat 2001/04/04 21:16:13 1.2 +++ build.bat 2001/04/12 01:22:52 1.2.2.1 @@ -7,5 +7,7 @@ set CP=%CP%;..\..\lib\jaxp.jar set CP=%CP%;..\..\lib\crimson.jar set CP=%CP%;..\..\lib\javac.jar +set CP=%CP%;..\..\lib\junit.jar +set CP=%CP%;..\..\lib\optional.jar java -classpath "%CP%" org.apache.tools.ant.Main %1 %2 %3 %4 %5 1.2.2.1 +2 -0 jbosssx/src/build/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jbosssx/src/build/build.sh,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- build.sh 2001/04/04 21:16:13 1.2 +++ build.sh 2001/04/12 01:22:52 1.2.2.1 @@ -6,5 +6,7 @@ CP=$CP:../../lib/jaxp.jar CP=$CP:../../lib/crimson.jar CP=$CP:../../lib/javac.jar +CP=$CP:../../lib/junit.jar +CP=$CP:../../lib/optional.jar java -classpath "$CP" org.apache.tools.ant.Main $* 1.2.2.1 +9 -2 jbosssx/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosssx/src/build/build.xml,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- build.xml 2001/04/04 21:16:13 1.2 +++ build.xml 2001/04/12 01:22:52 1.2.2.1 @@ -1,6 +1,6 @@
[JBoss-dev] CVS update: jbossmx/lib ant-1.3.jar jaxp.jar
User: kimptoc Date: 01/04/11 16:36:03 Added: lib ant-1.3.jar jaxp.jar Log: added a unix build script - and ant jars to the project - to allow for daily build - on unix... Revision ChangesPath 1.1 jbossmx/lib/ant-1.3.jar <> 1.1 jbossmx/lib/jaxp.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/build build.sh build.xml
User: kimptoc
Date: 01/04/11 16:36:03
Modified:src/build build.xml
Added: src/build build.sh
Log:
added a unix build script - and ant jars to the project - to allow for daily build -
on unix...
Revision ChangesPath
1.2 +8 -1 jbossmx/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbossmx/src/build/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.xml 2001/03/29 18:33:25 1.1
+++ build.xml 2001/04/11 23:36:03 1.2
@@ -35,6 +35,13 @@
${src.lib.dir}/xerces.jar;
${jboss.jar}"
/>
+
+
+
+
+
+
+
@@ -116,4 +123,4 @@
-
\ No newline at end of file
+
1.1 jbossmx/src/build/build.sh
Index: build.sh
===
#! /bin/sh
# $Id: build.sh,v 1.1 2001/04/11 23:36:03 kimptoc Exp $
TARGET_CLASSPATH=`echo ../../lib/*.jar | tr ' ' ':'`
TARGET_CLASSPATH=${TARGET_CLASSPATH}:`echo ../lib/*.jar | tr ' ' ':'`
if test -f ${JAVA_HOME}/lib/tools.jar ; then
TARGET_CLASSPATH=${TARGET_CLASSPATH}:${JAVA_HOME}/lib/tools.jar
fi
TARGET_CLASSPATH=${TARGET_CLASSPATH}:../../build/classes
java -classpath $TARGET_CLASSPATH org.apache.tools.ant.Main $*
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/lib - New directory
User: kimptoc Date: 01/04/11 16:34:51 jbossmx/lib - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 2.2 Patch procedure
I would say the problem is worthy of another release. Although its really isolated to a login module that I would not use in production, it is the login module used for the security howtos/examples so it causes users much pain. Since Toby also has an issue we might as well aggregate these together. > > Here if you think that a new JBoss release (2.2.1) is truly needed, you can > use the JBoss_2_2_1_Final tag instead of Rel_2_2_1. It really depends on how > much important is the bug you fixed, and maybe a word of Marc about shipping > a new release. If you have a doubt, use tag Rel_2_2_1, we can later rename > it to JBoss_2_2_1_Final. CVS tags are very easy to add, delete, rename, etc, > so better tag once more than once less. > > If a release is needed, you can now package everything again and upload to > the web site (Oh, if someone finds the time, update also the main page that > still refers to Rickard's 2.1 (beta) release, and maybe moving it in a more > visible position, like at the top of the main page) > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] 2.2 Patch procedure
Hey Scott, > The code that needs to be patched is actually in the jbosssx > cvs module. I did > add a JBoss_2_2_0_Final to the code in this module at the time of the > 2.2 release, but I did not make a branch. > > Would this work: > cvs rtag -b -r JBoss_2_2_0_Final Branch_2_2 jbosssx OK > co -rBranch_2_2 jbosssx You just missed the 'cvs' before 'co' but it's OK. Then you can commit the changes to the branch AND the main trunk of jbosssx module. After that I suppose you will have 2 new jars for the jboss module, one for the branch and one for the main trunk, so refer to previous indication on how to commit them. I think that tagging with Rel_2_2_1 at least jboss module would be useful. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: R: [JBoss-dev] 2.2 Patch procedure
Hey Toby, > > I can tell you what to do in CVS, I'm not expert on how > this must be handled > > in SourceForge using the tracker, anyway: > > > > Checkout the 2.2 branch: > > cvs co -rBranch_2_2 jboss > > > > Change what has to be changed (working on the files you > just checked out) > > and commit the changes. > > > > Tag the branch with a new tag: the next available is Rel_2_2_1, so: > > cvs tag Rel_2_2_1 (from the jboss' module root dir) > > I'm going to need to do this shortly as well, and I just want > to be sure > that I understand. What is the purpose of this tag? Its purpose is to allow easy merge of the patches commited to the branch with the code on the main trunk. Also, later on, when the branch and the main trunk have developed several new revisions, it will be easier to check if all the patches went to the main trunk. I'm finishing a detailed document about merging, when I'm done I'll post it, few days more :P Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Nested JMX Service Groups...??!
Ok as long as the management model of state is untouched your beans should not implement JBoss centric APIs. If I understand what you are saying correctly, there are other beans that Jetty generates, that have nothing to do with JBoss integration, but that use JMX as a bus for communication but do not go in as "services". pf... i go back to "be careful what you expose as JMX" you can go "everything is JMX", jmx is a poor bus when it comes down to it. Re: the problem is that we register listening interest for every possible MBean. Frankly I think the naming solution is possible in the sense that you require a "JBoss domain" that signifies integration. The API one is also good, even more "implicit" either one would work at this point. It got me thinking about scoping JMX domains of management. >From a management standpoint I must warn you about the non propagation of lifecycle events. Init and start are "scoped" methods. You can init your jetty stuff, and then "init" the integration with JBoss (hook up the naming whatever you need to do for the integration). I would stop the server as a unit and want the parts of the server to stop, if you are running jetty separately I would still want to notify you of a "stop" event as a jboss service. State management is important at each step of the domain (functional microkernels). Bottom line? we are standardizing this propagation in JSR77 as a "unit" start/stop (state management at its bare minimum). That you don't want to implement the jboss interface in *every* JMX class, I can see, that you should implement a "similar" jsr77 one is a "strong recommendation" soon to be the law. That we need to scope the registration and listening (essentially creating subnaming domains of notification with cascading calls in JMX) is also a trivial statement doing it explicetely by domain naming is the simplest more expressive solution, doing it with class detection would work but is more implicit. Either one is good at this point. Whoever reaches CVS first wins :) marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Julian Gosnell |Sent: Wednesday, April 11, 2001 4:52 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Nested JMX Service Groups...??! | | | |--- Scott M Stark <[EMAIL PROTECTED]> |wrote: |> They can't create a wrapper because mbeans are being |> created as a byproduct |> of interaction with the Jetty JMX interface. This is |> a generic issue with integrating |> third party services that happen to be mbeans which |> may be using the JMX bus |> for whatever purpose. Its trivial to add a filter by |> domain |> that allows ServiceControl to not even attempt to |> manage any mbeans in a given |> domain. This does not break the JBoss management |> model in any way that I see. |> It simply adds the notion of non-service domains. |> | |Yes ! | |Thanks Scott, | |This is it. | |How you choose to differentiate between JBoss Service |MBeans and 3rd party ones is what I think the |discussion should hinge upon. | |Jules | |> - Original Message - |> From: "marc fleury" <[EMAIL PROTECTED]> |> To: <[EMAIL PROTECTED]> |> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> |> Sent: Tuesday, April 10, 2001 8:17 PM |> Subject: RE: [JBoss-dev] Nested JMX Service |> Groups...??! |> |> |> > |The stack trace is coming from the Jetty |> ModelMBeanImpl class, not JBoss's |> > |ServiceControl. Although annoying, this is just a |> cosmetic |> > |exception. To clean |> > |this up we could add a notification filter |> attribute to the |> > |ServiceControl mbean |> > |> > Again, implement the empty wrapper, that you don't |> want to do anything about |> > the integration is your problem but we should not |> start breaking the |> > management model in JBoss because you decide to |> ignore it. |> > |> > marc |> > |> |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> |http://lists.sourceforge.net/lists/listinfo/jboss-development | | |__ |Do You Yahoo!? |Get email at your own domain with Yahoo! Mail. |http://personal.mail.yahoo.com/ | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 2.2 Patch procedure
The code that needs to be patched is actually in the jbosssx cvs module. I did add a JBoss_2_2_0_Final to the code in this module at the time of the 2.2 release, but I did not make a branch. Would this work: cvs rtag -b -r JBoss_2_2_0_Final Branch_2_2 jbosssx co -rBranch_2_2 jbosssx - Original Message - From: "Bordet, Simone" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 11, 2001 2:23 PM Subject: R: [JBoss-dev] 2.2 Patch procedure > Hey Scott, > > > Ok, a problem mentioned on the user list turns out to be a > > bug in the 2.2 > > release of the JBossSX code. This was not seen because the > > login module > > used in the howto was not being convered in the unit tests(my fault). > > > > So, what is the procedure for creating a patch and new release on the > > 2.2 branch? > > I can tell you what to do in CVS, I'm not expert on how this must be handled > in SourceForge using the tracker, anyway: > > Checkout the 2.2 branch: > cvs co -rBranch_2_2 jboss > > Change what has to be changed (working on the files you just checked out) > and commit the changes. > > Tag the branch with a new tag: the next available is Rel_2_2_1, so: > cvs tag Rel_2_2_1 (from the jboss' module root dir) > > Here if you think that a new JBoss release (2.2.1) is truly needed, you can > use the JBoss_2_2_1_Final tag instead of Rel_2_2_1. It really depends on how > much important is the bug you fixed, and maybe a word of Marc about shipping > a new release. If you have a doubt, use tag Rel_2_2_1, we can later rename > it to JBoss_2_2_1_Final. CVS tags are very easy to add, delete, rename, etc, > so better tag once more than once less. > > If a release is needed, you can now package everything again and upload to > the web site (Oh, if someone finds the time, update also the main page that > still refers to Rickard's 2.1 (beta) release, and maybe moving it in a more > visible position, like at the top of the main page) > > Update also the main trunk: > cvs up -A > > Change again the files (on this new working copy from the main trunk) > applying the patch (or if you know well CVS you can merge the changes) and > commit the changes. > > Hope helps, but if you have doubts don't hesitate to contact me. > > Cheers, > > Simon > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: R: [JBoss-dev] 2.2 Patch procedure
On Wed, Apr 11, 2001 at 10:23:27PM +0100, Bordet, Simone wrote: > Hey Scott, > > > Ok, a problem mentioned on the user list turns out to be a > > bug in the 2.2 > > release of the JBossSX code. This was not seen because the > > login module > > used in the howto was not being convered in the unit tests(my fault). > > > > So, what is the procedure for creating a patch and new release on the > > 2.2 branch? > > I can tell you what to do in CVS, I'm not expert on how this must be handled > in SourceForge using the tracker, anyway: > > Checkout the 2.2 branch: > cvs co -rBranch_2_2 jboss > > Change what has to be changed (working on the files you just checked out) > and commit the changes. > > Tag the branch with a new tag: the next available is Rel_2_2_1, so: > cvs tag Rel_2_2_1 (from the jboss' module root dir) I'm going to need to do this shortly as well, and I just want to be sure that I understand. What is the purpose of this tag? Thanks, Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Object Unique Id Generator
Packaged apps are a completely different story. There you want to layer the software so that as much as possible is portable. I would not dispute the use of portability techniques when you really need to be portable. I think the problem is that the RDBMS vendors have made a real hash of it, and if you're building something big or needs to go fast you usually need to spend some time on the database, and this winds up creeping into the bottom portions of the application. Cheers Jay -Original Message- From: Jim Archer To: [EMAIL PROTECTED] Cc: Jay Walters Sent: 4/11/01 4:57 PM Subject: RE: [JBoss-dev] Object Unique Id Generator Hi Jay... --On Wednesday, April 11, 2001 12:57 PM -0400 Jay Walters <[EMAIL PROTECTED]> wrote: > Besides, if you decide to change things, then change the unique ID > generation. It's not as if you're just going to take an application that > works with Oracle and plug it into a LDAP server or a message store. > Sorry, I've never seen it. In any application that has been optimized in > terms of data access there is always some database specific tuning > involved and this likely won't work on the next one. Most of your comments are quite correct for many uses and applications, in particular, if your developing an app for use in house. I think a concern for many people is that they want portability in their app not so they can migrate from one platform to another after deployment, although that may well be needed as systems grow, but so that they can license the app and let the customer deploy the app in their own existing environmant. Many big companies have a signifigant investment in an infrastructure (and entire departments to maintain this infrastructure), such as an Oracle database system used by all the companies apps, or a mainframe system everything must run on, and so on. If the app vendor can avoide dependencies, they have a wider market they can serve with less effort. If you don't know what your deploying on at design/development time (and its often best to assume you don't) then you want to make sure your components work in a wide variety of cases, including any database, and server, clustered or non-clustered and so on. My $0.02! Jim ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] 2.2 Patch procedure
Hey Scott, > Ok, a problem mentioned on the user list turns out to be a > bug in the 2.2 > release of the JBossSX code. This was not seen because the > login module > used in the howto was not being convered in the unit tests(my fault). > > So, what is the procedure for creating a patch and new release on the > 2.2 branch? I can tell you what to do in CVS, I'm not expert on how this must be handled in SourceForge using the tracker, anyway: Checkout the 2.2 branch: cvs co -rBranch_2_2 jboss Change what has to be changed (working on the files you just checked out) and commit the changes. Tag the branch with a new tag: the next available is Rel_2_2_1, so: cvs tag Rel_2_2_1 (from the jboss' module root dir) Here if you think that a new JBoss release (2.2.1) is truly needed, you can use the JBoss_2_2_1_Final tag instead of Rel_2_2_1. It really depends on how much important is the bug you fixed, and maybe a word of Marc about shipping a new release. If you have a doubt, use tag Rel_2_2_1, we can later rename it to JBoss_2_2_1_Final. CVS tags are very easy to add, delete, rename, etc, so better tag once more than once less. If a release is needed, you can now package everything again and upload to the web site (Oh, if someone finds the time, update also the main page that still refers to Rickard's 2.1 (beta) release, and maybe moving it in a more visible position, like at the top of the main page) Update also the main trunk: cvs up -A Change again the files (on this new working copy from the main trunk) applying the patch (or if you know well CVS you can merge the changes) and commit the changes. Hope helps, but if you have doubts don't hesitate to contact me. Cheers, Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] build.bat fails for Windows
you are correct, I had the MKS toolkit in my path so it was using the Unix like find Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jay > Walters > Sent: Wednesday, April 11, 2001 1:01 PM > To: 'Bill Burke '; '[EMAIL PROTECTED] ' > Subject: RE: [JBoss-dev] build.bat fails for Windows > > > I had the same problem and tracked it back (at least for me) to having > cygwin in my path. I think it's the use of 'find' in the script and it > wants the DOS/Win2K one not a Unix one. Once I went back to being a plain > Win2K machine the build.bat script works fine for me. > > Cheers > > -Original Message- > From: Bill Burke > To: [EMAIL PROTECTED] > Sent: 4/11/01 2:46 PM > Subject: Re: [JBoss-dev] build.bat fails for Windows > > Hardcode the paths in build.bat and you'll be ok. I had trouble > building with 2.0 and 2.1, I hardcoded the paths, and everything was > fine. Of course I didn't bother to figure out why :-) > > Bill > > Filip Hanik wrote: > > > I just checked out a fresh version of the JBoss module. > > > > the build script fails > > building jboss > > > > find: unable to access "Directory": The system cannot find the file > > specified. > > > > CLASSPATH= > > ...\..\lib\ant.jar;..\..\lib\xml.jar;..\..\lib\xmlbeans.jar;..\..\lib\ > > > javac.jar;\..\..\lib\ant-1.3.jar;\..\..\lib\awt.jar;\..\..\lib\codegen.j > ar;\ > > ...\. > > > ..\lib\crimson.jar;\..\..\lib\javac.jar;\..\..\lib\jaxp.jar;\..\..\lib\j > mxri. > > jar; > > \..\..\lib\xml.jar;\..\..\lib\xmlbeans.jar;\..\..\build\classes > > > > Exception in thread "main" java.lang.NoClassDefFoundError: > > org/apache/tools/ant/Main > > > > > > Filip > > ~ > > Namaste - I bow to the divine in you > > ~ > > Filip Hanik > > Software Architect > > [EMAIL PROTECTED] > > www.filip.net > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Object Unique Id Generator
Hi Jay... --On Wednesday, April 11, 2001 12:57 PM -0400 Jay Walters <[EMAIL PROTECTED]> wrote: > Besides, if you decide to change things, then change the unique ID > generation. It's not as if you're just going to take an application that > works with Oracle and plug it into a LDAP server or a message store. > Sorry, I've never seen it. In any application that has been optimized in > terms of data access there is always some database specific tuning > involved and this likely won't work on the next one. Most of your comments are quite correct for many uses and applications, in particular, if your developing an app for use in house. I think a concern for many people is that they want portability in their app not so they can migrate from one platform to another after deployment, although that may well be needed as systems grow, but so that they can license the app and let the customer deploy the app in their own existing environmant. Many big companies have a signifigant investment in an infrastructure (and entire departments to maintain this infrastructure), such as an Oracle database system used by all the companies apps, or a mainframe system everything must run on, and so on. If the app vendor can avoide dependencies, they have a wider market they can serve with less effort. If you don't know what your deploying on at design/development time (and its often best to assume you don't) then you want to make sure your components work in a wide variety of cases, including any database, and server, clustered or non-clustered and so on. My $0.02! Jim ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-415516 ] Can't redeploy resource adapters
Bugs item #415516, was updated on 2001-04-11 13:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=415516&group_id=22866 Category: JBossCX Group: v2.2 (stable) Status: Open Priority: 1 Submitted By: Toby Allsopp (tobyallsopp) Assigned to: Toby Allsopp (tobyallsopp) Summary: Can't redeploy resource adapters Initial Comment: Undeploying and redploying a resource adapter gives exceptions about zip files being open or something. Possibly a bug in the JarURLConnection stuff, I don't know. Not much of a problem. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=415516&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Object Unique Id Generator
Personally, I think it is faster and more robust in the database. Of course this all depends on your point of view. Alas this is getting us nowhere quickly. We have both made our points. As I said, there are many implementations of a unique id generator out there, and sometimes you need to use one of them. A good example of this would be if there is a need for non-sequential (guessable) primary keys. In the end it is a hammer and a one tool toolbox isn't all that useful. As for the serverside, they postulate that tightly coupling your database to your presentation layer via an entity bean inheriting from a value object is a good thing, so I wouldn't put too much faith in them as the arbiter of good design. Cheers Jay -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 4/11/01 2:41 PM Subject: RE: [JBoss-dev] Object Unique Id Generator The question is why use the database to generate unique id's? There is a pattern at www.theserverside.com that describes a simple, reliable, scalable technique to generate a reasonable GUID. While most applications will use databases as their only persistent storage, what is the benefit of introducing additional coupling by utilizing the database for unique id's? Scott -Original Message- From: Jay Walters [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 11, 2001 11:57 AM To: '[EMAIL PROTECTED] ' Subject: RE: [JBoss-dev] Object Unique Id Generator You are right that a unique identifier is not a database specific concept, and that unique id bean is a good tool to have in your toolbox. Sometimes, like when using LDAP or message queues you're going to need it. However if I am storing my data in an RDBMS (like most EJB developers will be) why not use the RDBMS' built in facilities for generating unique keys. If the data is persisted into the RDBMS it must be there for the application to run (persist new data or load old data). RDBMS products have been making unique ids efficiently since the client server days. I just don't buy this super size distributed enterprise needs GUIDs from a separate session bean thing for every application using EJBs. A lot of EJB applications will benefit from simple design (IMHO database generated keys fit this bill, but it's religion) and don't need all this stuff. Besides, if you decide to change things, then change the unique ID generation. It's not as if you're just going to take an application that works with Oracle and plug it into a LDAP server or a message store. Sorry, I've never seen it. In any application that has been optimized in terms of data access there is always some database specific tuning involved and this likely won't work on the next one. In terms of coupling, I think once you deploy the application most users are coupled to the database. The developers might say, "Ha this baby is 100% portable it'll run anywhere," but the DBAs who only know SQL Server or ORACLE and aren't in a hurry to migrate 200 GB of data probably know the score. Most companies don't move internal apps around without good reason, nor do they do it frequently. There is a small set of applications that will benefit from using a seperate bean for the enterprise super scalable thing, and a larger set of applications using databases on the low end which don't have efficient mechansisms for generating unique ids who will also benefit, but most people building real IS/IT applications IMHO should be using database generated unique ids where it makes sense, e.g. when storing the data into an RDBMS. Cheers Jay -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 4/11/01 11:37 AM Subject: RE: [JBoss-dev] Object Unique Id Generator The unique id is not a db concept. The application should have the flexibility to use multiple persistent stores such as directory servers, message queues, files, etc. The id should not be dependent on any one persistent store for generating id's because it binds the other persistent storages to that particular persistent store, the application itself should provide id's to reduce coupling between the components of the system. What is the benefit of having the id generation inside the database? At best, the database can only guarantee database scope uniqueness. Scott ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 2.2 Patch procedure
Ok, a problem mentioned on the user list turns out to be a bug in the 2.2 release of the JBossSX code. This was not seen because the login module used in the howto was not being convered in the unit tests(my fault). So, what is the procedure for creating a patch and new release on the 2.2 branch? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-415511 ] JaasServerLoginModule is broken
Bugs item #415511, was updated on 2001-04-11 13:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=415511&group_id=22866 Category: JBossSX Group: v2.2 (stable) Status: Open Priority: 9 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: JaasServerLoginModule is broken Initial Comment: The 2.2 release of the JaasServerLoginModule is assigning all the union of all roles to each user. This was not seen in testing because the JBossSX unit- tests are not convering this login module. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=415511&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] build.bat fails for Windows
I had the same problem and tracked it back (at least for me) to having cygwin in my path. I think it's the use of 'find' in the script and it wants the DOS/Win2K one not a Unix one. Once I went back to being a plain Win2K machine the build.bat script works fine for me. Cheers -Original Message- From: Bill Burke To: [EMAIL PROTECTED] Sent: 4/11/01 2:46 PM Subject: Re: [JBoss-dev] build.bat fails for Windows Hardcode the paths in build.bat and you'll be ok. I had trouble building with 2.0 and 2.1, I hardcoded the paths, and everything was fine. Of course I didn't bother to figure out why :-) Bill Filip Hanik wrote: > I just checked out a fresh version of the JBoss module. > > the build script fails > building jboss > > find: unable to access "Directory": The system cannot find the file > specified. > > CLASSPATH= > ...\..\lib\ant.jar;..\..\lib\xml.jar;..\..\lib\xmlbeans.jar;..\..\lib\ > javac.jar;\..\..\lib\ant-1.3.jar;\..\..\lib\awt.jar;\..\..\lib\codegen.j ar;\ > ...\. > ..\lib\crimson.jar;\..\..\lib\javac.jar;\..\..\lib\jaxp.jar;\..\..\lib\j mxri. > jar; > \..\..\lib\xml.jar;\..\..\lib\xmlbeans.jar;\..\..\build\classes > > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/tools/ant/Main > > > Filip > ~ > Namaste - I bow to the divine in you > ~ > Filip Hanik > Software Architect > [EMAIL PROTECTED] > www.filip.net > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Patches-415321 ] RAR Instance Deployer for jbosscx
On Wed, Apr 11, 2001 at 11:23:11AM -0400, David Jencks wrote: > OOPS! > > I inadvertantly broke the .jcml xml below while trying to add an > explanatory comment. Sorry. > > Fixed below > > Would it make any sense to configure instances of AutoDeployer to look for > specific extensions? So the next time we have a new deployer for .xyz > files we set up a autodeployer to look only for them? I think it would make more sense to have AutoDeployer ask its configured deployer to decide, e.g. by returning a java.io.FilenameFilter. The algorithm would then be: 1) if the deployer has a FileFilter getDeployableFilenameFilter() method, use that to grab the filter, otherwise use a filter that accepts all files 2) Change all the hardcoded checks in AutoDeployer to if(filter.accept(url.getFile())) I'll commit this tonight if there are no objections. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] build.bat fails for Windows
Hardcode the paths in build.bat and you'll be ok. I had trouble building with 2.0 and 2.1, I hardcoded the paths, and everything was fine. Of course I didn't bother to figure out why :-) Bill Filip Hanik wrote: > I just checked out a fresh version of the JBoss module. > > the build script fails > building jboss > > find: unable to access "Directory": The system cannot find the file > specified. > > CLASSPATH= > ...\..\lib\ant.jar;..\..\lib\xml.jar;..\..\lib\xmlbeans.jar;..\..\lib\ > javac.jar;\..\..\lib\ant-1.3.jar;\..\..\lib\awt.jar;\..\..\lib\codegen.jar;\ > ...\. > ..\lib\crimson.jar;\..\..\lib\javac.jar;\..\..\lib\jaxp.jar;\..\..\lib\jmxri. > jar; > \..\..\lib\xml.jar;\..\..\lib\xmlbeans.jar;\..\..\build\classes > > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/tools/ant/Main > > > Filip > ~ > Namaste - I bow to the divine in you > ~ > Filip Hanik > Software Architect > [EMAIL PROTECTED] > www.filip.net > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Object Unique Id Generator
The question is why use the database to generate unique id's? There is a pattern at www.theserverside.com that describes a simple, reliable, scalable technique to generate a reasonable GUID. While most applications will use databases as their only persistent storage, what is the benefit of introducing additional coupling by utilizing the database for unique id's? Scott -Original Message- From: Jay Walters [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 11, 2001 11:57 AM To: '[EMAIL PROTECTED] ' Subject: RE: [JBoss-dev] Object Unique Id Generator You are right that a unique identifier is not a database specific concept, and that unique id bean is a good tool to have in your toolbox. Sometimes, like when using LDAP or message queues you're going to need it. However if I am storing my data in an RDBMS (like most EJB developers will be) why not use the RDBMS' built in facilities for generating unique keys. If the data is persisted into the RDBMS it must be there for the application to run (persist new data or load old data). RDBMS products have been making unique ids efficiently since the client server days. I just don't buy this super size distributed enterprise needs GUIDs from a separate session bean thing for every application using EJBs. A lot of EJB applications will benefit from simple design (IMHO database generated keys fit this bill, but it's religion) and don't need all this stuff. Besides, if you decide to change things, then change the unique ID generation. It's not as if you're just going to take an application that works with Oracle and plug it into a LDAP server or a message store. Sorry, I've never seen it. In any application that has been optimized in terms of data access there is always some database specific tuning involved and this likely won't work on the next one. In terms of coupling, I think once you deploy the application most users are coupled to the database. The developers might say, "Ha this baby is 100% portable it'll run anywhere," but the DBAs who only know SQL Server or ORACLE and aren't in a hurry to migrate 200 GB of data probably know the score. Most companies don't move internal apps around without good reason, nor do they do it frequently. There is a small set of applications that will benefit from using a seperate bean for the enterprise super scalable thing, and a larger set of applications using databases on the low end which don't have efficient mechansisms for generating unique ids who will also benefit, but most people building real IS/IT applications IMHO should be using database generated unique ids where it makes sense, e.g. when storing the data into an RDBMS. Cheers Jay -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 4/11/01 11:37 AM Subject: RE: [JBoss-dev] Object Unique Id Generator The unique id is not a db concept. The application should have the flexibility to use multiple persistent stores such as directory servers, message queues, files, etc. The id should not be dependent on any one persistent store for generating id's because it binds the other persistent storages to that particular persistent store, the application itself should provide id's to reduce coupling between the components of the system. What is the benefit of having the id generation inside the database? At best, the database can only guarantee database scope uniqueness. Scott ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] using jBoss in a production environment?!?
Torben Jäger wrote: > Hi all! > > Just ported our b2b platform from IAS to jBoss it seems that jBoss is > having some performance problems. > > A simple jsp (in embedded tomcat) reading some entities over a finder > method is real slow (table contains only 30 rows!!). Running this jsp > with Inprise Application Server you couldn't recognize any action on > the server. Is it a CMP bean or a BMP bean? You do realize that accessing entities directly from a JSP is probably not going to perform well on a variety of application servers, right? Also, Tomcat is known to not be the fastest JSP engine out there. > > I am using standard jBoss 2.2 installation with embedded > tomcat. Database is running on another server (100 Mbit). > > Dev-Environment > > PIII 600 > 512 MB RAM > jdk 1.3 > tested on RH7.0 (23 sec) and w2k (9 sec) Are those times averaged, or first-run. You'll find that JBoss under hotspot gets quite a bit faster in subsequent runs. > > jdbc-driver: i-net sprinta2000 @ M$-SQL-Server 2000 > > > Having said to my CEOs jBoss is the server to choose, I now have a > problem to underline this statement when I have to present my work > next week. > If I can't fill this lack of performance my boss isn't struggling > anymore whether to change the appserver or not. So, jBoss will be > dead. :-( > > Why is jBoss so slow in this case? Are any performance improvements > planned in near future? I've been looking at performance a bit. This was on haitus while we get the ECPerf stuff running so that we have real-world(ish) test cases. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Object Unique Id Generator
Hi! Hey Andy, Jay, I think you made some very good points here. I might be shooting myself in the foot here, but I see 2 good reasons for not including my UID Generator in JBoss: - It is probably an overkill for most development, refering to the realities you point to Jay and your arguments Andy; - It needs a database supporting "FOR UPDATE" clauses, and no database of such type is blundled with JBoss; So lets say this is an "honorable defeat". I will just have to find something else! :-) Have fun Emmanuel - Original Message - From: "Jay Walters" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 11, 2001 5:57 PM Subject: RE: [JBoss-dev] Object Unique Id Generator > You are right that a unique identifier is not a database specific concept, > and that unique id bean is a good tool to have in your toolbox. Sometimes, > like when using LDAP or message queues you're going to need it. > > However if I am storing my data in an RDBMS (like most EJB developers will > be) why not use the RDBMS' built in facilities for generating unique keys. > If the data is persisted into the RDBMS it must be there for the application > to run (persist new data or load old data). RDBMS products have been making > unique ids efficiently since the client server days. > > I just don't buy this super size distributed enterprise needs GUIDs from a > separate session bean thing for every application using EJBs. A lot of EJB > applications will benefit from simple design (IMHO database generated keys > fit this bill, but it's religion) and don't need all this stuff. > > Besides, if you decide to change things, then change the unique ID > generation. It's not as if you're just going to take an application that > works with Oracle and plug it into a LDAP server or a message store. Sorry, > I've never seen it. In any application that has been optimized in terms of > data access there is always some database specific tuning involved and this > likely won't work on the next one. > > In terms of coupling, I think once you deploy the application most users are > coupled to the database. The developers might say, "Ha this baby is 100% > portable it'll run anywhere," but the DBAs who only know SQL Server or > ORACLE and aren't in a hurry to migrate 200 GB of data probably know the > score. Most companies don't move internal apps around without good reason, > nor do they do it frequently. > > There is a small set of applications that will benefit from using a seperate > bean for the enterprise super scalable thing, and a larger set of > applications using databases on the low end which don't have efficient > mechansisms for generating unique ids who will also benefit, but most people > building real IS/IT applications IMHO should be using database generated > unique ids where it makes sense, e.g. when storing the data into an RDBMS. > > Cheers > Jay > > -Original Message- > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Sent: 4/11/01 11:37 AM > Subject: RE: [JBoss-dev] Object Unique Id Generator > > The unique id is not a db concept. The application should have the > flexibility to use multiple persistent stores such as directory servers, > message queues, files, etc. The id should not be dependent on any one > persistent store for generating id's because it binds the other > persistent > storages to that particular persistent store, the application itself > should > provide id's to reduce coupling between the components of the system. > What > is the benefit of having the id generation inside the database? At best, > the > database can only guarantee database scope uniqueness. > > > Scott > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] build.bat fails for Windows
I just checked out a fresh version of the JBoss module. the build script fails building jboss find: unable to access "Directory": The system cannot find the file specified. CLASSPATH= ..\..\lib\ant.jar;..\..\lib\xml.jar;..\..\lib\xmlbeans.jar;..\..\lib\ javac.jar;\..\..\lib\ant-1.3.jar;\..\..\lib\awt.jar;\..\..\lib\codegen.jar;\ ..\. .\lib\crimson.jar;\..\..\lib\javac.jar;\..\..\lib\jaxp.jar;\..\..\lib\jmxri. jar; \..\..\lib\xml.jar;\..\..\lib\xmlbeans.jar;\..\..\build\classes Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/Main Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
RequestID 415472 has been created for this issue on sourceforge. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-415472 ] Identifying JMX services improvement
Bugs item #415472, was updated on 2001-04-11 10:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=415472&group_id=22866 Category: JBossServer Group: v2.3 (unstable) Status: Open Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Identifying JMX services improvement Initial Comment: Currently any mbean that registers with the JBoss MBeanServer is treated as a candidate implementation of the org.jboss.util.Service interface and these methods are invoked on it. This can have bad side affects that range from annoying exceptions being logged to invoking a method that has nothing to do with being a service. There needs to be a better classification of what mbeans are JBoss services. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=415472&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] using jBoss in a production environment?!?
Hi all! Just ported our b2b platform from IAS to jBoss it seems that jBoss is having some performance problems. A simple jsp (in embedded tomcat) reading some entities over a finder method is real slow (table contains only 30 rows!!). Running this jsp with Inprise Application Server you couldn't recognize any action on the server. I am using standard jBoss 2.2 installation with embedded tomcat. Database is running on another server (100 Mbit). Dev-Environment PIII 600 512 MB RAM jdk 1.3 tested on RH7.0 (23 sec) and w2k (9 sec) jdbc-driver: i-net sprinta2000 @ M$-SQL-Server 2000 Having said to my CEOs jBoss is the server to choose, I now have a problem to underline this statement when I have to present my work next week. If I can't fill this lack of performance my boss isn't struggling anymore whether to change the appserver or not. So, jBoss will be dead. :-( Why is jBoss so slow in this case? Are any performance improvements planned in near future? -- Torben << life is short - code hard >> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Object Unique Id Generator
Sorry, it was not meant that the Unique ID is a DB concept but that for regular DBs the Primary Key (and we are here speaking from a "artifical key") is a unique number. I agree that there are other persistent stores which also use a unique ID. But normally you use one persistent store and I think then you should use their ID generator (if available) not only the one from the particular DB. The database ID generator only guarantes that it delivers a unique ID on a request as long as the generator is not tampered. But when you generate the unique ID in an EJB the generation is hidden from the DB and you have to know the state of this EJB to understand how the IDs are generated in the DB. Especially when you change data on a DB level you must change the EJB which is not that easy (especially for a DBA). Have fun - Andy > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 11, 2001 8:37 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > The unique id is not a db concept. The application should have the > flexibility to use multiple persistent stores such as > directory servers, > message queues, files, etc. The id should not be dependent on any one > persistent store for generating id's because it binds the > other persistent > storages to that particular persistent store, the > application itself should > provide id's to reduce coupling between the components of the > system. What > is the benefit of having the id generation inside the > database? At best, the > database can only guarantee database scope uniqueness. > > > Scott > > -Original Message- > From: Jay Walters [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 11, 2001 9:29 AM > To: ''[EMAIL PROTECTED]' ' > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > I think one of the issues here is what type of development is > being done. > If it's for internal use, generally you're already wedded to > a database > product and it's unlikely you'll change due to operational > considerations. > If you're building a product which needs to run with multiple > databases then > you need to address database portability issues. > > Cheers > Jay > > -Original Message- > From: Schaefer, Andreas > To: '[EMAIL PROTECTED]' > Sent: 4/10/01 2:32 PM > Subject: RE: [JBoss-dev] Object Unique Id Generator > > There is a conceptual issue I like to raise here. From my > point of view the "Unique Key" is part of the DB and therefore > under the ownership of the DB. The idea I saw there would > work under some assumptions: > - DB belongs only to the application > - There is no interaction with the DB except through the EJBs > - DB is only the persistence tool > > If you want to add data to the DB through the DB directly > like an import or through a backup. > > The Unique Key is a DB concept and therefore I think the > key generation should remain within the DB. > > Have fun - Andy > > > -Original Message- > > From: Sean Neville [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 10, 2001 11:01 AM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > > > > There are a series of key generation patterns available on > > The Server Side, > > at least one of which requires no databases and no > singletons, and is > > therefore quite portable: > > > > http://www2.theserverside.com/patterns/index.jsp > > > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Schaefer, Andreas > > Sent: Tuesday, April 10, 2001 1:22 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > > > > Hi Geeks > > > > The "FOR UPDATE" is not always necessary as like in Oracle you > > have a sequence generator delivering you an unique ID. > > > > For the other DBs it is maybe better to use a DB procedure or > > function to generate an unique ID than use a SQL Statement. > > > > Have fun - Andy > > > > > -Original Message- > > > From: Emmanuel Sciara [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, April 10, 2001 9:28 AM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] Object Unique Id Generator > > > > > > > > > Hi guys, > > > > > > I have written an advanced key generator for ejbs > > > (http://ejbutils.sourceforge.net/). I would like to > possibly have it > > > blundled with JBoss. For this however, I need a database that > > > supports "FOR > > > UPDATE" sql clauses or transactions with serializable > > isolation level. > > > > > > >From what I know, Hypersonic does not provide that and I > > > moved away from > > > InstantDB early in the process because I had problems with > > > it, so I don't > > > know. > > > > > > So I guess, my question is two fold: > > > - Does JBoss have such database? > > > - If yes, do you think it would be worth blundling this stuff > > > with JBoss. > > > > > > Not
RE: [JBoss-dev] CVS client/ssh
Hello, > Cool, I'm vindicated! > > When Simone imparts his knowledge, I'd be happy to > update the web page if Marc thinks it a good idea... Thanks for that, would really be useful for developers with CVS write access, but I have very little time this period. I don't have cygwin, the following works with plain win2k and winme. Probably will be useful to remove cygwin's ssh.exe from %PATH% environment variable to avoid some mess. Unfortunately there is no solution yet for being behind a firewall, ssh does not work. If someone has a solution for this, please share it !! The following will only work for jboss' developers that have CVS write access to the CVS jboss repository. Sooo, here it is ;) 1) Go to http://download.sourceforge.net/sfsetup/sfsetup-v1.2.zip and download it. Unzip it. When unzipped, there is another zipped file, called ssh-1.2.14-win32bin.zip. Unzip also this in a well-known directory (mine is D:\Simon\ssh\). In there there should be now 5 files, one of them being ssh.exe. Only these 5 files should be kept, you can delete all the other unzipped files. 2) Create a passwd file under C:\etc as explained in bullet 5 at http://sourceforge.net/docman/display_doc.php?docid=767&group_id=1. Follow only instruction at bullet 5. 3) Open a Windows console and go in the directory where you unzipped ssh.exe (I would do 'cd \Simon\ssh'). 4) If you don't have a global HOME environment variable, set it in the console. I would do 'set HOME=D:\Simon'. If you don't do this, ssh will complain (while executing the next step) that it cannot create the directory 'NULL/.ssh' or something like that. 5) Now connect with sourceforge. Type the following: ssh -l jboss.sourceforge.net and enter your password. You should get a unix-like after-login window. Type exit and come back to the Windows console. Then type: ssh -l cvs.jboss.sourceforge.net and enter your password. Again the unix-like after-login window. Type exit and come back to the Windows console. These 2 commands created a .ssh directory (please note the dot before ssh) under %HOME% and 2 files in it. These files are required by WinCVS. 6) Close the console. Open WinCVS. From the menu bar, Admin/Preferences. In the 'General' tab, set the CVSROOT to be :ext:@cvs.jboss.sourceforge.net:/cvsroot/jboss, authentication 'SSH server' 7) In the Preferences dialog, tab 'Ports', select the checkbox 'Chek for an alternate rsh name' and fill the textbox with the full path of ssh.exe (mine is D:\Simon\ssh\ssh.exe). Click OK. 8) From main menu bar, Create/Checkout module, fill the dialog box, then click OK. It will appear a minimized console (so you will only see it in the taskbar or with Alt-Tab): you should un-minimize it, it will appear completely empty. Type in there your sourceforge password and then enter. If you switch back to WinCVS, you'll see that the checkout begins, and the password console stays there until the CVS command is finished. You have to retype your password in an empty console for each CVS command (there is a way to avoid also this but I did not try it). Enjoy ! Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Object Unique Id Generator
You are right that a unique identifier is not a database specific concept, and that unique id bean is a good tool to have in your toolbox. Sometimes, like when using LDAP or message queues you're going to need it. However if I am storing my data in an RDBMS (like most EJB developers will be) why not use the RDBMS' built in facilities for generating unique keys. If the data is persisted into the RDBMS it must be there for the application to run (persist new data or load old data). RDBMS products have been making unique ids efficiently since the client server days. I just don't buy this super size distributed enterprise needs GUIDs from a separate session bean thing for every application using EJBs. A lot of EJB applications will benefit from simple design (IMHO database generated keys fit this bill, but it's religion) and don't need all this stuff. Besides, if you decide to change things, then change the unique ID generation. It's not as if you're just going to take an application that works with Oracle and plug it into a LDAP server or a message store. Sorry, I've never seen it. In any application that has been optimized in terms of data access there is always some database specific tuning involved and this likely won't work on the next one. In terms of coupling, I think once you deploy the application most users are coupled to the database. The developers might say, "Ha this baby is 100% portable it'll run anywhere," but the DBAs who only know SQL Server or ORACLE and aren't in a hurry to migrate 200 GB of data probably know the score. Most companies don't move internal apps around without good reason, nor do they do it frequently. There is a small set of applications that will benefit from using a seperate bean for the enterprise super scalable thing, and a larger set of applications using databases on the low end which don't have efficient mechansisms for generating unique ids who will also benefit, but most people building real IS/IT applications IMHO should be using database generated unique ids where it makes sense, e.g. when storing the data into an RDBMS. Cheers Jay -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 4/11/01 11:37 AM Subject: RE: [JBoss-dev] Object Unique Id Generator The unique id is not a db concept. The application should have the flexibility to use multiple persistent stores such as directory servers, message queues, files, etc. The id should not be dependent on any one persistent store for generating id's because it binds the other persistent storages to that particular persistent store, the application itself should provide id's to reduce coupling between the components of the system. What is the benefit of having the id generation inside the database? At best, the database can only guarantee database scope uniqueness. Scott ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
Just to add my 2c again I don't think this is really related to how a MBean is implement. Standard, Dynamic, Model or Open MBeans may all be used in a JBoss MBeanServer and each may either be a JBoss service or not. The point is that JBoss should only call init() on MBeans that are JBoss services - regardless of how they are implemented. Presence of an init() method is not really a good enough test for a JBoss service, it is a bit of a universal method name to claim as a unique JBoss service. Julians idea of an isAJBossServer() method is good (except that I prefer the name isJBossServer() ) If JBoss wants to allow components to use MBeans to manage themselves OR if you want JBoss components are to be used in larger JMX frameworks then you must do something to detect JBoss MBeans and only attempt to auto manage them. cheers Julian Gosnell wrote: > --- Juha-P Lindfors <[EMAIL PROTECTED]> wrote: > >> >>On Wed, 11 Apr 2001, Julian Gosnell wrote: >> >>>AFAIK, the advantage of Dynamic MBeans is that >>> >>they >> >>>are not statically constrained by inheritance and >>> >>may >> >>>vary their interfaces dynamically at run time. >>> >>>Both of these demonstrate the inadequacy of simply >>>checking the inheritance of a potential Service >>> >>MBean >> >>Actually I don't believe this to be true. Dynamic >>MBeans can determine >>their management interface at runtime, for example >>by reading an XML >>file. This allows the management interface to be >>changed without >>recompiling. But they should not vary the interface >>during their life >> > > OK - I agree - my mistaken assumption. The way they > are coded leaves a gap which MAY be exploited to do > this, however the JMX spec states DynamicMBeans SHOULD > not do so. > > >>time. A management application can expect the >>management interface to stay >>the same during the life time of the MBean, once it >>has retrieved it from the >>agent. The agent is not required to enforce this >>static interface, so it >>is possible to build dynamic mbeans that do vary >>their interfaces but this >>can only be done with proprietary management >>applications. Compliant JMX >>applications can't be expected to work. >> >> > >>So I still think checking for the Service interface >>is good enough for >>solving the Jetty integration problem. For fancier >>life cycle management, >>I think Stacy already has the base work done (via >>xmlets) and that is a >>very interesting work, but not required for this >>particular problem at >>hand :) >> >> > > I still think that it should be up to a DynamicMBean > at runtime whether or not it wishes to be managed by > ControlService (otherwise what is the point of being a > DynamicMBean?). > > If you simply look at it's inheritance you constrain > this decision to compile time. > > If you configure it in a file you constrain it to > deploy-time. > > What is more complicated, less efficient or wrong > about making the decision at run-time ? > > I think I'll rest my case here and wait to see what > actually gets implemented. > > I look forward to seeing my JettyMBeans working > harmoniously with JBossMBeans. > > > Thanks everyone for all the input. I hope we didn't > consume to much bandwidth. > > Catch you all later, > > > Jules > > > >>-- Juha >> >> >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >> >> > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > __ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Release date for 2.2
Title: Release date for 2.2 Is there somewhere a list of project milestones that would detail the release date for Jboss 2.2? Thanks Dave Bolt There is always plenty of bandwidth, just none for you.
RE: [JBoss-dev] Nested JMX Service Groups...??!
--- Juha-P Lindfors <[EMAIL PROTECTED]> wrote: > > > On Wed, 11 Apr 2001, Julian Gosnell wrote: > > AFAIK, the advantage of Dynamic MBeans is that > they > > are not statically constrained by inheritance and > may > > vary their interfaces dynamically at run time. > > > > Both of these demonstrate the inadequacy of simply > > checking the inheritance of a potential Service > MBean > > Actually I don't believe this to be true. Dynamic > MBeans can determine > their management interface at runtime, for example > by reading an XML > file. This allows the management interface to be > changed without > recompiling. But they should not vary the interface > during their life OK - I agree - my mistaken assumption. The way they are coded leaves a gap which MAY be exploited to do this, however the JMX spec states DynamicMBeans SHOULD not do so. > time. A management application can expect the > management interface to stay > the same during the life time of the MBean, once it > has retrieved it from the > agent. The agent is not required to enforce this > static interface, so it > is possible to build dynamic mbeans that do vary > their interfaces but this > can only be done with proprietary management > applications. Compliant JMX > applications can't be expected to work. > > So I still think checking for the Service interface > is good enough for > solving the Jetty integration problem. For fancier > life cycle management, > I think Stacy already has the base work done (via > xmlets) and that is a > very interesting work, but not required for this > particular problem at > hand :) > I still think that it should be up to a DynamicMBean at runtime whether or not it wishes to be managed by ControlService (otherwise what is the point of being a DynamicMBean?). If you simply look at it's inheritance you constrain this decision to compile time. If you configure it in a file you constrain it to deploy-time. What is more complicated, less efficient or wrong about making the decision at run-time ? I think I'll rest my case here and wait to see what actually gets implemented. I look forward to seeing my JettyMBeans working harmoniously with JBossMBeans. Thanks everyone for all the input. I hope we didn't consume to much bandwidth. Catch you all later, Jules > -- Juha > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Object Unique Id Generator
The unique id is not a db concept. The application should have the flexibility to use multiple persistent stores such as directory servers, message queues, files, etc. The id should not be dependent on any one persistent store for generating id's because it binds the other persistent storages to that particular persistent store, the application itself should provide id's to reduce coupling between the components of the system. What is the benefit of having the id generation inside the database? At best, the database can only guarantee database scope uniqueness. Scott -Original Message- From: Jay Walters [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 11, 2001 9:29 AM To: ''[EMAIL PROTECTED]' ' Subject: RE: [JBoss-dev] Object Unique Id Generator I think one of the issues here is what type of development is being done. If it's for internal use, generally you're already wedded to a database product and it's unlikely you'll change due to operational considerations. If you're building a product which needs to run with multiple databases then you need to address database portability issues. Cheers Jay -Original Message- From: Schaefer, Andreas To: '[EMAIL PROTECTED]' Sent: 4/10/01 2:32 PM Subject: RE: [JBoss-dev] Object Unique Id Generator There is a conceptual issue I like to raise here. From my point of view the "Unique Key" is part of the DB and therefore under the ownership of the DB. The idea I saw there would work under some assumptions: - DB belongs only to the application - There is no interaction with the DB except through the EJBs - DB is only the persistence tool If you want to add data to the DB through the DB directly like an import or through a backup. The Unique Key is a DB concept and therefore I think the key generation should remain within the DB. Have fun - Andy > -Original Message- > From: Sean Neville [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 10, 2001 11:01 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > There are a series of key generation patterns available on > The Server Side, > at least one of which requires no databases and no singletons, and is > therefore quite portable: > > http://www2.theserverside.com/patterns/index.jsp > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Schaefer, Andreas > Sent: Tuesday, April 10, 2001 1:22 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > Hi Geeks > > The "FOR UPDATE" is not always necessary as like in Oracle you > have a sequence generator delivering you an unique ID. > > For the other DBs it is maybe better to use a DB procedure or > function to generate an unique ID than use a SQL Statement. > > Have fun - Andy > > > -Original Message- > > From: Emmanuel Sciara [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 10, 2001 9:28 AM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] Object Unique Id Generator > > > > > > Hi guys, > > > > I have written an advanced key generator for ejbs > > (http://ejbutils.sourceforge.net/). I would like to possibly have it > > blundled with JBoss. For this however, I need a database that > > supports "FOR > > UPDATE" sql clauses or transactions with serializable > isolation level. > > > > >From what I know, Hypersonic does not provide that and I > > moved away from > > InstantDB early in the process because I had problems with > > it, so I don't > > know. > > > > So I guess, my question is two fold: > > - Does JBoss have such database? > > - If yes, do you think it would be worth blundling this stuff > > with JBoss. > > > > Note: the source is a bit out of date on sourceforge but I am > > working on it. > > I have a fully JBoss-deployable version if you are interested. > > > > Emmanuel > > > > > From: "marc fleury" <[EMAIL PROTECTED]> > > > > post this to jboss-dev, I remember there is a key > > generator somewhere > > but > > > > yours might be more advanced. if you generate some > > interest there, you > > > are > > > > on > > > > > > > > marc > > > > > > > > > > > > |-Original Message- > > > > |From: Emmanuel Sciara [mailto:[EMAIL PROTECTED]] > > > > |Sent: Friday, April 06, 2001 10:31 AM > > > > |To: marc fleury > > > > |Subject: Re: Thanks > > > > | > > > > | > > > > |Hey! > > > > | > > > > |Cool Idea! I am interested for sure. Just tell me where > > to find the > > right > > > > |sample code and I am of! (if you can do that easily > > enough, that would > > > save > > > > |me some time) > > > > | > > > > |Just need to modify my sql so it does not use "For > > Update", which is > > not > > > > |supported by Hypersonic. I would like to write some doc > > too. But I > > guess > > > > |that can wait if I send some explanation mail to the list. > > > > | > > > > |Any other suggestion you would have? > > > > | > > > > |Emmanuel > > > > | > > > > |- Original Message - > > > > |F
RE: [JBoss-dev] CVS client/ssh
Simone, EXCELLENT, thank you! waiting, waiting, waiting... :-) --- "Bordet, Simone" <[EMAIL PROTECTED]> wrote: > Peter, > > I have WinCVS working fine with ssh, and I know how > to setup everything (I > had to do some more tweak WRT SF's docs) > Just give me few hours, right now I'm busy, but for > today you'll get it > working, promised ! > > Simon > __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS client/ssh
Cool, I'm vindicated! When Simone imparts his knowledge, I'd be happy to update the web page if Marc thinks it a good idea... peter --- Peter Spicer <[EMAIL PROTECTED]> wrote: > Simon, > > That would be great as I also am having the same > types of problems. TIA. > > Peter # 2 > > > Peter, > > > > I have WinCVS working fine with ssh, and I know > how to setup everything (I > > had to do some more tweak WRT SF's docs) > > Just give me few hours, right now I'm busy, but > for today you'll get it > > working, promised ! > > > > Simon > > __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Patches-415321 ] RAR Instance Deployer for jbosscx
OOPS!
I inadvertantly broke the .jcml xml below while trying to add an
explanatory comment. Sorry.
Fixed below
Would it make any sense to configure instances of AutoDeployer to look for
specific extensions? So the next time we have a new deployer for .xyz
files we set up a autodeployer to look only for them?
Thanks
david
On 2001.04.11 10:39:18 -0400 David Jencks wrote:
> Hi,
>
> My goal of stimulating someone to find a better solution worked great!
> Thanks, Toby.
>
> I also added around line 139
>
// Check if it's a JAR or zip or ear or war
if (!(fileUrl.getFile().endsWith(".jar") ||
fileUrl.getFile().endsWith(".ear") ||
fileUrl.getFile().endsWith(".war") ||
fileUrl.getFile().endsWith(".rar") ||
fileUrl.getFile().endsWith(".zip")))
continue; // Was not a JAR or zip - skip it...
>
> to make .rar files auto-recognizable
>
> and my jboss.jcml has
>
(fixed xml)
JCA:service=RARDeployer
../deploy/resource/
J2EE:service=J2eeDeployer
../deploy
> so that JCA resources are autodeployed BEFORE any apps that might use
> them.
>
>
>
> Would you consider putting these small changes into CVS?
>
>
> Thanks!
> David Jencks
>
> On 2001.04.11 04:36:29 -0400 Toby Allsopp wrote:
> > Toby Allsopp wrote:
> >
> > > Or or!!! Why not just start another AutoDeployer pointing at, say,
> > > deploy/resource, that talks to RARDeployer instead of J2EEDeployer?
> > >
> > > I'll try that last one and let you know.
> >
> > Ok, after modifying AutoDeployer slightly, this works (although it
> > reveals a bug in RARDeployer that means that you can't redeploy
> resource
> > adapters).
> >
> > I just addded this after the RARDeployer entry in jboss.jcml:
> >
> >> name="JCA:service=AutoDeployer">
> > JCA:service=RARDeployer
> > ../deploy/resource/minerva-jdbc-1.0b3.rar
> >
> >
> > It won't work for watching directories unless AutoDeployer is modified
> > even further to recognise .rar files as deployable. That patch is left
> > as an exercise for the reader :-).
> >
> > Here's the AutoDeployer patch that makes watching single files work:
> >
> > @@ -292,13 +293,6 @@
> > }
> > } else if (urlFile.exists()) // It's a file
> > {
> > - // Check if it's a JAR or zip
> > - if (!(url.endsWith(".jar") ||
> > - url.endsWith(".ear") ||
> > - url.endsWith(".war") ||
> > - url.endsWith(".zip")))
> > - continue; // Was not a JAR or zip - skip it...
> > -
> > try
> > {
> >watchedURLs.add(new
> > Deployment(urlFile.getCanonicalFile().toURL()));
> > @@ -309,13 +303,6 @@
> > }
> > } else // It's a real URL (probably http:)
> > {
> > -// Check if it's a JAR or zip
> > -if (!(url.endsWith(".jar") ||
> > - url.endsWith(".ear") ||
> > - url.endsWith(".war") ||
> > - url.endsWith(".zip")))
> > - continue; // Was not a JAR or zip - skip it...
> > -
> > try
> > {
> > watchedURLs.add(new Deployment(new URL(url)));
> > @@ -402,7 +389,9 @@
> > this.url = url;
> > if (url.getFile().endsWith(".jar") ||
> > url.getFile().endsWith(".ear") ||
> > - url.getFile().endsWith(".war"))
> > + url.getFile().endsWith(".war") ||
> > + (url.getProtocol().startsWith("file") &&
> > + !new File(url.getFile()).isDirectory()))
> > watch = url;
> > else
> > watch = new URL(url, "META-INF/ejb-jar.xml");
> >
> > Toby.
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??!
Hi, Whatever solution you decide on for this problem, I think it could be a good idea to replace the current MLet MBean-loader with Stacy's XML-based XMLet. Just my 2 irish cents, David. -Original Message- From: Stacy Curl [mailto:[EMAIL PROTECTED]] Sent: 11 April 2001 15:33 To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??! Ok, sorry for the misunderstanding. I think that putting extra methods onto JBoss MBeans is one technique, but this is an example of meta-data. I think a better technique would be to do something like: // My XML is rusty &JbossServiceEntry; &JettyEntry; &JbossServiceEntry; &FlibbleLifeCycleEntry; where JBossServiceEntry is: JBossService true ]]> life-cycle-start init start ]]> This moves the burden from MBean's to the config, and it gives you the ability to change what is considered to be a JBossService without changing code. -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: 11 April 2001 12:00 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??! Stacy, I like your idea of abstracting the lifecycle mapping. However, as I understand your description here, it still does not address my problem. You suggest that in the absence of valid metadata, you would assume the default lifecycle (I assume you mean default JBoss Service lifecycle). The problem is that not all MBeans that may wish to publish their interface via the JBoss JMX agent necessarily want their lifecycle managed by ServiceControl. They may not be a Service. I suggest that the default behaviour should be _NOT_ to assume that every registered MBean is a Service. Services should publish a method - e.g. isAJBossService(), which can be looked for by ServiceControl. This could be added to Service, implemented in MBeanServiceSupport etc, bringing most MBeans used in JBoss into the fold. 3rd party MBeans developed outside JBoss, but finding themselves running inside JBoss would then be free to share the JBoss JMX Agent, without fear of being tampered with by ServiceControl. I am asking for a clear division between JMX and JBoss Services. JBoss Services may be MBeans, but not all MBeans are JBoss Services. I hope this makes sense, Jules --- Stacy Curl <[EMAIL PROTECTED]> wrote: > I think that having an abstract life cycle of: init, > start, ping, stop, > destroy > is ok, but constraining MBeans to implement init(), > start(), ping(), stop(), > destroy() > methods is not ok. So I think replacing a service is > a mistake but > abstracting parts > of it isn't. So the ServiceControl would continue to > listen for registration > of MBeans > and be responsible for doing init, etc but would > first obtain the actual > methods to > call from the MetaDataService, in the absence of any > life-cycle meta-data > the ServiceControl > would default to the standard methods, at present > there are work arounds > such as catching > ReflectionExceptions after invoking 'start' and > assuming (rightly or > wrongly) that this means > the MBean doesn't have a start method. > > I think that ServiceControl doesn't manage > dependancies, it just aggregates > MBeans. The dependancies > seem to be implicit in the order in the MLet > resource file. This is ok if > you want to start/stop all > the mbeans but not if you want to start/stop a > subset. I think we should be > following the style in ant > and do something like: > > depends="really-important"/> > > -Original Message- > From: Scott M Stark > [mailto:[EMAIL PROTECTED]] > Sent: 10 April 2001 23:57 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Custom startup solved !? > was: Nested JMX > Service Groups...??! > > > Are you talking about a new service that replaces > org.jboss.util.ServiceControl or > a new service? The ServiceControl MBean that manages > service lifecyle also > manages service dependencies and the invocation of > init() and start() are > distinct > phases. When start is called on a service you know > that every service has > received an init() and every service you depend on > has received a start(). > > - Original Message - > From: "Stacy Curl" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; > "'Julian Gosnell'" > <[EMAIL PROTECTED]> > Sent: Tuesday, April 10, 2001 2:09 PM > Subject: RE: [JBoss-dev] Custom startup solved !? > was: Nested JMX Service > Groups...??! > > > > I think that the JBoss inspired life-cycle is too > restrictive, I'd > > like to be able to define life-cycle schemas in > the XMLet resource > > file, or in another XML file. An XMLet version > might look something > > like: > > > > > >code="com.sun.jdmk.com
RE: [JBoss-dev] CVS client/ssh
Simon, That would be great as I also am having the same types of problems. TIA. Peter # 2 > Peter, > > I have WinCVS working fine with ssh, and I know how to setup everything (I > had to do some more tweak WRT SF's docs) > Just give me few hours, right now I'm busy, but for today you'll get it > working, promised ! > > Simon > > > -Original Message- > > From: Peter Braswell [[EMAIL PROTECTED]] > > Sent: mercoledi 11 aprile 2001 14:58 > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] CVS client/ssh > > > > > > All, > > I hate to bother everybody with a stupid question, > > but... > > > > I've been having a devil of a time with > > sourceforge/CVS/ssh and getting to the point where I > > can commit. > > > > I'm using a W2K machine. I've tried jCVS (no support > > for ssh), winCVS (seems to support ssh, but won't work > > properly) and cygwin's command line CVS from within > > the Unix shell. Nothing seems to work. > > > > I very carefully followed the directions on the jboss > > link to sourceforge and the cvs how-to. > > > > Does anybody have a concise, set-up for winCVS or > > something similar you might be able to pass along? > > Actually it doesn't really even have to be winCVS, > > anything that would easily set up on a windows > > machine. > > > > thanks everybody! > > peter > > > > __ > > Do You Yahoo!? > > Get email at your own domain with Yahoo! Mail. > > http://personal.mail.yahoo.com/ > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development Powered by the Email PIM - Info Select - www.miclog.com ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS client/ssh
Peter, I have WinCVS working fine with ssh, and I know how to setup everything (I had to do some more tweak WRT SF's docs) Just give me few hours, right now I'm busy, but for today you'll get it working, promised ! Simon > -Original Message- > From: Peter Braswell [mailto:[EMAIL PROTECTED]] > Sent: mercoledi 11 aprile 2001 14:58 > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] CVS client/ssh > > > All, > I hate to bother everybody with a stupid question, > but... > > I've been having a devil of a time with > sourceforge/CVS/ssh and getting to the point where I > can commit. > > I'm using a W2K machine. I've tried jCVS (no support > for ssh), winCVS (seems to support ssh, but won't work > properly) and cygwin's command line CVS from within > the Unix shell. Nothing seems to work. > > I very carefully followed the directions on the jboss > link to sourceforge and the cvs how-to. > > Does anybody have a concise, set-up for winCVS or > something similar you might be able to pass along? > Actually it doesn't really even have to be winCVS, > anything that would easily set up on a windows > machine. > > thanks everybody! > peter > > __ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Object Unique Id Generator
I think one of the issues here is what type of development is being done. If it's for internal use, generally you're already wedded to a database product and it's unlikely you'll change due to operational considerations. If you're building a product which needs to run with multiple databases then you need to address database portability issues. Cheers Jay -Original Message- From: Schaefer, Andreas To: '[EMAIL PROTECTED]' Sent: 4/10/01 2:32 PM Subject: RE: [JBoss-dev] Object Unique Id Generator There is a conceptual issue I like to raise here. From my point of view the "Unique Key" is part of the DB and therefore under the ownership of the DB. The idea I saw there would work under some assumptions: - DB belongs only to the application - There is no interaction with the DB except through the EJBs - DB is only the persistence tool If you want to add data to the DB through the DB directly like an import or through a backup. The Unique Key is a DB concept and therefore I think the key generation should remain within the DB. Have fun - Andy > -Original Message- > From: Sean Neville [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 10, 2001 11:01 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > There are a series of key generation patterns available on > The Server Side, > at least one of which requires no databases and no singletons, and is > therefore quite portable: > > http://www2.theserverside.com/patterns/index.jsp > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Schaefer, Andreas > Sent: Tuesday, April 10, 2001 1:22 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > Hi Geeks > > The "FOR UPDATE" is not always necessary as like in Oracle you > have a sequence generator delivering you an unique ID. > > For the other DBs it is maybe better to use a DB procedure or > function to generate an unique ID than use a SQL Statement. > > Have fun - Andy > > > -Original Message- > > From: Emmanuel Sciara [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 10, 2001 9:28 AM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] Object Unique Id Generator > > > > > > Hi guys, > > > > I have written an advanced key generator for ejbs > > (http://ejbutils.sourceforge.net/). I would like to possibly have it > > blundled with JBoss. For this however, I need a database that > > supports "FOR > > UPDATE" sql clauses or transactions with serializable > isolation level. > > > > >From what I know, Hypersonic does not provide that and I > > moved away from > > InstantDB early in the process because I had problems with > > it, so I don't > > know. > > > > So I guess, my question is two fold: > > - Does JBoss have such database? > > - If yes, do you think it would be worth blundling this stuff > > with JBoss. > > > > Note: the source is a bit out of date on sourceforge but I am > > working on it. > > I have a fully JBoss-deployable version if you are interested. > > > > Emmanuel > > > > > From: "marc fleury" <[EMAIL PROTECTED]> > > > > post this to jboss-dev, I remember there is a key > > generator somewhere > > but > > > > yours might be more advanced. if you generate some > > interest there, you > > > are > > > > on > > > > > > > > marc > > > > > > > > > > > > |-Original Message- > > > > |From: Emmanuel Sciara [mailto:[EMAIL PROTECTED]] > > > > |Sent: Friday, April 06, 2001 10:31 AM > > > > |To: marc fleury > > > > |Subject: Re: Thanks > > > > | > > > > | > > > > |Hey! > > > > | > > > > |Cool Idea! I am interested for sure. Just tell me where > > to find the > > right > > > > |sample code and I am of! (if you can do that easily > > enough, that would > > > save > > > > |me some time) > > > > | > > > > |Just need to modify my sql so it does not use "For > > Update", which is > > not > > > > |supported by Hypersonic. I would like to write some doc > > too. But I > > guess > > > > |that can wait if I send some explanation mail to the list. > > > > | > > > > |Any other suggestion you would have? > > > > | > > > > |Emmanuel > > > > | > > > > |- Original Message - > > > > |From: "marc fleury" <[EMAIL PROTECTED]> > > > > |To: "Emmanuel Sciara" <[EMAIL PROTECTED]> > > > > |Sent: Thursday, April 05, 2001 6:28 PM > > > > |Subject: Thanks > > > > | > > > > | > > > > |> for removing the documentation from the website, > > > > |> > > > > |> also did you think about implementing the high/low > pattern and > > > > |putting it > > > > |> as an MBean (or Bean) in JBoss? > > > > |> > > > > |> let me know if interested let the list know and see if > > they want it. > > > > |> > > > > |> marc > > > > |> > > > > |> > > > > |> _ > > > > |> Marc Fleury, Ph.D > > > > |> [EMAIL PROTECTED] > > > > |> _ > > > > | > > > > > > > > > > > > > > ___ > > Jboss-development mail
Re: [JBoss-dev] [ jboss-Patches-415321 ] RAR Instance Deployer for jbosscx
Hi,
My goal of stimulating someone to find a better solution worked great!
Thanks, Toby.
I also added around line 139
// Check if it's a JAR or zip or ear or war
if (!(fileUrl.getFile().endsWith(".jar") ||
fileUrl.getFile().endsWith(".ear") ||
fileUrl.getFile().endsWith(".war") ||
fileUrl.getFile().endsWith(".rar") ||
fileUrl.getFile().endsWith(".zip")))
continue; // Was not a JAR or zip - skip it...
to make .rar files auto-recognizable
and my jboss.jcml has
JCA:service=RARDeployer
../deploy/resource/
J2EE:service=J2eeDeployer
../deploy
so that JCA resources are autodeployed BEFORE any apps that might use them.
Would you consider putting these small changes into CVS?
Thanks!
David Jencks
On 2001.04.11 04:36:29 -0400 Toby Allsopp wrote:
> Toby Allsopp wrote:
>
> > Or or!!! Why not just start another AutoDeployer pointing at, say,
> > deploy/resource, that talks to RARDeployer instead of J2EEDeployer?
> >
> > I'll try that last one and let you know.
>
> Ok, after modifying AutoDeployer slightly, this works (although it
> reveals a bug in RARDeployer that means that you can't redeploy resource
> adapters).
>
> I just addded this after the RARDeployer entry in jboss.jcml:
>
>name="JCA:service=AutoDeployer">
> JCA:service=RARDeployer
> ../deploy/resource/minerva-jdbc-1.0b3.rar
>
>
> It won't work for watching directories unless AutoDeployer is modified
> even further to recognise .rar files as deployable. That patch is left
> as an exercise for the reader :-).
>
> Here's the AutoDeployer patch that makes watching single files work:
>
> @@ -292,13 +293,6 @@
> }
> } else if (urlFile.exists()) // It's a file
> {
> - // Check if it's a JAR or zip
> - if (!(url.endsWith(".jar") ||
> - url.endsWith(".ear") ||
> - url.endsWith(".war") ||
> - url.endsWith(".zip")))
> - continue; // Was not a JAR or zip - skip it...
> -
> try
> {
>watchedURLs.add(new
> Deployment(urlFile.getCanonicalFile().toURL()));
> @@ -309,13 +303,6 @@
> }
> } else // It's a real URL (probably http:)
> {
> -// Check if it's a JAR or zip
> -if (!(url.endsWith(".jar") ||
> - url.endsWith(".ear") ||
> - url.endsWith(".war") ||
> - url.endsWith(".zip")))
> - continue; // Was not a JAR or zip - skip it...
> -
> try
> {
> watchedURLs.add(new Deployment(new URL(url)));
> @@ -402,7 +389,9 @@
> this.url = url;
> if (url.getFile().endsWith(".jar") ||
> url.getFile().endsWith(".ear") ||
> - url.getFile().endsWith(".war"))
> + url.getFile().endsWith(".war") ||
> + (url.getProtocol().startsWith("file") &&
> + !new File(url.getFile()).isDirectory()))
> watch = url;
> else
> watch = new URL(url, "META-INF/ejb-jar.xml");
>
> Toby.
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??!
Ok, sorry for the misunderstanding. I think that putting extra methods onto JBoss MBeans is one technique, but this is an example of meta-data. I think a better technique would be to do something like: // My XML is rusty &JbossServiceEntry; &JettyEntry; &JbossServiceEntry; &FlibbleLifeCycleEntry; where JBossServiceEntry is: JBossService true ]]> life-cycle-start init start ]]> This moves the burden from MBean's to the config, and it gives you the ability to change what is considered to be a JBossService without changing code. -Original Message- From: Julian Gosnell [mailto:[EMAIL PROTECTED]] Sent: 11 April 2001 12:00 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??! Stacy, I like your idea of abstracting the lifecycle mapping. However, as I understand your description here, it still does not address my problem. You suggest that in the absence of valid metadata, you would assume the default lifecycle (I assume you mean default JBoss Service lifecycle). The problem is that not all MBeans that may wish to publish their interface via the JBoss JMX agent necessarily want their lifecycle managed by ServiceControl. They may not be a Service. I suggest that the default behaviour should be _NOT_ to assume that every registered MBean is a Service. Services should publish a method - e.g. isAJBossService(), which can be looked for by ServiceControl. This could be added to Service, implemented in MBeanServiceSupport etc, bringing most MBeans used in JBoss into the fold. 3rd party MBeans developed outside JBoss, but finding themselves running inside JBoss would then be free to share the JBoss JMX Agent, without fear of being tampered with by ServiceControl. I am asking for a clear division between JMX and JBoss Services. JBoss Services may be MBeans, but not all MBeans are JBoss Services. I hope this makes sense, Jules --- Stacy Curl <[EMAIL PROTECTED]> wrote: > I think that having an abstract life cycle of: init, > start, ping, stop, > destroy > is ok, but constraining MBeans to implement init(), > start(), ping(), stop(), > destroy() > methods is not ok. So I think replacing a service is > a mistake but > abstracting parts > of it isn't. So the ServiceControl would continue to > listen for registration > of MBeans > and be responsible for doing init, etc but would > first obtain the actual > methods to > call from the MetaDataService, in the absence of any > life-cycle meta-data > the ServiceControl > would default to the standard methods, at present > there are work arounds > such as catching > ReflectionExceptions after invoking 'start' and > assuming (rightly or > wrongly) that this means > the MBean doesn't have a start method. > > I think that ServiceControl doesn't manage > dependancies, it just aggregates > MBeans. The dependancies > seem to be implicit in the order in the MLet > resource file. This is ok if > you want to start/stop all > the mbeans but not if you want to start/stop a > subset. I think we should be > following the style in ant > and do something like: > > depends="really-important"/> > > -Original Message- > From: Scott M Stark > [mailto:[EMAIL PROTECTED]] > Sent: 10 April 2001 23:57 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Custom startup solved !? > was: Nested JMX > Service Groups...??! > > > Are you talking about a new service that replaces > org.jboss.util.ServiceControl or > a new service? The ServiceControl MBean that manages > service lifecyle also > manages service dependencies and the invocation of > init() and start() are > distinct > phases. When start is called on a service you know > that every service has > received an init() and every service you depend on > has received a start(). > > - Original Message - > From: "Stacy Curl" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; > "'Julian Gosnell'" > <[EMAIL PROTECTED]> > Sent: Tuesday, April 10, 2001 2:09 PM > Subject: RE: [JBoss-dev] Custom startup solved !? > was: Nested JMX Service > Groups...??! > > > > I think that the JBoss inspired life-cycle is too > restrictive, I'd > > like to be able to define life-cycle schemas in > the XMLet resource > > file, or in another XML file. An XMLet version > might look something > > like: > > > > > >code="com.sun.jdmk.comm.HtmlAdaptorServer" > > archive="jmxtools.jar" > > > name="DefaultDomain:name=HtmlAdaptorServer"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 500 > > > > > > true > >
Re: [JBoss-dev] CVS client/ssh
Juha, Thanks for getting back with me. Cygwin works to a point: CVS_RSH=ssh cvs -d :ext:@cvs.jboss.sourceforge.net:/cvsroot/jb error: cannot chdir /home/users/p/pe/peterbraswell weird? frustrating? --- Juha-P Lindfors <[EMAIL PROTECTED]> wrote: > > > On Wed, 11 Apr 2001, Peter Braswell wrote: > > I'm using a W2K machine. I've tried jCVS (no > support > > for ssh), winCVS (seems to support ssh, but won't > work > > properly) and cygwin's command line CVS from > within > > the Unix shell. Nothing seems to work. > > Cygwin pretty much works out of the box for me on > NT4. What sort of > problems were you having with it? > > export CVS_RSH=ssh > cvs -d > :ext:@cvs.jboss.sourceforge.net:/cvsroot/jboss > co jboss > > > > cvs commit > > > > > :wq > > done > > -- Juha > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Nested JMX Service Groups...??!
On Wed, 11 Apr 2001, Julian Gosnell wrote: > AFAIK, the advantage of Dynamic MBeans is that they > are not statically constrained by inheritance and may > vary their interfaces dynamically at run time. > > Both of these demonstrate the inadequacy of simply > checking the inheritance of a potential Service MBean Actually I don't believe this to be true. Dynamic MBeans can determine their management interface at runtime, for example by reading an XML file. This allows the management interface to be changed without recompiling. But they should not vary the interface during their life time. A management application can expect the management interface to stay the same during the life time of the MBean, once it has retrieved it from the agent. The agent is not required to enforce this static interface, so it is possible to build dynamic mbeans that do vary their interfaces but this can only be done with proprietary management applications. Compliant JMX applications can't be expected to work. So I still think checking for the Service interface is good enough for solving the Jetty integration problem. For fancier life cycle management, I think Stacy already has the base work done (via xmlets) and that is a very interesting work, but not required for this particular problem at hand :) -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE:I am a new user of JBoss and the following bug appears:
Hello friends , I am new to Jboss and when I start the jBoss server , I get the following message about a JMX detection in the server log file. What does this mean and how can this cause a problem?? Could someone help me? [Configuration] Detected JMX Bug: Server reports attribute 'ConnectionManagerFactoryName' is not writeable for MBean 'JCA:name=BlackBoxDS,service=ConnectionFactoryLoader' thnx and regds hsk ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
> This would have the additional advantage of allowing a
> Service that does inherit from Service to opt out of
> the JBoss lifecycle by returning 'false'. Furthermore
> it would allow dynamic MBeans to make the decision
> dynamically, instead of statically, which on further
> consideration I think is probably the best argument
> for the method. DynamicMBeans are allowed to vary
> their interfaces during their lifetime. This may well
> impact on the availability of their JBoss Service
> interface, so they need to be able to indicate this to
> JBoss.
>
> I don't think you can achieve this same dynamicity and
> simplicity by checking inheritance or naming schemes.
>
> Anyone ?
>
Aha nice, very nice. This solution is much more flexible and better. I see
your point clearly.
Vladimir
>
> Jules
>
> --- "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
> > Hey ppl,
> >
> > On Wed, 11 Apr 2001, Julian Gosnell wrote:
> >
> > > I think that Services should publish 'boolean
> > > isAJBossService() {return true;}' method.
> > >
> > > This could be implemented in MBeanServiceSupport
> > for
> > > standard Service MBeans. Dynamic Service MBeans
> > would
> > > have to do it themselves.
> > >
> >
> > Yes sure, but what if DynamicMBean doesn't fullfill
> > this contract or
> > implements it poorly? DMBean will probably log
> > NoSuchMethodException or
> > even something worse and we will have bunch of
> > "cosmetic" (thanks
> > Scott) stacktraces/exceptions.
> >
> > I still don't see anything wrong with type check for
> > org.jboss.util.Service.
> >
> > Vladimir
> >
> >
> > > You could use naming, but then you constrain
> > naming
> > > conventions, which may upset someone else.
> > >
> > > Just my 1p's-worth,
> > >
> > > Jules
> > >
> > > --- Scott M Stark <[EMAIL PROTECTED]>
> > > wrote:
> > > > The Jetty mbean is logging the exception itself
> > as a
> > > > warning and then it
> > > > is throwing the proper ReflectionException. The
> > > > issue is that ServiceControl
> > > > is invoking JBoss Service methods on any mbean
> > that
> > > > registers with the
> > > > MBeanServer. There needs to be a way to tell
> > > > ServiceControl that categories
> > > > of mbean should not be treated as candidate
> > JBoss
> > > > services. I'm saying this
> > > > is trivial to do using a domain naming
> > convention
> > > > and a configurable NotificationFilter
> > > > based on mbean domain names.
> > > >
> > > > If anyone has a better way achieving this speak
> > up.
> > > >
> > > >
> > > > - Original Message -
> > > > From: "David Jencks" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Tuesday, April 10, 2001 10:30 PM
> > > > Subject: Re: [JBoss-dev] Nested JMX Service
> > > > Groups...??!
> > > >
> > > >
> > > > > Hi,
> > > > >
> > > > > Well, it looks to me like he has thrown the
> > > > NoSuchMethodException himself
> > > > > in his ModelMBeanImpl. This exception
> > dexcends
> > > > from Exception, thus is not
> > > > > a reflection exception, and isn't caught by
> > any of
> > > > the exception
> > > > > handlers/ignorers.
> > > > >
> > > > > I don't yet understand what ModelMBeans are
> > for...
> > > > but if he changed the
> > > > > missing method handling to match that of line
> > 1620
> > > > of the MBeanServerImpl,
> > > > > the problems might go away.
> > > > >
> > > > >
> > > > > Further posts from Scott Stark and Marc Fleury
> > > > make me think this may be
> > > > > difficult to impossible. If so, we could
> > instead
> > > > change ServiceControl to
> > > > > ignore MethodNotFoundExceptions as well as
> > > > ReflectionExceptions. e.g.
> > > > > around line 67
> > > > >
> > > > > } catch (ReflectionException e)
> > > > > {
> > > > >// Not a service - ok
> > > > > }
> > > > > catch (NoSuchMethodException e) {
> > > > >//Not a service - also ok
> > > > > } catch (RuntimeMBeanException e)
> > > > >
> > > > >
> > > > > Personally I am inclined to suggest putting
> > empty
> > > > methods for the
> > > > > nonexistent operations in every mbean. I
> > don't
> > > > entirely understand why
> > > > > this isn't in the mbean spec.
> > > > >
> > > > > David Jencks
> > > > >
> > > >
> > > >
> > > >
> > > > ___
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > >
> > >
> >
> http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> > > __
> > > Do You Yahoo!?
> > > Get email at your own domain with Yahoo! Mail.
> > > http://personal.mail.yahoo.com/
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > >
> >
> http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAI
Re: [JBoss-dev] Object Unique Id Generator
Hi! From: "Schaefer, Andreas" <[EMAIL PROTECTED]> > There is a conceptual issue I like to raise here. From my > point of view the "Unique Key" is part of the DB and therefore > under the ownership of the DB. The idea I saw there would > work under some assumptions: > - DB belongs only to the application I don't see what you mean. Could you elaborate please? > - There is no interaction with the DB except through the EJBs hmmm not strictly but you have a point. A java client could use this generator, but it's true that you would have to go through java code and have an ejb server running. > - DB is only the persistence tool > > If you want to add data to the DB through the DB directly > like an import or through a backup. Yes, I agree that you would not be able to use some database tools to import data. But the goal of this UID Generator is to offer an "enterprise-ready" solution as Scott Ambler puts it. This involves a wider range of applications than the typical web/ejb/db solution and at a larger scale. To summarise the arguments against surrogate keys (database generated keys fall into that category) : - First, your applications become plateform dependant. - Second, the strategies typically break down in multi-database scenarios, especially when the databases are from different vendors. - Third, obtaining the key value causes a dip in performance each time, especially if you need to bring the value back across the network. - As a last argument (impact of which I must admit I am not really familiar with), surrogate keys generated solely by databases are predicated on the concept of your applications actually being in communication with your database, a requirement that is difficult to fulfill if your application needs to support mobile, disconnected users. That's it! Further opinions: please open fire! :) Emmanuel > Have fun - Andy > > > -Original Message- > > From: Sean Neville [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 10, 2001 11:01 AM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > > > > There are a series of key generation patterns available on > > The Server Side, > > at least one of which requires no databases and no singletons, and is > > therefore quite portable: > > > > http://www2.theserverside.com/patterns/index.jsp > > > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Schaefer, Andreas > > Sent: Tuesday, April 10, 2001 1:22 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > > > > Hi Geeks > > > > The "FOR UPDATE" is not always necessary as like in Oracle you > > have a sequence generator delivering you an unique ID. > > > > For the other DBs it is maybe better to use a DB procedure or > > function to generate an unique ID than use a SQL Statement. > > > > Have fun - Andy > > > > > -Original Message- > > > From: Emmanuel Sciara [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, April 10, 2001 9:28 AM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] Object Unique Id Generator > > > > > > > > > Hi guys, > > > > > > I have written an advanced key generator for ejbs > > > (http://ejbutils.sourceforge.net/). I would like to possibly have it > > > blundled with JBoss. For this however, I need a database that > > > supports "FOR > > > UPDATE" sql clauses or transactions with serializable > > isolation level. > > > > > > >From what I know, Hypersonic does not provide that and I > > > moved away from > > > InstantDB early in the process because I had problems with > > > it, so I don't > > > know. > > > > > > So I guess, my question is two fold: > > > - Does JBoss have such database? > > > - If yes, do you think it would be worth blundling this stuff > > > with JBoss. > > > > > > Note: the source is a bit out of date on sourceforge but I am > > > working on it. > > > I have a fully JBoss-deployable version if you are interested. > > > > > > Emmanuel > > > > > > > From: "marc fleury" <[EMAIL PROTECTED]> > > > > > post this to jboss-dev, I remember there is a key > > > generator somewhere > > > but > > > > > yours might be more advanced. if you generate some > > > interest there, you > > > > are > > > > > on > > > > > > > > > > marc > > > > > > > > > > > > > > > |-Original Message- > > > > > |From: Emmanuel Sciara [mailto:[EMAIL PROTECTED]] > > > > > |Sent: Friday, April 06, 2001 10:31 AM > > > > > |To: marc fleury > > > > > |Subject: Re: Thanks > > > > > | > > > > > | > > > > > |Hey! > > > > > | > > > > > |Cool Idea! I am interested for sure. Just tell me where > > > to find the > > > right > > > > > |sample code and I am of! (if you can do that easily > > > enough, that would > > > > save > > > > > |me some time) > > > > > | > > > > > |Just need to modify my sql so it does not use "For > > > Update", which is > > > not > > > > > |supported by Hypersonic. I would like to write some doc > > > too. But I > > > g
[JBoss-dev] CVS update: jboss/src/main/org/jboss/logging Log.java
User: juhalindfors
Date: 01/04/11 06:37:46
Modified:src/main/org/jboss/logging Log.java
Log:
Using Reader instead of InputStream.
(Patch #414002 submitted by Samuel Niles Peretz)
Revision ChangesPath
1.9 +3 -2 jboss/src/main/org/jboss/logging/Log.java
Index: Log.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/logging/Log.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Log.java 2001/03/29 17:47:47 1.8
+++ Log.java 2001/04/11 13:37:46 1.9
@@ -17,7 +17,7 @@
*
* @see
* @author Rickard Öberg ([EMAIL PROTECTED])
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public abstract class Log
{
@@ -173,7 +173,8 @@
exception.printStackTrace(out);
out.close();
- DataInputStream din = new DataInputStream(new
ByteArrayInputStream(baos.toByteArray()));
+ BufferedReader din = new BufferedReader(
+new InputStreamReader(new ByteArrayInputStream(baos.toByteArray(;
String error;
try
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Nested JMX Service Groups...??!
--- Lemoine David-dlemoi01 <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> Yes, the ServiceControl could use the
> MBeanServer.isInstanceOf(ObjectName objName, String
> className) before
> invoking the Service methods.
> What I find frustrating about JMX is that it seems
> difficult to implement a kind of "Service Provider"
> pattern as is commonly used in COM, for example
> (where you query a "service provider" for a given
> interface on a given component). I guess this
> follows from the fact that standard MBeans do not
> have a common interface.
>
> David.
>
AFAIK, the advantage of Dynamic MBeans is that they
are not statically constrained by inheritance and may
vary their interfaces dynamically at run time.
Both of these demonstrate the inadequacy of simply
checking the inheritance of a potential Service MBean.
Sorry to be so terse. I have put a longer explanation
of this in a previous reply.
Thanks for the interest,
Jules
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: 11 April 2001 12:24
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Nested JMX Service
> Groups...??!
>
>
> Hey ppl,
>
> On Wed, 11 Apr 2001, Julian Gosnell wrote:
>
> > I think that Services should publish 'boolean
> > isAJBossService() {return true;}' method.
> >
> > This could be implemented in MBeanServiceSupport
> for
> > standard Service MBeans. Dynamic Service MBeans
> would
> > have to do it themselves.
> >
>
> Yes sure, but what if DynamicMBean doesn't fullfill
> this contract or
> implements it poorly? DMBean will probably log
> NoSuchMethodException or
> even something worse and we will have bunch of
> "cosmetic" (thanks
> Scott) stacktraces/exceptions.
>
> I still don't see anything wrong with type check for
> org.jboss.util.Service.
>
> Vladimir
>
>
> > You could use naming, but then you constrain
> naming
> > conventions, which may upset someone else.
> >
> > Just my 1p's-worth,
> >
> > Jules
> >
> > --- Scott M Stark <[EMAIL PROTECTED]>
> > wrote:
> > > The Jetty mbean is logging the exception itself
> as a
> > > warning and then it
> > > is throwing the proper ReflectionException. The
> > > issue is that ServiceControl
> > > is invoking JBoss Service methods on any mbean
> that
> > > registers with the
> > > MBeanServer. There needs to be a way to tell
> > > ServiceControl that categories
> > > of mbean should not be treated as candidate
> JBoss
> > > services. I'm saying this
> > > is trivial to do using a domain naming
> convention
> > > and a configurable NotificationFilter
> > > based on mbean domain names.
> > >
> > > If anyone has a better way achieving this speak
> up.
> > >
> > >
> > > - Original Message -
> > > From: "David Jencks" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Tuesday, April 10, 2001 10:30 PM
> > > Subject: Re: [JBoss-dev] Nested JMX Service
> > > Groups...??!
> > >
> > >
> > > > Hi,
> > > >
> > > > Well, it looks to me like he has thrown the
> > > NoSuchMethodException himself
> > > > in his ModelMBeanImpl. This exception
> dexcends
> > > from Exception, thus is not
> > > > a reflection exception, and isn't caught by
> any of
> > > the exception
> > > > handlers/ignorers.
> > > >
> > > > I don't yet understand what ModelMBeans are
> for...
> > > but if he changed the
> > > > missing method handling to match that of line
> 1620
> > > of the MBeanServerImpl,
> > > > the problems might go away.
> > > >
> > > >
> > > > Further posts from Scott Stark and Marc Fleury
> > > make me think this may be
> > > > difficult to impossible. If so, we could
> instead
> > > change ServiceControl to
> > > > ignore MethodNotFoundExceptions as well as
> > > ReflectionExceptions. e.g.
> > > > around line 67
> > > >
> > > > } catch (ReflectionException e)
> > > > {
> > > >// Not a service - ok
> > > > }
> > > > catch (NoSuchMethodException e) {
> > > >//Not a service - also ok
> > > > } catch (RuntimeMBeanException e)
> > > >
> > > >
> > > > Personally I am inclined to suggest putting
> empty
> > > methods for the
> > > > nonexistent operations in every mbean. I
> don't
> > > entirely understand why
> > > > this isn't in the mbean spec.
> > > >
> > > > David Jencks
> > > >
> > >
> > >
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > >
> >
>
http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> > __
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> >
>
http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
>
htt
Re: [JBoss-dev] Nested JMX Service Groups...??!
On Wed, 11 Apr 2001, [EMAIL PROTECTED] wrote: > I still don't see anything wrong with type check for > org.jboss.util.Service. Me neither. That should be enough to identify the mbeans adhering to the JBoss service life cycle management. Will you make this change? -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS client/ssh
All, I hate to bother everybody with a stupid question, but... I've been having a devil of a time with sourceforge/CVS/ssh and getting to the point where I can commit. I'm using a W2K machine. I've tried jCVS (no support for ssh), winCVS (seems to support ssh, but won't work properly) and cygwin's command line CVS from within the Unix shell. Nothing seems to work. I very carefully followed the directions on the jboss link to sourceforge and the cvs how-to. Does anybody have a concise, set-up for winCVS or something similar you might be able to pass along? Actually it doesn't really even have to be winCVS, anything that would easily set up on a windows machine. thanks everybody! peter __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
If a DynamicMBean does not implement the contract
correctly then by definition it is not a JBoss Service
and does not require management.
checking isA(org.jboss.util.Service) will work on
standard MBeans, but not necessarily on DynamicMBeans.
Just because a DynamicMBean implements Service does
not mean that it publishes it via JMX. Alternatively
it may publish an interface that looks like Service
via JMX but implement it differently (If I added an
init() method to the Jetty lifecycle it would look the
same).
I maintain that the way to be sure if an MBean intends
to be used as a JBoss service is for it to be explicit
and unambigous about this intention.
Inheriting from org.jboss.util.Service is so.
Publishing a method isAJBossService() is so.
In order to save using different tests for Standard
and Dynamic MBeans you could simply add
isAJBossService() to org.jboss.util.Service and test
for this one thing.
This would have the additional advantage of allowing a
Service that does inherit from Service to opt out of
the JBoss lifecycle by returning 'false'. Furthermore
it would allow dynamic MBeans to make the decision
dynamically, instead of statically, which on further
consideration I think is probably the best argument
for the method. DynamicMBeans are allowed to vary
their interfaces during their lifetime. This may well
impact on the availability of their JBoss Service
interface, so they need to be able to indicate this to
JBoss.
I don't think you can achieve this same dynamicity and
simplicity by checking inheritance or naming schemes.
Anyone ?
Jules
--- "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hey ppl,
>
> On Wed, 11 Apr 2001, Julian Gosnell wrote:
>
> > I think that Services should publish 'boolean
> > isAJBossService() {return true;}' method.
> >
> > This could be implemented in MBeanServiceSupport
> for
> > standard Service MBeans. Dynamic Service MBeans
> would
> > have to do it themselves.
> >
>
> Yes sure, but what if DynamicMBean doesn't fullfill
> this contract or
> implements it poorly? DMBean will probably log
> NoSuchMethodException or
> even something worse and we will have bunch of
> "cosmetic" (thanks
> Scott) stacktraces/exceptions.
>
> I still don't see anything wrong with type check for
> org.jboss.util.Service.
>
> Vladimir
>
>
> > You could use naming, but then you constrain
> naming
> > conventions, which may upset someone else.
> >
> > Just my 1p's-worth,
> >
> > Jules
> >
> > --- Scott M Stark <[EMAIL PROTECTED]>
> > wrote:
> > > The Jetty mbean is logging the exception itself
> as a
> > > warning and then it
> > > is throwing the proper ReflectionException. The
> > > issue is that ServiceControl
> > > is invoking JBoss Service methods on any mbean
> that
> > > registers with the
> > > MBeanServer. There needs to be a way to tell
> > > ServiceControl that categories
> > > of mbean should not be treated as candidate
> JBoss
> > > services. I'm saying this
> > > is trivial to do using a domain naming
> convention
> > > and a configurable NotificationFilter
> > > based on mbean domain names.
> > >
> > > If anyone has a better way achieving this speak
> up.
> > >
> > >
> > > - Original Message -
> > > From: "David Jencks" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Tuesday, April 10, 2001 10:30 PM
> > > Subject: Re: [JBoss-dev] Nested JMX Service
> > > Groups...??!
> > >
> > >
> > > > Hi,
> > > >
> > > > Well, it looks to me like he has thrown the
> > > NoSuchMethodException himself
> > > > in his ModelMBeanImpl. This exception
> dexcends
> > > from Exception, thus is not
> > > > a reflection exception, and isn't caught by
> any of
> > > the exception
> > > > handlers/ignorers.
> > > >
> > > > I don't yet understand what ModelMBeans are
> for...
> > > but if he changed the
> > > > missing method handling to match that of line
> 1620
> > > of the MBeanServerImpl,
> > > > the problems might go away.
> > > >
> > > >
> > > > Further posts from Scott Stark and Marc Fleury
> > > make me think this may be
> > > > difficult to impossible. If so, we could
> instead
> > > change ServiceControl to
> > > > ignore MethodNotFoundExceptions as well as
> > > ReflectionExceptions. e.g.
> > > > around line 67
> > > >
> > > > } catch (ReflectionException e)
> > > > {
> > > >// Not a service - ok
> > > > }
> > > > catch (NoSuchMethodException e) {
> > > >//Not a service - also ok
> > > > } catch (RuntimeMBeanException e)
> > > >
> > > >
> > > > Personally I am inclined to suggest putting
> empty
> > > methods for the
> > > > nonexistent operations in every mbean. I
> don't
> > > entirely understand why
> > > > this isn't in the mbean spec.
> > > >
> > > > David Jencks
> > > >
> > >
> > >
> > >
> > > ___
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > >
> >
>
http://lists.sourceforge.net/lists/listi
RE: [JBoss-dev] Object Unique Id Generator
This brings up related points that RDBMS folks have been making for some time concerning flaws in EJB. Persistence not being an official SPI but rather bundled into pieces of EJB, JDBC and Connector specs, most of the difficult problems aren't directly addressed in a J2EE spec. Dave Wolf of Sybase has referred to the persistence issue as the great white elephant sitting in the J2EE room that no one wants to mention by name, though we're all propping our feet up on it. I guess Dave has a good sense of humor. Dave and others make a case that EJB is useful only when it does have exclusive access to the underlying datastore (making commit option A the only viable solution). Even simple issues like discrepancies between ejbStore and ejbLoad (if external apps can access the database, the data may change between a load and store, causing the bean to be out of sync with the actual data even though the EJB server has carefully locked access within its realm to properly sync all EJB's) are addressable only through DB-specific methods or true XA drivers (not XA wrappers provided by pooling code, but drivers) and some DB vendor-specific syntax. More complex issues than this exist, and diamond scenarios proliferate. There are quite strong workarounds for much of these issues -- using messaging between views, complex deployment schemes, relying on Oracle-specific or Sybase-specific products and syntax, etc. -- but it would be helpful, in my humble opinion, to see some concerted direction from Sun in the form of an SPI that takes a stab at addressing the persistence issues in a way that consolidates CMP, Connector, JDBC, and even that current Sun political pariah, JDO. For now, patterns and pattern languages such as those mentioned on The Server Side suffice as a starting point -- not a silver bullet, but a viable starting point -- for handling such issues in specific vertical apps. Sean -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Schaefer, Andreas Sent: Tuesday, April 10, 2001 2:33 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Object Unique Id Generator There is a conceptual issue I like to raise here. From my point of view the "Unique Key" is part of the DB and therefore under the ownership of the DB. The idea I saw there would work under some assumptions: - DB belongs only to the application - There is no interaction with the DB except through the EJBs - DB is only the persistence tool If you want to add data to the DB through the DB directly like an import or through a backup. The Unique Key is a DB concept and therefore I think the key generation should remain within the DB. Have fun - Andy > -Original Message- > From: Sean Neville [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 10, 2001 11:01 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > There are a series of key generation patterns available on > The Server Side, > at least one of which requires no databases and no singletons, and is > therefore quite portable: > > http://www2.theserverside.com/patterns/index.jsp > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Schaefer, Andreas > Sent: Tuesday, April 10, 2001 1:22 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Object Unique Id Generator > > > Hi Geeks > > The "FOR UPDATE" is not always necessary as like in Oracle you > have a sequence generator delivering you an unique ID. > > For the other DBs it is maybe better to use a DB procedure or > function to generate an unique ID than use a SQL Statement. > > Have fun - Andy > > > -Original Message- > > From: Emmanuel Sciara [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 10, 2001 9:28 AM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] Object Unique Id Generator > > > > > > Hi guys, > > > > I have written an advanced key generator for ejbs > > (http://ejbutils.sourceforge.net/). I would like to possibly have it > > blundled with JBoss. For this however, I need a database that > > supports "FOR > > UPDATE" sql clauses or transactions with serializable > isolation level. > > > > >From what I know, Hypersonic does not provide that and I > > moved away from > > InstantDB early in the process because I had problems with > > it, so I don't > > know. > > > > So I guess, my question is two fold: > > - Does JBoss have such database? > > - If yes, do you think it would be worth blundling this stuff > > with JBoss. > > > > Note: the source is a bit out of date on sourceforge but I am > > working on it. > > I have a fully JBoss-deployable version if you are interested. > > > > Emmanuel > > > > > From: "marc fleury" <[EMAIL PROTECTED]> > > > > post this to jboss-dev, I remember there is a key > > generator somewhere > > but > > > > yours might be more advanced. if you generate some > > interest there, you > > > are > > > > on > > > > > > > > marc > > > > > >
RE: [JBoss-dev] Nested JMX Service Groups...??!
Hi,
Yes, the ServiceControl could use the MBeanServer.isInstanceOf(ObjectName objName,
String className) before
invoking the Service methods.
What I find frustrating about JMX is that it seems difficult to implement a kind of
"Service Provider" pattern as is commonly used in COM, for example (where you query a
"service provider" for a given interface on a given component). I guess this follows
from the fact that standard MBeans do not have a common interface.
David.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 11 April 2001 12:24
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Nested JMX Service Groups...??!
Hey ppl,
On Wed, 11 Apr 2001, Julian Gosnell wrote:
> I think that Services should publish 'boolean
> isAJBossService() {return true;}' method.
>
> This could be implemented in MBeanServiceSupport for
> standard Service MBeans. Dynamic Service MBeans would
> have to do it themselves.
>
Yes sure, but what if DynamicMBean doesn't fullfill this contract or
implements it poorly? DMBean will probably log NoSuchMethodException or
even something worse and we will have bunch of "cosmetic" (thanks
Scott) stacktraces/exceptions.
I still don't see anything wrong with type check for
org.jboss.util.Service.
Vladimir
> You could use naming, but then you constrain naming
> conventions, which may upset someone else.
>
> Just my 1p's-worth,
>
> Jules
>
> --- Scott M Stark <[EMAIL PROTECTED]>
> wrote:
> > The Jetty mbean is logging the exception itself as a
> > warning and then it
> > is throwing the proper ReflectionException. The
> > issue is that ServiceControl
> > is invoking JBoss Service methods on any mbean that
> > registers with the
> > MBeanServer. There needs to be a way to tell
> > ServiceControl that categories
> > of mbean should not be treated as candidate JBoss
> > services. I'm saying this
> > is trivial to do using a domain naming convention
> > and a configurable NotificationFilter
> > based on mbean domain names.
> >
> > If anyone has a better way achieving this speak up.
> >
> >
> > - Original Message -
> > From: "David Jencks" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, April 10, 2001 10:30 PM
> > Subject: Re: [JBoss-dev] Nested JMX Service
> > Groups...??!
> >
> >
> > > Hi,
> > >
> > > Well, it looks to me like he has thrown the
> > NoSuchMethodException himself
> > > in his ModelMBeanImpl. This exception dexcends
> > from Exception, thus is not
> > > a reflection exception, and isn't caught by any of
> > the exception
> > > handlers/ignorers.
> > >
> > > I don't yet understand what ModelMBeans are for...
> > but if he changed the
> > > missing method handling to match that of line 1620
> > of the MBeanServerImpl,
> > > the problems might go away.
> > >
> > >
> > > Further posts from Scott Stark and Marc Fleury
> > make me think this may be
> > > difficult to impossible. If so, we could instead
> > change ServiceControl to
> > > ignore MethodNotFoundExceptions as well as
> > ReflectionExceptions. e.g.
> > > around line 67
> > >
> > > } catch (ReflectionException e)
> > > {
> > >// Not a service - ok
> > > }
> > > catch (NoSuchMethodException e) {
> > >//Not a service - also ok
> > > } catch (RuntimeMBeanException e)
> > >
> > >
> > > Personally I am inclined to suggest putting empty
> > methods for the
> > > nonexistent operations in every mbean. I don't
> > entirely understand why
> > > this isn't in the mbean spec.
> > >
> > > David Jencks
> > >
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> >
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> __
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS client/ssh
On Wed, 11 Apr 2001, Peter Braswell wrote: > I'm using a W2K machine. I've tried jCVS (no support > for ssh), winCVS (seems to support ssh, but won't work > properly) and cygwin's command line CVS from within > the Unix shell. Nothing seems to work. Cygwin pretty much works out of the box for me on NT4. What sort of problems were you having with it? export CVS_RSH=ssh cvs -d :ext:@cvs.jboss.sourceforge.net:/cvsroot/jboss co jboss cvs commit :wq done -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
Hey Juha, I can't until tonite (EST). Let Julian play with it and if other folks agree it is trivial to add this. So ServiceControl.handleNotification(), instead of just checking for registration event , check type as well. I beleive easiest way to do this is to use MBeanServer.isInstanceOf . Something like: if(reg.getType().equals(MBeanServerNotification.REGISTRATION_NOTIFICATION) && server.isInstanceOf(reg.getMBeanName(),"org.jboss.util.Service")) simillar for deregistration. Vlada On Wed, 11 Apr 2001, Juha-P Lindfors wrote: > > > On Wed, 11 Apr 2001, [EMAIL PROTECTED] wrote: > > I still don't see anything wrong with type check for > > org.jboss.util.Service. > > Me neither. That should be enough to identify the mbeans adhering to the > JBoss service life cycle management. > > Will you make this change? > > -- Juha > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
Hey ppl,
On Wed, 11 Apr 2001, Julian Gosnell wrote:
> I think that Services should publish 'boolean
> isAJBossService() {return true;}' method.
>
> This could be implemented in MBeanServiceSupport for
> standard Service MBeans. Dynamic Service MBeans would
> have to do it themselves.
>
Yes sure, but what if DynamicMBean doesn't fullfill this contract or
implements it poorly? DMBean will probably log NoSuchMethodException or
even something worse and we will have bunch of "cosmetic" (thanks
Scott) stacktraces/exceptions.
I still don't see anything wrong with type check for
org.jboss.util.Service.
Vladimir
> You could use naming, but then you constrain naming
> conventions, which may upset someone else.
>
> Just my 1p's-worth,
>
> Jules
>
> --- Scott M Stark <[EMAIL PROTECTED]>
> wrote:
> > The Jetty mbean is logging the exception itself as a
> > warning and then it
> > is throwing the proper ReflectionException. The
> > issue is that ServiceControl
> > is invoking JBoss Service methods on any mbean that
> > registers with the
> > MBeanServer. There needs to be a way to tell
> > ServiceControl that categories
> > of mbean should not be treated as candidate JBoss
> > services. I'm saying this
> > is trivial to do using a domain naming convention
> > and a configurable NotificationFilter
> > based on mbean domain names.
> >
> > If anyone has a better way achieving this speak up.
> >
> >
> > - Original Message -
> > From: "David Jencks" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, April 10, 2001 10:30 PM
> > Subject: Re: [JBoss-dev] Nested JMX Service
> > Groups...??!
> >
> >
> > > Hi,
> > >
> > > Well, it looks to me like he has thrown the
> > NoSuchMethodException himself
> > > in his ModelMBeanImpl. This exception dexcends
> > from Exception, thus is not
> > > a reflection exception, and isn't caught by any of
> > the exception
> > > handlers/ignorers.
> > >
> > > I don't yet understand what ModelMBeans are for...
> > but if he changed the
> > > missing method handling to match that of line 1620
> > of the MBeanServerImpl,
> > > the problems might go away.
> > >
> > >
> > > Further posts from Scott Stark and Marc Fleury
> > make me think this may be
> > > difficult to impossible. If so, we could instead
> > change ServiceControl to
> > > ignore MethodNotFoundExceptions as well as
> > ReflectionExceptions. e.g.
> > > around line 67
> > >
> > > } catch (ReflectionException e)
> > > {
> > >// Not a service - ok
> > > }
> > > catch (NoSuchMethodException e) {
> > >//Not a service - also ok
> > > } catch (RuntimeMBeanException e)
> > >
> > >
> > > Personally I am inclined to suggest putting empty
> > methods for the
> > > nonexistent operations in every mbean. I don't
> > entirely understand why
> > > this isn't in the mbean spec.
> > >
> > > David Jencks
> > >
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> >
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> __
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-415379 ] Patch #415337: Informix jaws.xml
Change Notes item #415379, was updated on 2001-04-11 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=415379&group_id=22866 Category: None Group: v2.4 Status: Open Priority: 5 Submitted By: Juha Lindfors (juhalindfors) Assigned to: Nobody/Anonymous (nobody) Summary: Patch #415337: Informix jaws.xml Initial Comment: See http://sourceforge.net/tracker/index.php?func=detail&aid=415337&group_id=22866&atid=376687 -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=415379&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjaws.xml
User: juhalindfors Date: 01/04/11 05:10:12 Modified:src/etc/conf/default standardjaws.xml Log: Informix Mappings added (Patch #415337 by Nobody/Anonymous) Revision ChangesPath 1.14 +94 -0 jboss/src/etc/conf/default/standardjaws.xml Index: standardjaws.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjaws.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- standardjaws.xml 2001/03/26 15:55:42 1.13 +++ standardjaws.xml 2001/04/11 12:10:12 1.14 @@ -1056,5 +1056,99 @@ + + +InformixDB + +java.lang.Character +CHAR +CHAR(1) + + + +java.lang.String +VARCHAR +VARCHAR(255,0) + + + +java.math.BigDecimal +NUMERIC +DECIMAL + + + +java.lang.Boolean +BIT +SMALLINT + + + +java.lang.Integer +INTEGER +INTEGER + + + +java.lang.Long +BIGINT +NUMERIC(18,0) + + + +java.lang.Float +REAL +FLOAT + + + +java.lang.Double +DOUBLE +DOUBLE PRECISION + + + +java.lang.Byte +TINYINT +SMALLINT + + + +java.lang.Short +SMALLINT +SMALLINT + + + +java.util.Date +DATE +DATE + + + +java.sql.Date +DATE +DATE + + + +java.sql.Time +TIME +TIME + + + +java.sql.Timestamp +TIMESTAMP +DATETIME YEAR TO FRACTION(3) + + + +java.lang.Object +JAVA_OBJECT +BYTE + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Nested JMX Service Groups...??!
I think that Services should publish 'boolean
isAJBossService() {return true;}' method.
This could be implemented in MBeanServiceSupport for
standard Service MBeans. Dynamic Service MBeans would
have to do it themselves.
You could use naming, but then you constrain naming
conventions, which may upset someone else.
Just my 1p's-worth,
Jules
--- Scott M Stark <[EMAIL PROTECTED]>
wrote:
> The Jetty mbean is logging the exception itself as a
> warning and then it
> is throwing the proper ReflectionException. The
> issue is that ServiceControl
> is invoking JBoss Service methods on any mbean that
> registers with the
> MBeanServer. There needs to be a way to tell
> ServiceControl that categories
> of mbean should not be treated as candidate JBoss
> services. I'm saying this
> is trivial to do using a domain naming convention
> and a configurable NotificationFilter
> based on mbean domain names.
>
> If anyone has a better way achieving this speak up.
>
>
> - Original Message -
> From: "David Jencks" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, April 10, 2001 10:30 PM
> Subject: Re: [JBoss-dev] Nested JMX Service
> Groups...??!
>
>
> > Hi,
> >
> > Well, it looks to me like he has thrown the
> NoSuchMethodException himself
> > in his ModelMBeanImpl. This exception dexcends
> from Exception, thus is not
> > a reflection exception, and isn't caught by any of
> the exception
> > handlers/ignorers.
> >
> > I don't yet understand what ModelMBeans are for...
> but if he changed the
> > missing method handling to match that of line 1620
> of the MBeanServerImpl,
> > the problems might go away.
> >
> >
> > Further posts from Scott Stark and Marc Fleury
> make me think this may be
> > difficult to impossible. If so, we could instead
> change ServiceControl to
> > ignore MethodNotFoundExceptions as well as
> ReflectionExceptions. e.g.
> > around line 67
> >
> > } catch (ReflectionException e)
> > {
> >// Not a service - ok
> > }
> > catch (NoSuchMethodException e) {
> >//Not a service - also ok
> > } catch (RuntimeMBeanException e)
> >
> >
> > Personally I am inclined to suggest putting empty
> methods for the
> > nonexistent operations in every mbean. I don't
> entirely understand why
> > this isn't in the mbean spec.
> >
> > David Jencks
> >
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
>
http://lists.sourceforge.net/lists/listinfo/jboss-development
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??!
Stacy, I like your idea of abstracting the lifecycle mapping. However, as I understand your description here, it still does not address my problem. You suggest that in the absence of valid metadata, you would assume the default lifecycle (I assume you mean default JBoss Service lifecycle). The problem is that not all MBeans that may wish to publish their interface via the JBoss JMX agent necessarily want their lifecycle managed by ServiceControl. They may not be a Service. I suggest that the default behaviour should be _NOT_ to assume that every registered MBean is a Service. Services should publish a method - e.g. isAJBossService(), which can be looked for by ServiceControl. This could be added to Service, implemented in MBeanServiceSupport etc, bringing most MBeans used in JBoss into the fold. 3rd party MBeans developed outside JBoss, but finding themselves running inside JBoss would then be free to share the JBoss JMX Agent, without fear of being tampered with by ServiceControl. I am asking for a clear division between JMX and JBoss Services. JBoss Services may be MBeans, but not all MBeans are JBoss Services. I hope this makes sense, Jules --- Stacy Curl <[EMAIL PROTECTED]> wrote: > I think that having an abstract life cycle of: init, > start, ping, stop, > destroy > is ok, but constraining MBeans to implement init(), > start(), ping(), stop(), > destroy() > methods is not ok. So I think replacing a service is > a mistake but > abstracting parts > of it isn't. So the ServiceControl would continue to > listen for registration > of MBeans > and be responsible for doing init, etc but would > first obtain the actual > methods to > call from the MetaDataService, in the absence of any > life-cycle meta-data > the ServiceControl > would default to the standard methods, at present > there are work arounds > such as catching > ReflectionExceptions after invoking 'start' and > assuming (rightly or > wrongly) that this means > the MBean doesn't have a start method. > > I think that ServiceControl doesn't manage > dependancies, it just aggregates > MBeans. The dependancies > seem to be implicit in the order in the MLet > resource file. This is ok if > you want to start/stop all > the mbeans but not if you want to start/stop a > subset. I think we should be > following the style in ant > and do something like: > > depends="really-important"/> > > -Original Message- > From: Scott M Stark > [mailto:[EMAIL PROTECTED]] > Sent: 10 April 2001 23:57 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Custom startup solved !? > was: Nested JMX > Service Groups...??! > > > Are you talking about a new service that replaces > org.jboss.util.ServiceControl or > a new service? The ServiceControl MBean that manages > service lifecyle also > manages service dependencies and the invocation of > init() and start() are > distinct > phases. When start is called on a service you know > that every service has > received an init() and every service you depend on > has received a start(). > > - Original Message - > From: "Stacy Curl" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; > "'Julian Gosnell'" > <[EMAIL PROTECTED]> > Sent: Tuesday, April 10, 2001 2:09 PM > Subject: RE: [JBoss-dev] Custom startup solved !? > was: Nested JMX Service > Groups...??! > > > > I think that the JBoss inspired life-cycle is too > restrictive, I'd > > like to be able to define life-cycle schemas in > the XMLet resource > > file, or in another XML file. An XMLet version > might look something > > like: > > > > > >code="com.sun.jdmk.comm.HtmlAdaptorServer" > > archive="jmxtools.jar" > > > name="DefaultDomain:name=HtmlAdaptorServer"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 500 > > > > > > true > > > > > > > > > > > > > > > > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-415368 ] JBoss 2.2 + Tomcat & Log4j
Bugs item #415368, was updated on 2001-04-11 03:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=415368&group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Christian Riege (lqd) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss 2.2 + Tomcat & Log4j Initial Comment: Is there any reason why the log4j stuff is ENABLED in the 'default' config of JBoss 2.2 but DISABLED in the jboss w/ bundled Tomcat?! There are also some other minor differences in between the 'conf/default' and 'conf/tomcat' directory which are clearly not related to the bundled Tomcat. Oh, and jboss-auto.jcml should probably *not* be bundled in the binary distribution, but this is just MHO. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=415368&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-415366 ] Bug fix: MetricsInterceptor
Change Notes item #415366, was updated on 2001-04-11 03:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=415366&group_id=22866 Category: None Group: v2.2.1 Status: Open Priority: 5 Submitted By: Juha Lindfors (juhalindfors) Assigned to: Nobody/Anonymous (nobody) Summary: Bug fix: MetricsInterceptor Initial Comment: JMS Messages were never deliverd due to too small time to live value. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=415366&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??!
I think that having an abstract life cycle of: init, start, ping, stop, destroy is ok, but constraining MBeans to implement init(), start(), ping(), stop(), destroy() methods is not ok. So I think replacing a service is a mistake but abstracting parts of it isn't. So the ServiceControl would continue to listen for registration of MBeans and be responsible for doing init, etc but would first obtain the actual methods to call from the MetaDataService, in the absence of any life-cycle meta-data the ServiceControl would default to the standard methods, at present there are work arounds such as catching ReflectionExceptions after invoking 'start' and assuming (rightly or wrongly) that this means the MBean doesn't have a start method. I think that ServiceControl doesn't manage dependancies, it just aggregates MBeans. The dependancies seem to be implicit in the order in the MLet resource file. This is ok if you want to start/stop all the mbeans but not if you want to start/stop a subset. I think we should be following the style in ant and do something like: -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: 10 April 2001 23:57 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??! Are you talking about a new service that replaces org.jboss.util.ServiceControl or a new service? The ServiceControl MBean that manages service lifecyle also manages service dependencies and the invocation of init() and start() are distinct phases. When start is called on a service you know that every service has received an init() and every service you depend on has received a start(). - Original Message - From: "Stacy Curl" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "'Julian Gosnell'" <[EMAIL PROTECTED]> Sent: Tuesday, April 10, 2001 2:09 PM Subject: RE: [JBoss-dev] Custom startup solved !? was: Nested JMX Service Groups...??! > I think that the JBoss inspired life-cycle is too restrictive, I'd > like to be able to define life-cycle schemas in the XMLet resource > file, or in another XML file. An XMLet version might look something > like: > > > archive="jmxtools.jar" > name="DefaultDomain:name=HtmlAdaptorServer"> > > > > > > > > > > > > > > > 500 > > > true > > > > > > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins MetricsInterceptor.java
User: juhalindfors
Date: 01/04/11 03:01:07
Modified:src/main/org/jboss/ejb/plugins MetricsInterceptor.java
Log:
These messages died before they got delivered.
Fix also applied to Branch_2_2 in case there's a 2.2.1 release.
Revision ChangesPath
1.7 +1 -1 jboss/src/main/org/jboss/ejb/plugins/MetricsInterceptor.java
Index: MetricsInterceptor.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/MetricsInterceptor.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- MetricsInterceptor.java 2001/01/23 17:19:50 1.6
+++ MetricsInterceptor.java 2001/04/11 10:01:06 1.7
@@ -132,7 +132,7 @@
try {
msg.setLongProperty(TIME, time);
-metricsPub.publish(msg, DeliveryMode.NON_PERSISTENT, 1, 1);
+metricsPub.publish(msg, DeliveryMode.NON_PERSISTENT, 1, 1);
}
catch (Exception e) {
// catch JMSExceptions, NPE's etc and prevent them from propagating
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/documentation migration.html
User: gropi Date: 01/04/11 02:50:14 Modified:documentation migration.html Log: added instructions on needed client jars like jbosssx-client.jar Revision ChangesPath 1.2 +6 -1 newsite/documentation/migration.html Index: migration.html === RCS file: /cvsroot/jboss/newsite/documentation/migration.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- migration.html2001/04/10 20:42:45 1.1 +++ migration.html2001/04/11 09:50:14 1.2 @@ -63,7 +63,12 @@ value ofto org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker . It is no longer needed to select jrmp12 or jrmp13 since JBoss should -select the correct version for you automatically. +select the correct version for you automatically. +There are more jar archives for the client side now. At +least you need to copy the archive jbosssx-client.jar and include it +into the CLASSPATH at the client side. Depending on what functionality +you use in your client you may need to include additional archives from +the jboss/client/ directory. MIGRATION FROM PRE2.1 TO 2.2 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Nested JMX Service Groups...??!
Jules,
> --- Scott M Stark <[EMAIL PROTECTED]>
> wrote:
> > They can't create a wrapper because mbeans are being
> > created as a byproduct
> > of interaction with the Jetty JMX interface. This is
> > a generic issue with integrating
> > third party services that happen to be mbeans which
> > may be using the JMX bus
> > for whatever purpose. Its trivial to add a filter by
> > domain
> > that allows ServiceControl to not even attempt to
> > manage any mbeans in a given
> > domain. This does not break the JBoss management
> > model in any way that I see.
> > It simply adds the notion of non-service domains.
> >
>
> Yes !
>
> Thanks Scott,
>
> This is it.
>
> How you choose to differentiate between JBoss Service
> MBeans and 3rd party ones is what I think the
> discussion should hinge upon.
Ehm, maybe I'm missing something but why the Vlada's solution isn't OK ? IE
modify the ServiceControl JBoss' MBean to check if the MBean belongs to the
JBoss lifecycle:
if (registration_notification &&
registeredMBean instanceof org.jboss.utill.Service)
{
list.add(registeredMBean);
}
Simon
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins MetricsInterceptor.java
User: juhalindfors
Date: 01/04/11 02:21:32
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_2
MetricsInterceptor.java
Log:
BUG FIX: With the current JBossMQ implementation, these messages died
before they were ever sent.
Ooops..
Revision ChangesPath
No revision
No revision
1.6.2.1 +1 -1 jboss/src/main/org/jboss/ejb/plugins/MetricsInterceptor.java
Index: MetricsInterceptor.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/MetricsInterceptor.java,v
retrieving revision 1.6
retrieving revision 1.6.2.1
diff -u -r1.6 -r1.6.2.1
--- MetricsInterceptor.java 2001/01/23 17:19:50 1.6
+++ MetricsInterceptor.java 2001/04/11 09:21:31 1.6.2.1
@@ -132,7 +132,7 @@
try {
msg.setLongProperty(TIME, time);
-metricsPub.publish(msg, DeliveryMode.NON_PERSISTENT, 1, 1);
+metricsPub.publish(msg, DeliveryMode.NON_PERSISTENT, 1, 1);
}
catch (Exception e) {
// catch JMSExceptions, NPE's etc and prevent them from propagating
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
