[JBoss-dev] CVS update: jboss/src/main/org/jboss/security RealmMapping.java
User: starksm
Date: 01/09/25 23:23:16
Modified:src/main/org/jboss/security Tag: Branch_2_4
RealmMapping.java
Log:
Add a Set getUserRoles(Principal principal) method
Revision ChangesPath
No revision
No revision
1.3.2.1 +7 -1 jboss/src/main/org/jboss/security/RealmMapping.java
Index: RealmMapping.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/security/RealmMapping.java,v
retrieving revision 1.3
retrieving revision 1.3.2.1
diff -u -r1.3 -r1.3.2.1
--- RealmMapping.java 2001/06/12 08:00:43 1.3
+++ RealmMapping.java 2001/09/26 06:23:16 1.3.2.1
@@ -18,7 +18,7 @@
method.
@author [EMAIL PROTECTED]
-@version $Revision: 1.3 $
+@version $Revision: 1.3.2.1 $
*/
public interface RealmMapping
{
@@ -40,4 +40,10 @@
false otherwise.
*/
public boolean doesUserHaveRole(Principal principal, Set roles);
+
+/** Return the set of domain roles the principal has been assigned.
+@return The SetPrincipal for the application domain roles that the
+ principal has been assigned.
+ */
+public Set getUserRoles(Principal principal);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/tomcat TomcatService.java TomcatServiceMBean.java
User: starksm Date: 01/09/25 23:29:14 Removed: src/main/org/jboss/tomcat Tag: Branch_2_4 TomcatService.java TomcatServiceMBean.java Log: Drop the out of date tomcat service ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/security SecurityDomain.java
User: starksm Date: 01/09/25 23:27:01 Added: src/main/org/jboss/security Tag: Branch_2_4 SecurityDomain.java Log: The SecurityDomain interface combines the SubjectSecurityManager and RealmMapping interfaces and adds a keyStore and trustStore as well as JSSE KeyManagerFactory and TrustManagerFactory accessors for use with SSL/JSSE. Revision ChangesPath No revision No revision 1.1.2.1 +40 -0 jboss/src/main/org/jboss/security/Attic/SecurityDomain.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/spi LdapLoginModule.java
User: starksm
Date: 01/09/25 23:35:58
Modified:src/main/org/jboss/security/auth/spi Tag: Branch_2_4
LdapLoginModule.java
Log:
matchOnUserDN : A flag indicating if the search for user roles should match
on the user's fully distinguished name. If false just the username is used
as the match value. If true, the userDN is used as the match value.
Revision ChangesPath
No revision
No revision
1.1.4.3 +18 -3
jbosssx/src/main/org/jboss/security/auth/spi/LdapLoginModule.java
Index: LdapLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/LdapLoginModule.java,v
retrieving revision 1.1.4.2
retrieving revision 1.1.4.3
diff -u -r1.1.4.2 -r1.1.4.3
--- LdapLoginModule.java 2001/08/03 20:31:18 1.1.4.2
+++ LdapLoginModule.java 2001/09/26 06:35:55 1.1.4.3
@@ -68,7 +68,10 @@
uidAttributeName : The name of the attribute that in the object containing
the user roles that corresponds to the userid. This is used to locate the
user roles.
-
+matchOnUserDN : A flag indicating if the search for user roles should match
+ on the user's fully distinguished name. If false just the username is used
+ as the match value. If true, the userDN is used as the match value.
+
A sample login config:
testLdap {
org.jboss.security.plugins.samples.LdapLoginModule required
@@ -83,7 +86,7 @@
};
@author [EMAIL PROTECTED]
- @version $Revision: 1.1.4.2 $
+ @version $Revision: 1.1.4.3 $
*/
public class LdapLoginModule extends UsernamePasswordLoginModule
{
@@ -93,6 +96,7 @@
private static final String ROLES_CTX_DN_OPT = rolesCtxDN;
private static final String UID_ATTRIBUTE_ID_OPT = uidAttributeID;
private static final String ROLE_ATTRIBUTE_ID_OPT = roleAttributeID;
+ private static final String MATCH_ON_USER_DN_OPT = matchOnUserDN;
public LdapLoginModule()
{
@@ -122,6 +126,12 @@
return roleSets;
}
+ /** Validate the inputPassword by creating a ldap InitialContext with the
+SECURITY_CREDENTIALS set to the password.
+
+@param inputPassword the password to validate.
+@param expectedPassword ignored
+*/
protected boolean validatePassword(String inputPassword, String expectedPassword)
{
boolean isValid = false;
@@ -174,6 +184,8 @@
String principalDNSuffix = (String) options.get(PRINCIPAL_DN_SUFFIX_OPT);
if( principalDNSuffix == null )
principalDNSuffix=;
+ String matchType = (String) options.get(MATCH_ON_USER_DN_OPT);
+ boolean matchOnUserDN = Boolean.valueOf(matchType).booleanValue();
String userDN = principalDNPrefix + username + principalDNSuffix;
env.setProperty(Context.PROVIDER_URL, providerURL);
env.setProperty(Context.SECURITY_PRINCIPAL, userDN);
@@ -192,7 +204,10 @@
if( roleAttrName == null )
roleAttrName = roles;
BasicAttributes matchAttrs = new BasicAttributes(true);
- matchAttrs.put(uidAttrName, username);
+ if( matchOnUserDN == true )
+matchAttrs.put(uidAttrName, userDN);
+ else
+matchAttrs.put(uidAttrName, username);
String[] roleAttr =
{roleAttrName};
try
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins JaasSecurityDomain.java JaasSecurityDomainMBean.java JaasSecurityManager.java JaasSecurityManagerService.java JaasSecurityManagerServiceMBean.java
User: starksm
Date: 01/09/25 23:36:35
Modified:src/main/org/jboss/security/plugins Tag: Branch_2_4
JaasSecurityManager.java
JaasSecurityManagerService.java
JaasSecurityManagerServiceMBean.java
Added: src/main/org/jboss/security/plugins Tag: Branch_2_4
JaasSecurityDomain.java
JaasSecurityDomainMBean.java
Log:
Add SecurityDomain implementation
Revision ChangesPath
No revision
No revision
1.7.2.5 +42 -8
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java
Index: JaasSecurityManager.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java,v
retrieving revision 1.7.2.4
retrieving revision 1.7.2.5
diff -u -r1.7.2.4 -r1.7.2.5
--- JaasSecurityManager.java 2001/07/27 03:38:32 1.7.2.4
+++ JaasSecurityManager.java 2001/09/26 06:36:35 1.7.2.5
@@ -10,6 +10,7 @@
import java.io.Serializable;
import java.util.Arrays;
import java.util.Enumeration;
+import java.util.HashSet;
import java.util.Iterator;
import java.util.Set;
@@ -53,8 +54,8 @@
@see #doesUserHaveRole(Principal, Set)
@author a href=[EMAIL PROTECTED]Oleg Nitz/a
- @author [EMAIL PROTECTED]
- @version $Revision: 1.7.2.4 $
+ @author [EMAIL PROTECTED]
+ @version $Revision: 1.7.2.5 $
*/
public class JaasSecurityManager implements SubjectSecurityManager, RealmMapping
{
@@ -71,9 +72,6 @@
/** The current authenticate()d subject.
*/
private static ThreadLocal activeSubject = new ThreadLocal();
- /** The log4j category for the security manager domain
-*/
- private Category log;
/** The name of the domain this instance is securing. It is used as
the appName into the SecurityPolicy.
*/
@@ -90,6 +88,9 @@
securityDomain name.
*/
private SecurityAssociationHandler handler = new SecurityAssociationHandler();
+ /** The log4j category for the security manager domain
+*/
+ protected Category log;
/** Get the currently authenticated Subject in securityDomain.
@return The Subject for securityDomain if one exists, false otherwise.
@@ -142,7 +143,8 @@
public JaasSecurityManager(String securityDomain)
{
this.securityDomain = securityDomain;
- this.log = Category.getInstance(getClass().getName()+.+securityDomain);
+ String categoryName = getClass().getName()+#+securityDomain;
+ this.log = Category.getInstance(categoryName);
try
{ // Try to get the SecurityPolicy from the JAAS Policy class
securityPolicy = (SecurityPolicy) Policy.getPolicy();
@@ -181,6 +183,7 @@
{
return securityDomain;
}
+
/** Get the currently authenticated Subject. This is a thread local
property shared across all JaasSecurityManager instances.
@return The Subject authenticated in the current thread if one
@@ -304,8 +307,39 @@
}
}
return hasRole;
+ }
+
+ /** Return the set of domain roles the principal has been assigned.
+ @return The SetPrincipal for the application domain roles that the
+ principal has been assigned.
+ */
+ public Set getUserRoles(Principal principal)
+ {
+ HashSet userRoles = null;
+ Subject subject = getActiveSubject();
+ if( subject != null )
+ {
+ DomainInfo info = null;
+ if( domainCache != null )
+info = (DomainInfo) domainCache.get(principal);
+
+ Group roles = null;
+ if( info != null )
+roles = info.roles;
+ if( roles != null )
+ {
+userRoles = new HashSet();
+Enumeration members = roles.members();
+while( members.hasMoreElements() )
+{
+ Principal role = (Principal) members.nextElement();
+ userRoles.add(role);
+}
+ }
+ }
+ return userRoles;
}
-
+
/** Currently this simply calls defaultLogin() to do a JAAS login using the
security domain name as the login module configuration name.
@@ -352,7 +386,7 @@
@exception LoginException throw if login fails for any reason.
*/
private Subject defaultLogin(Principal principal, Object credential)
- throws LoginException
+ throws LoginException
{
// We use our internal CallbackHandler to provide the security info
handler.setSecurityInfo(principal, credential);
1.2.2.5 +25 -8
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManagerService.java
Index: JaasSecurityManagerService.java
Re: [JBoss-dev] Off-Topic: Mangement of Java Classes through SNMP
I just did a quick search on freshmeat.net when I saw this. I have looked over this stuff before, but never had time or a reason to look futher. Might have to adapt JMX to it or it to JMX (which ever you prefer). I think there might be a few other packages available, but this one looks like it has the most steam. --jason On Wed, 26 Sep 2001, Rickard [iso-8859-1] Öberg wrote: Hi! This looks very interesting!!! Have you tested it with JBoss though? I browsed in the docs and couldn't find anything about JMX. /R Jason Dillon wrote: http://www.opennms.org --jason On Tue, 25 Sep 2001, Andreas Schaefer wrote: Hi Geeks I am looking for information how Java Classes can be managed through SNMP (I know this sounds ugly). Does anyone has some info or a link about this ? Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs jbossdocs.xml
User: gropi Date: 01/09/26 00:19:17 Modified:src/xdocs jbossdocs.xml Log: ;-) scary this slipped through unnoticed. Revision ChangesPath 1.8 +2 -2 manual/src/xdocs/jbossdocs.xml Index: jbossdocs.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/jbossdocs.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- jbossdocs.xml 2001/09/18 21:37:52 1.7 +++ jbossdocs.xml 2001/09/26 07:19:17 1.8 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=UTF-8? -!-- $Id: jbossdocs.xml,v 1.7 2001/09/18 21:37:52 tmcsys Exp $ -- +!-- $Id: jbossdocs.xml,v 1.8 2001/09/26 07:19:17 gropi Exp $ -- !DOCTYPE book SYSTEM file:@oasis.docbook.xml.root@/docbookx.dtd [ !ENTITY preface.xml SYSTEM preface.xml !ENTITY jbossintro.xml SYSTEM jbossintro.xml @@ -52,7 +52,7 @@ year2001/year holderJBoss Organization/holder /copyright - pubdateSeptember 18 2001/pubdate + pubdate@TODAY@/pubdate /bookinfo preface.xml; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS ExceptionListener not working any more?!
Hi, you are so great!!! Unfortunately I am not able to test it since the HEAD cvs is broken. (seems as if Scotts latest checkins is broken). I will test it with my old failsafe code when things stabilize. //Peter On 26 Sep, Hiram Chirino wrote: Peter, I have just fixed this bug in the HEAD branch. Every connection now has a thread that pings the server every 1 min. So, if the server goes down, failure should be detected within that amount of time. This should even apply to the RMI IL (the ExceptionListener handeling was really screwed for RMI since RMI is stateless). Regards, Hiram From: Peter Antman [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [JBoss-dev] JMS ExceptionListener not working any more?! Date: Tue, 25 Sep 2001 15:13:43 +0200 (CEST) Hi, we have had complaint in the messaging forum that the setExceptionListener (ExceptionListener.onException()). Does not work (any more). Up to and including 2.2.1 we have the following behaviour for the exception handling: If a client was connected and has received at least on message, the exception listener would get called if the server went down. If the client had not received a message, it would hang forever if the server went down. This was not a perfect behaviour (if server for example was restarted several time before any messages was sent, the client would be lost) but it worked resonable ok. And it was much better that having no support for the exception listener at all. Why is this not working any longer? Was it a strategic decision to remove the support for it, or some hierto undiscovered side-effect of some other changes? Any chance we could ge that support back into JBossMQ (and preferably also some cind of support for lost connection without any messages having to be received first)? //Peter -- Jobba hos oss: http://www.tim.se/weblab Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems Architect WWW: http://www.tim.se Email: [EMAIL PROTECTED] WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Jobba hos oss: http://www.tim.se/weblab Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss and log4j version 1.2
Hello Jason, There is no firm release date for 1.2. It will be released when it is ready. However, 1.2alpha0 is available since yesterday. :-) Extending the interface of Logger (i.e. Category) with new printing methods such as trace() is considered bad practice, at least by me. I understand that adding printing methods is consistent with the rest of the API, easy on the fingers and eyes. That is not good enough a reason. Log4j can never guarantee that a given category will be of a certain type, say org.jboss.logging.log4j.JBossCategory instead of org.apache.log4j.Logger. ClassCastException when instantiating a Category subclass is one example of this problem. See also http://jakarta.apache.org/log4j/docs/TROUBLESHOOT.html#cce In the future, I expect that Application Servers or Servlet Containers will impose a particular org.apache.log4j.Logger implementation (for security reasons). It will not be up to an embedded component to decide the logger subclass. Thus, you will not be able to rely on a org.jboss.logging.log4j.JBossCategory being returned even if you set the categoryFactory to org.jboss.logging.log4j.JBossCategory$JBossCategoryFactory in the configuration file. Log4j support in JBoss is particularly important. I suggest that you look into the LogManager, RepositorySelector and LoggerRepository code. See also http://jakarta.apache.org/log4j/docs/manual/manual.html#AEN718 The whole construction is intended to allow Application Servers to select the appropriate LoggerRepository depending on the embedded application. Let me give an example. Assume we have to applications App-A and App-B running inside JBoss. We want App-A and App-B to live in separate logging universes. We achieve this by having App-A and App-B use different LoggerRepositories (LoggerRepository is the new name for Hierarchies in log4j 1.2). Clients still call Logger.getLogger(name) to retrieve a logger (= category). However, we want to vary the LoggerRepository (~hierarchy) depending on the caller. For a call to Logger.getLogger(name) emanating from code in App-A, we want JBoss to detect that the caller is in App-A and use the LoggerRepository specific to App-A. Similarly, calling Logger.getLogger(name) within App-B should use a LoggerRepository specific to App-B. Since JBoss is the top-level application, JBoss is free to impose the RepositorySelector to the LogManager. JBoss' implementation of RepositorySelector can use different methods to track the caller (the particular application), for example by setting a ThreadLocal variable to track applications by Thread. Regarding your last question, the DOMConfigurator offers more services than ProppertyConfigurator and is considered as stable. Don't hesitate to contact me if you encounter problems when migrating to the DOMConfigurator. Regards, Ceki Gülcü -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 11:10 PM To: '[EMAIL PROTECTED]' Subject: Re: [JBoss-dev] jboss and log4j version 1.2 Hello, Hi. There are a few changes in log4j 1.2 that require your attention. Any clues to when 1.2 will be released? I also strongly recommend against sub-classing Logger (or Category) to introduce new printing methods, you can use the general purpose log method instead. For example, for some category-subclass object x instead of writing x.trace(hello) you can write x.log(SomePrioritySubclass.TRACE, hello); Why? The first is consistent with the other logging methods and it is terse (easy on the eyes and fingers). If I am not mistaken, JBoss also uses deprecated and now removed methods such as getOptions/setOptions in its own appenders. There is no need for this as log4j uses introspection to configure its appenders and layouts. I don't know anything about these, but we should fix that. Please let me know if you have any questions or comments. Regards, Ceki Thanks for the update. Do you know if the xml config bits support all of the features that the property based config does? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss and log4j version 1.2
Hate to follow up on myself but my previous discussion is based on the premise that log4j classes are loaded once and for all for everyone at JBoss startup time. Playing class loader tricks à la Tomcat-Catalina makes it a totally different game. Am I correct to assume that log4j classes are loaded once and for all by Jboss? Regards, Ceki -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] jboss and log4j version 1.2 Hello Jason, There is no firm release date for 1.2. It will be released when it is ready. However, 1.2alpha0 is available since yesterday. :-) Extending the interface of Logger (i.e. Category) with new printing methods such as trace() is considered bad practice, at least by me. I understand that adding printing methods is consistent with the rest of the API, easy on the fingers and eyes. That is not good enough a reason. Log4j can never guarantee that a given category will be of a certain type, say org.jboss.logging.log4j.JBossCategory instead of org.apache.log4j.Logger. ClassCastException when instantiating a Category subclass is one example of this problem. See also http://jakarta.apache.org/log4j/docs/TROUBLESHOOT.html#cce In the future, I expect that Application Servers or Servlet Containers will impose a particular org.apache.log4j.Logger implementation (for security reasons). It will not be up to an embedded component to decide the logger subclass. Thus, you will not be able to rely on a org.jboss.logging.log4j.JBossCategory being returned even if you set the categoryFactory to org.jboss.logging.log4j.JBossCategory$JBossCategoryFactory in the configuration file. Log4j support in JBoss is particularly important. I suggest that you look into the LogManager, RepositorySelector and LoggerRepository code. See also http://jakarta.apache.org/log4j/docs/manual/manual.html#AEN718 The whole construction is intended to allow Application Servers to select the appropriate LoggerRepository depending on the embedded application. Let me give an example. Assume we have to applications App-A and App-B running inside JBoss. We want App-A and App-B to live in separate logging universes. We achieve this by having App-A and App-B use different LoggerRepositories (LoggerRepository is the new name for Hierarchies in log4j 1.2). Clients still call Logger.getLogger(name) to retrieve a logger (= category). However, we want to vary the LoggerRepository (~hierarchy) depending on the caller. For a call to Logger.getLogger(name) emanating from code in App-A, we want JBoss to detect that the caller is in App-A and use the LoggerRepository specific to App-A. Similarly, calling Logger.getLogger(name) within App-B should use a LoggerRepository specific to App-B. Since JBoss is the top-level application, JBoss is free to impose the RepositorySelector to the LogManager. JBoss' implementation of RepositorySelector can use different methods to track the caller (the particular application), for example by setting a ThreadLocal variable to track applications by Thread. Regarding your last question, the DOMConfigurator offers more services than ProppertyConfigurator and is considered as stable. Don't hesitate to contact me if you encounter problems when migrating to the DOMConfigurator. Regards, Ceki Gülcü -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 11:10 PM To: '[EMAIL PROTECTED]' Subject: Re: [JBoss-dev] jboss and log4j version 1.2 Hello, Hi. There are a few changes in log4j 1.2 that require your attention. Any clues to when 1.2 will be released? I also strongly recommend against sub-classing Logger (or Category) to introduce new printing methods, you can use the general purpose log method instead. For example, for some category-subclass object x instead of writing x.trace(hello) you can write x.log(SomePrioritySubclass.TRACE, hello); Why? The first is consistent with the other logging methods and it is terse (easy on the eyes and fingers). If I am not mistaken, JBoss also uses deprecated and now removed methods such as getOptions/setOptions in its own appenders. There is no need for this as log4j uses introspection to configure its appenders and layouts. I don't know anything about these, but we should fix that. Please let me know if you have any questions or comments. Regards, Ceki Thanks for the update. Do you know if the xml config bits support all of the features that the property based config does? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development
Re: [JBoss-dev] Off-Topic: Mangement of Java Classes through SNMP
Take look at The lizzard lounge forum and Jboss and SNMP thread. It seems there is currently no a clean implementation of SNMP JMX adaptor... Jiri. On Tue, 25 Sep 2001 11:53:42 -0700, you wrote: Hi Geeks I am looking for information how Java Classes can be managed through SNMP (I know this sounds ugly). Does anyone has some info or a link about this ? Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS ExceptionListener not working any more?!
This is a good point. The logic should be easily convertible. Hey aren't you glad that we at least detect connection failures now?? ;) Regards, Hiram From: Jason Dillon [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS ExceptionListener not working any more?! Date: Tue, 25 Sep 2001 22:51:53 -0700 (PDT) Why not a shared timer thread to reduce thread usage? --jason On Wed, 26 Sep 2001, Hiram Chirino wrote: Peter, I have just fixed this bug in the HEAD branch. Every connection now has a thread that pings the server every 1 min. So, if the server goes down, failure should be detected within that amount of time. This should even apply to the RMI IL (the ExceptionListener handeling was really screwed for RMI since RMI is stateless). Regards, Hiram From: Peter Antman [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [JBoss-dev] JMS ExceptionListener not working any more?! Date: Tue, 25 Sep 2001 15:13:43 +0200 (CEST) Hi, we have had complaint in the messaging forum that the setExceptionListener (ExceptionListener.onException()). Does not work (any more). Up to and including 2.2.1 we have the following behaviour for the exception handling: If a client was connected and has received at least on message, the exception listener would get called if the server went down. If the client had not received a message, it would hang forever if the server went down. This was not a perfect behaviour (if server for example was restarted several time before any messages was sent, the client would be lost) but it worked resonable ok. And it was much better that having no support for the exception listener at all. Why is this not working any longer? Was it a strategic decision to remove the support for it, or some hierto undiscovered side-effect of some other changes? Any chance we could ge that support back into JBossMQ (and preferably also some cind of support for lost connection without any messages having to be received first)? //Peter -- Jobba hos oss: http://www.tim.se/weblab Peter AntmanTechnology in Media, Box 34105 100 26 Stockholm Systems Architect WWW: http://www.tim.se Email: [EMAIL PROTECTED] WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-465222 ] stateless session beans ejbCreate
Bugs item #465222, was opened at 2001-09-26 07:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=465222group_id=22866 Category: None Group: v2.4 BETA (stable) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: stateless session beans ejbCreate Initial Comment: Hello, I have one client that does one create() on a stateless session beans followed by 20 method invocations on the home returned from the create(). In 2.4.1 this creates 20 stateless session beans. In 2.2.2 it creates one stateless session bean. This really degrades performance. I though clients should be able to use pooled beans. Thanks Jeff Seaman -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=465222group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/security/plugins/samples CacheRealmMapping.java CacheRealmMappingService.java CacheRealmMappingServiceMBean.java DatabaseRealmMapping.java DatabaseRealmMappingService.java DatabaseRealmMappingServiceMBean.java DatabaseSecurityManagerService.java DatabaseSecurityManagerServiceMBean.java EJBSecurityManagerDatabaseImpl.java EJBSecurityManagerDefaultImpl.java EJBSecurityManagerService.java EJBSecurityManagerServiceMBean.java SimpleRealmMapping.java SimpleRealmMappingService.java SimpleRealmMappingServiceMBean.java
User: starksm Date: 01/09/26 08:14:42 Removed: src/main/org/jboss/security/plugins/samples Tag: Branch_2_4 CacheRealmMapping.java CacheRealmMappingService.java CacheRealmMappingServiceMBean.java DatabaseRealmMapping.java DatabaseRealmMappingService.java DatabaseRealmMappingServiceMBean.java DatabaseSecurityManagerService.java DatabaseSecurityManagerServiceMBean.java EJBSecurityManagerDatabaseImpl.java EJBSecurityManagerDefaultImpl.java EJBSecurityManagerService.java EJBSecurityManagerServiceMBean.java SimpleRealmMapping.java SimpleRealmMappingService.java SimpleRealmMappingServiceMBean.java Log: Remove obsolete samples ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/security/plugins NullSecurityManager.java
User: starksm
Date: 01/09/26 08:15:24
Modified:src/main/org/jboss/security/plugins NullSecurityManager.java
Log:
Remove obsolete samples and update NullSecurityManager for RealmMapping
changes
Revision ChangesPath
1.4 +13 -1
jboss/src/main/org/jboss/security/plugins/NullSecurityManager.java
Index: NullSecurityManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/security/plugins/NullSecurityManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- NullSecurityManager.java 2001/08/03 17:15:56 1.3
+++ NullSecurityManager.java 2001/09/26 15:15:23 1.4
@@ -7,10 +7,12 @@
package org.jboss.security.plugins;
import java.io.Serializable;
+import java.util.HashSet;
import java.util.Set;
import java.security.Principal;
import javax.security.auth.Subject;
+import org.jboss.security.AnybodyPrincipal;
import org.jboss.security.RealmMapping;
import org.jboss.security.SubjectSecurityManager;
@@ -24,7 +26,7 @@
@see #doesUserHaveRole(Principal, Set)
@author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
-@version $Revision: 1.3 $
+@version $Revision: 1.4 $
*/
public class NullSecurityManager
implements SubjectSecurityManager, RealmMapping, Serializable
@@ -81,6 +83,16 @@
{
boolean hasRole = true;
return hasRole;
+}
+
+/** Return the set of domain roles the principal has been assigned.
+@return The SetPrincipal with the AnybodyPrincipal as the sole role.
+ */
+public Set getUserRoles(Principal principal)
+{
+HashSet roles = new HashSet();
+roles.add(AnybodyPrincipal.ANYBODY_PRINCIPAL);
+return roles;
}
/** Authenticate principal against credential
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/security/plugins/samples CacheRealmMapping.java CacheRealmMappingService.java CacheRealmMappingServiceMBean.java DatabaseRealmMapping.java DatabaseRealmMappingService.java DatabaseRealmMappingServiceMBean.java DatabaseSecurityManagerService.java DatabaseSecurityManagerServiceMBean.java EJBSecurityManagerDatabaseImpl.java EJBSecurityManagerDefaultImpl.java EJBSecurityManagerService.java EJBSecurityManagerServiceMBean.java SimpleRealmMapping.java SimpleRealmMappingService.java SimpleRealmMappingServiceMBean.java
User: starksm Date: 01/09/26 08:15:24 Removed: src/main/org/jboss/security/plugins/samples CacheRealmMapping.java CacheRealmMappingService.java CacheRealmMappingServiceMBean.java DatabaseRealmMapping.java DatabaseRealmMappingService.java DatabaseRealmMappingServiceMBean.java DatabaseSecurityManagerService.java DatabaseSecurityManagerServiceMBean.java EJBSecurityManagerDatabaseImpl.java EJBSecurityManagerDefaultImpl.java EJBSecurityManagerService.java EJBSecurityManagerServiceMBean.java SimpleRealmMapping.java SimpleRealmMappingService.java SimpleRealmMappingServiceMBean.java Log: Remove obsolete samples and update NullSecurityManager for RealmMapping changes ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/security/plugins NullSecurityManager.java
User: starksm
Date: 01/09/26 08:17:17
Modified:src/main/org/jboss/security/plugins Tag: Branch_2_4
NullSecurityManager.java
Log:
Update for changes in RealmMapping interface
Revision ChangesPath
No revision
No revision
1.1.2.1 +12 -0
jboss/src/main/org/jboss/security/plugins/NullSecurityManager.java
Index: NullSecurityManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/security/plugins/NullSecurityManager.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- NullSecurityManager.java 2001/06/12 08:00:43 1.1
+++ NullSecurityManager.java 2001/09/26 15:17:17 1.1.2.1
@@ -7,10 +7,12 @@
package org.jboss.security.plugins;
import java.io.Serializable;
+import java.util.HashSet;
import java.util.Set;
import java.security.Principal;
import javax.security.auth.Subject;
+import org.jboss.security.AnybodyPrincipal;
import org.jboss.security.RealmMapping;
import org.jboss.security.SubjectSecurityManager;
@@ -24,7 +26,7 @@
@see #doesUserHaveRole(Principal, Set)
@author [EMAIL PROTECTED]
-@version $Revision: 1.1 $
+@version $Revision: 1.1.2.1 $
*/
public class NullSecurityManager
implements SubjectSecurityManager, RealmMapping, Serializable
@@ -81,6 +83,16 @@
{
boolean hasRole = true;
return hasRole;
+}
+
+/** Return the set of domain roles the principal has been assigned.
+@return The SetPrincipal with the AnybodyPrincipal as the sole role.
+ */
+public Set getUserRoles(Principal principal)
+{
+HashSet roles = new HashSet();
+roles.add(AnybodyPrincipal.ANYBODY_PRINCIPAL);
+return roles;
}
/** Authenticate principal against credential
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss and log4j version 1.2
That is the case. - Original Message - From: Ceki Gülcü [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 1:13 AM Subject: RE: [JBoss-dev] jboss and log4j version 1.2 Hate to follow up on myself but my previous discussion is based on the premise that log4j classes are loaded once and for all for everyone at JBoss startup time. Playing class loader tricks à la Tomcat-Catalina makes it a totally different game. Am I correct to assume that log4j classes are loaded once and for all by Jboss? Regards, Ceki ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib idb.jar
User: starksm Date: 01/09/26 08:55:26 Removed: src/lib Tag: Branch_2_4 idb.jar Log: Remove InstantDB from the distribution ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jboss-jaas.jar jbosssx.jar
User: starksm Date: 01/09/26 09:04:03 Modified:src/lib Tag: Branch_2_4 jboss-jaas.jar jbosssx.jar Log: Integrate the Rel_2_4_2_4 JBossSX changes Revision ChangesPath No revision No revision 1.11.2.12 +121 -124 jboss/src/lib/Attic/jboss-jaas.jar Binary file 1.11.2.12 +213 -189 jboss/src/lib/Attic/jbosssx.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins SecurityInterceptor.java
User: starksm
Date: 01/09/26 09:01:08
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
SecurityInterceptor.java
Log:
Log the principal roles on authorization failure
Revision ChangesPath
No revision
No revision
1.17.2.3 +3 -2 jboss/src/main/org/jboss/ejb/plugins/SecurityInterceptor.java
Index: SecurityInterceptor.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/SecurityInterceptor.java,v
retrieving revision 1.17.2.2
retrieving revision 1.17.2.3
diff -u -r1.17.2.2 -r1.17.2.3
--- SecurityInterceptor.java 2001/08/20 22:16:35 1.17.2.2
+++ SecurityInterceptor.java 2001/09/26 16:01:07 1.17.2.3
@@ -29,7 +29,7 @@
@author a href=[EMAIL PROTECTED]Oleg Nitz/a
@author [EMAIL PROTECTED]
-@version $Revision: 1.17.2.2 $
+@version $Revision: 1.17.2.3 $
*/
public class SecurityInterceptor extends AbstractInterceptor
{
@@ -209,8 +209,9 @@
else if( realmMapping.doesUserHaveRole(principal, methodRoles) == false )
{
String method = mi.getMethod().getName();
+Set userRoles = realmMapping.getUserRoles(principal);
String msg = Insufficient method permissions, principal=+principal
-+ , method=+method+, requiredRoles=+methodRoles;
++ , method=+method+, requiredRoles=+methodRoles+,
principalRoles=+userRoles;
Logger.error(msg);
SecurityException e = new SecurityException(msg);
throw new RemoteException(checkSecurityAssociation, e);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/web AbstractWebContainer.java
User: starksm
Date: 01/09/26 09:00:19
Modified:src/main/org/jboss/web Tag: Branch_2_4
AbstractWebContainer.java
Log:
Drop the local category in favor of the ServiceMBeanSupport category
Revision ChangesPath
No revision
No revision
1.4.4.1 +1 -5 jboss/src/main/org/jboss/web/AbstractWebContainer.java
Index: AbstractWebContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/web/AbstractWebContainer.java,v
retrieving revision 1.4
retrieving revision 1.4.4.1
diff -u -r1.4 -r1.4.4.1
--- AbstractWebContainer.java 2001/05/23 18:21:57 1.4
+++ AbstractWebContainer.java 2001/09/26 16:00:18 1.4.4.1
@@ -113,7 +113,7 @@
@see org.jboss.security.SecurityAssociation;
@author [EMAIL PROTECTED]
-@version $Revision: 1.4 $
+@version $Revision: 1.4.4.1 $
*/
public abstract class AbstractWebContainer extends ServiceMBeanSupport implements
AbstractWebContainerMBean
{
@@ -143,10 +143,6 @@
public void parseWebAppDescriptors(ClassLoader loader, Element webApp,
Element jbossWeb) throws Exception;
}
-/** The WebContainer log4j category instance available for logging related
-to WebContainer events.
- */
-public static final Category category = Category.getInstance(WebContainer);
/** A mapping of deployed warUrl strings to the WebApplication object */
protected HashMap deploymentMap = new HashMap();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/client auth.conf jbosssx-client.jar
User: starksm
Date: 01/09/26 09:04:03
Modified:src/client Tag: Branch_2_4 auth.conf jbosssx-client.jar
Log:
Integrate the Rel_2_4_2_4 JBossSX changes
Revision ChangesPath
No revision
No revision
1.2.6.1 +1 -1 jboss/src/client/Attic/auth.conf
Index: auth.conf
===
RCS file: /cvsroot/jboss/jboss/src/client/Attic/auth.conf,v
retrieving revision 1.2
retrieving revision 1.2.6.1
diff -u -r1.2 -r1.2.6.1
--- auth.conf 2001/03/05 10:31:35 1.2
+++ auth.conf 2001/09/26 16:04:02 1.2.6.1
@@ -1,6 +1,6 @@
srp {
// Example client auth.conf for using the SRPLoginModule
-org.jboss.srp.jaas.SRPLoginModule required
+org.jboss.security.srp.jaas.SRPLoginModule required
password-stacking=useFirstPass
principalClassName=org.jboss.security.SimplePrincipal
srpServerJndiName=SRPServerInterface
1.8.2.11 +44 -44jboss/src/client/Attic/jbosssx-client.jar
Binary file
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
- Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 9:03 AM Subject: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) 1. How does your program find its local directory? I don't want to bind anything in jndi, since jndi may not be started when these local directories are copied. I think it's time for the JBossFilesSystemRoot mbean which anyone can use to find the jboss local directory structure. I'm thinking this would be the first mbean loaded, and could be used by everyone else to find where stuff is. For instance, log4j can find its config files, the ServiceDeployer can find where to put local directories, and your app can find where to look for its local directory. Is this OK with everyone? No, as I may not have a usable local filesystem. Resources should be loaded from thread context class loader, not a filesystem. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
| 1. How does your program find its local directory? I don't want to bind | anything in jndi, since jndi may not be started when these local | directories are copied. I think it's time for the JBossFilesSystemRoot | mbean which anyone can use to find the jboss local directory structure. | I'm thinking this would be the first mbean loaded, and could be used by | everyone else to find where stuff is. For instance, log4j can find its | config files, the ServiceDeployer can find where to put local |directories, | and your app can find where to look for its local directory. Is this OK | with everyone? |No, as I may not have a usable local filesystem. Resources should be loaded |from thread context class loader, not a filesystem. You are right. That is true of resources. But I think the example that he took was poorly chosen (config files). But in the case of MQ it still needs a file system to work so it is relevant that we ship it. The point where I am a bit torn is that we want to tell people stop clinging on your FS, make it web friendly (what you talk about) and on the other hand we need to be realistic about the dependencies on FS these days. I view this as an intermediary solution. marcf | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
On 2001.09.26 12:34:31 -0400 Scott M Stark wrote: - Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 9:03 AM Subject: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) 1. How does your program find its local directory? I don't want to bind anything in jndi, since jndi may not be started when these local directories are copied. I think it's time for the JBossFilesSystemRoot mbean which anyone can use to find the jboss local directory structure. I'm thinking this would be the first mbean loaded, and could be used by everyone else to find where stuff is. For instance, log4j can find its config files, the ServiceDeployer can find where to put local directories, and your app can find where to look for its local directory. Is this OK with everyone? No, as I may not have a usable local filesystem. Resources should be loaded from thread context class loader, not a filesystem. ??? Log4j can get its configuration from a classloader resource, so this was a bad example, however you can't deploy anything without making a local copy first... so you need some kind of usable local filesystem. Marc mentioned earlier that instead of relying on looking up system properites like jboss.system.home it would be a good idea to put this info in an mbean. I'm suggesting putting the copy of local directories location in the same mbean. Are you against the idea of copying specific directories out of a sar verbatim? This whole local directory thing was not my idea, however as I understood it David Maplesden, the Jetty guys, and Jason wanted to be able to put a directory in a sar that would be copied literally into the local filesystem for eg. pre-setup databases, config files, native libraries, and presumably things I haven't heard of. The idea is that they would then have a predictable directory structure at a findable root, that they can write stuff into. If there is no local filesystem available, you won't be able to use a feature like this, but I don't know how you can deploy anything into jboss either. I'm more than happy to take it out if you get marc to agree. thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
|This whole local directory thing was not my idea, however as I understood |it David Maplesden, the Jetty guys, and Jason wanted to be able to put a |directory in a sar that would be copied literally into the local filesystem |for eg. pre-setup databases, config files, native libraries, and presumably |things I haven't heard of. The idea is that they would then have a |predictable directory structure at a findable root, that they can write |stuff into. If there is no local filesystem available, you won't be able |to use a feature like this, but I don't know how you can deploy anything |into jboss either. I'm more than happy to take it out if you get marc to |agree. over my dead body kiddo, david, finish it, you got it marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
- Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:11 AM Subject: RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) | everyone else to find where stuff is. For instance, log4j can find its | config files, the ServiceDeployer can find where to put local |directories, | and your app can find where to look for its local directory. Is this OK | with everyone? |No, as I may not have a usable local filesystem. Resources should be loaded |from thread context class loader, not a filesystem. You are right. That is true of resources. But I think the example that he took was poorly chosen (config files). But in the case of MQ it still needs a file system to work so it is relevant that we ship it. The point where I am a bit torn is that we want to tell people stop clinging on your FS, make it web friendly (what you talk about) and on the other hand we need to be realistic about the dependencies on FS these days. I view this as an intermediary solution. marcf A filesystem should just be another service just like JDBC. Ideally it should be accessed like any other securable managed resource via a resource factory. This is the direction we should be moving in. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
- Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:20 AM Subject: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) directories are copied. I think it's time for the JBossFilesSystemRoot mbean which anyone can use to find the jboss local directory structure. I'm thinking this would be the first mbean loaded, and could be used by everyone else to find where stuff is. For instance, log4j can find its config files, the ServiceDeployer can find where to put local directories, and your app can find where to look for its local directory. Is this OK with everyone? No, as I may not have a usable local filesystem. Resources should be loaded from thread context class loader, not a filesystem. ??? Log4j can get its configuration from a classloader resource, so this was a bad example, however you can't deploy anything without making a local copy first... so you need some kind of usable local filesystem. Marc mentioned earlier that instead of relying on looking up system properites like jboss.system.home it would be a good idea to put this info in an mbean. I'm suggesting putting the copy of local directories location in the same mbean. Are you against the idea of copying specific directories out of a sar verbatim? This whole local directory thing was not my idea, however as I understood it David Maplesden, the Jetty guys, and Jason wanted to be able to put a directory in a sar that would be copied literally into the local filesystem for eg. pre-setup databases, config files, native libraries, and presumably things I haven't heard of. The idea is that they would then have a predictable directory structure at a findable root, that they can write stuff into. If there is no local filesystem available, you won't be able to use a feature like this, but I don't know how you can deploy anything into jboss either. I'm more than happy to take it out if you get marc to agree. thanks david jencks That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
|A filesystem should just be another service just like JDBC. Ideally it |should be |accessed like any other securable managed resource via a resource factory. |This |is the direction we should be moving in. interesting... yes, you are probably right here. marcf | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
On 2001.09.26 13:51:23 -0400 Scott M Stark wrote: - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:20 AM Subject: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) directories are copied. I think it's time for the JBossFilesSystemRoot mbean which anyone can use to find the jboss local directory structure. I'm thinking this would be the first mbean loaded, and could be used by everyone else to find where stuff is. For instance, log4j can find its config files, the ServiceDeployer can find where to put local directories, and your app can find where to look for its local directory. Is this OK with everyone? No, as I may not have a usable local filesystem. Resources should be loaded from thread context class loader, not a filesystem. ??? Log4j can get its configuration from a classloader resource, so this was a bad example, however you can't deploy anything without making a local copy first... so you need some kind of usable local filesystem. Marc mentioned earlier that instead of relying on looking up system properites like jboss.system.home it would be a good idea to put this info in an mbean. I'm suggesting putting the copy of local directories location in the same mbean. Are you against the idea of copying specific directories out of a sar verbatim? This whole local directory thing was not my idea, however as I understood it David Maplesden, the Jetty guys, and Jason wanted to be able to put a directory in a sar that would be copied literally into the local filesystem for eg. pre-setup databases, config files, native libraries, and presumably things I haven't heard of. The idea is that they would then have a predictable directory structure at a findable root, that they can write stuff into. If there is no local filesystem available, you won't be able to use a feature like this, but I don't know how you can deploy anything into jboss either. I'm more than happy to take it out if you get marc to agree. thanks david jencks That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. Hmm, I guess I should experiment and see if a url like jar:jar:http://.../myrar.rar!/path/myjar.jar!/ works to get to the jar inside a rar... maybe we don't need to unpack these things. Scott, does the idea of a mbean providing where the local filesystem is fit in better to your securable resource idea than looking up jboss.system.home and accessing the filesystem? Can you be more specific about what the interface to this system would look like? Would you get files out of it? I'm going to commit (after a couple more tests) what I have now that uses the jboss.system.home directly, so we can play with it, and hopefully a better solution will emerge soon. thanks David Jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
Hmm, I guess I should experiment and see if a url like jar:jar:http://.../myrar.rar!/path/myjar.jar!/ works to get to the jar inside a rar... maybe we don't need to unpack these things. Scott, does the idea of a mbean providing where the local filesystem is fit in better to your securable resource idea than looking up jboss.system.home and accessing the filesystem? Can you be more specific about what the interface to this system would look like? Would you get files out of it? I'm more inclined to access jboss/system/home from JNDI and have this be setup as a filesystem context using the ExternalContext mbean. The interface should be a JNDI DirContext that has attributes for the things one normally obtains from a file. For example, take the jboss/system/home/db/jbossmq/QUEUE.A.dat29 file as a DirContext and there could be the following attributes + QUEUE.A.dat29 | -- lastModified = Date of last modification | -- size = size of file in bytes | -- in = java.io.InputStream for reading the file | -- out = java.io.OutputStream for writing the file | etc. This would require a file system provider implementation for use by JBossNS. The Sun provider does not provide this File independent view of the filesystem. Alternatively, how would the J2EE connector APIs work for exposing a filesystem? I'm going to commit (after a couple more tests) what I have now that uses the jboss.system.home directly, so we can play with it, and hopefully a better solution will emerge soon. Fine for now. However, everyone needs to be thinking about how to limit dependency on the filesystem. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
On 26 Sep, marc fleury wrote: |A filesystem should just be another service just like JDBC. Ideally it |should be |accessed like any other securable managed resource via a resource factory. |This |is the direction we should be moving in. interesting... yes, you are probably right here. I have been thinking a long time of doing this, to be able to legaly access the filesystem from within beans (;-)), but have never had the time to do it. It should be farly easy once we know the API we want, since we already have at least one ra (JMS) to steel and borow from. //Peter marcf | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories.(rh/3.0)
That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. Lets not fall into the trap Sun did with Java and *limit* the API based on what plafroms do not support. I agree that JNDI is a good choice for look up of such resources, but it is clear that the java.io.File crap is not sufficent for robust file system access. Some thing like the NetBeans FileSystem API: http://www.netbeans.org/download/apis/org/openide/filesystems/doc-files/api.html Not that I have looked into it much, but the concept is solid. Map a fs to a cvs repo, a website (read-only|put, read-write|getput)... --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
|normally obtains from a file. For example, take the |jboss/system/home/db/jbossmq/QUEUE.A.dat29 file as a DirContext and |there could be the following attributes |+ QUEUE.A.dat29 || -- lastModified = Date of last modification || -- size = size of file in bytes || -- in = java.io.InputStream for reading the file || -- out = java.io.OutputStream for writing the file || etc. huh... interesting indeed... this does provide a portable way to access file systems, local or not... interesting you are making the distributed filesystem view of JNDI I love to rap about so much a concrete reality. |Fine for now. However, everyone needs to be thinking about how to limit |dependency on the filesystem. If it is truly distributed it is then just a persistent storage view of things. That is what the filesystem was and will always be... just a 'persistent store' on clumsy disks. We abstract that view in something more web friendly. Once we re-invent the feel of files in the web then we can go back and say files ok but for now you are absolutely right, we need to limit the usage of the files as people understand LOCAL FS which is bad. marcf | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
NetBeans appears to have quite a rich interface after a quick read of the link you provided. But it's an IDE so it has a need for all of that. How rich an interface does JBoss need, I have been just sort of following the emails and not thinking too hard. Did this need start with a desire to load configuration files, or is there more to it? Cheers -Original Message- From: Jason Dillon To: [EMAIL PROTECTED] Sent: 9/26/01 3:20 PM Subject: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. Lets not fall into the trap Sun did with Java and *limit* the API based on what plafroms do not support. I agree that JNDI is a good choice for look up of such resources, but it is clear that the java.io.File crap is not sufficent for robust file system access. Some thing like the NetBeans FileSystem API: http://www.netbeans.org/download/apis/org/openide/filesystems/doc-files/ api.html Not that I have looked into it much, but the concept is solid. Map a fs to a cvs repo, a website (read-only|put, read-write|getput)... --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite build.xml
User: starksm
Date: 01/09/26 13:16:36
Modified:.build.xml
Log:
Create a j2ee/dtd directory containing server/src/resource/org/jboss/metadata
dtd files so that the DTD uri corresponds to a valid url from which the
latest version may be obtained.
Revision ChangesPath
1.12 +8 -1 newsite/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/newsite/build.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- build.xml 2001/09/12 00:11:27 1.11
+++ build.xml 2001/09/26 20:16:36 1.12
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.11 2001/09/12 00:11:27 user57 Exp $ --
+!-- $Id: build.xml,v 1.12 2001/09/26 20:16:36 starksm Exp $ --
project default=main name=JBoss/Website
@@ -273,6 +273,13 @@
copy todir=${build.docs} filtering=no
fileset dir=${source.docs}
include name=**/*/
+ /fileset
+/copy
+ !-- Make the JBoss DTDs available under j2ee/dtd --
+ mkdir dir=${build.docs}/j2ee/dtd/
+copy todir=${build.docs}/j2ee/dtd filtering=no
+ fileset
dir=${build.snapshots}/jboss-all/server/src/resources/org/jboss/metadata
+ include name=*.dtd/
/fileset
/copy
/target
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directori es. (rh/3.0)
On 2001.09.26 15:26:57 -0400 Jay Walters wrote: NetBeans appears to have quite a rich interface after a quick read of the link you provided. But it's an IDE so it has a need for all of that. How rich an interface does JBoss need, I have been just sort of following the emails and not thinking too hard. Did this need start with a desire to load configuration files, or is there more to it? I think you can _read_ a config file as a classloader resource. My understanding is that the requestors want to be able to do things like set up the filesystem and files for e.g. the jbossmq message storage, and hsqldb db file. Although not thrilled, I do think it's better than setting this stuff up in the jboss build script... I guess that means now _I_ have to set it up to show it really works. david jencks Cheers -Original Message- From: Jason Dillon To: [EMAIL PROTECTED] Sent: 9/26/01 3:20 PM Subject: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. Lets not fall into the trap Sun did with Java and *limit* the API based on what plafroms do not support. I agree that JNDI is a good choice for look up of such resources, but it is clear that the java.io.File crap is not sufficent for robust file system access. Some thing like the NetBeans FileSystem API: http://www.netbeans.org/download/apis/org/openide/filesystems/doc-files/ api.html Not that I have looked into it much, but the concept is solid. Map a fs to a cvs repo, a website (read-only|put, read-write|getput)... --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
NetBeans appears to have quite a rich interface after a quick read of the link you provided. But it's an IDE so it has a need for all of that. How rich an interface does JBoss need, I have been just sort of following the emails and not thinking too hard. Did this need start with a desire to load configuration files, or is there more to it? We can not really assume what a service provider will need with respect to file system access, so I would say rich is better. I am just frustrated with the poor fs support from Java nativly. I think that a layer of indirection would really be appropriate when accessing files. As the file could be a native file (java.io.File) or a remoted file (web or cvs or whatever). Java does not really provide a good interface for managing a system of files either. I looked a little a the JNDI FSContext plugin, but it looks like that is very java.io.File specific too. I would like to see an abstraction of a file system used by service applications. I have spent a little time at my current job, writting a simple FileManager to make java.io.File objects more network transparent, but it is a cheesy impl, that serverved only to get the immediate job done. WebOS will need a robust network file system, or rather an absract API to access files to be really successfull. As I remember the WebOS bits from MS were based on a WebFS, or perhaps that was another WebOS... not really sure how many of them there are. Anyways, the class loader stuff is nice, as it makes it easy to pull in files, but it sucks when you really need to work with a set of files. We can build a system to make accessing such a set network transparent (based on http, rmi, whatever). The questions are: has anyone else done it already in open source? does it provide most if not all of the immediate functionality required? is it an active project, if not could we fork it? Lets not reinvent to wheel... it is a really good design. Lets worry about the vehicle and try to find quality parts which will work out of the box or with minor modifications (forks). --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MDB non-xa cf tx timeout
Hi, Jason Dillon wrote: I ran some tests last night with the TransactionManager.TransactionTimeout set toInteger.MAX_VALUE, and I am still getting these messages: org.jboss.tm.TxCapsule [Thread-5] () - Transaction XidImpl [FormatId=257, GlobalId=eng-ecr5a//0, BranchQual=] timed out. status=STATUS_ACTIVE That shouldn't happen. Just looked into the code I wrote, and it looks like you have found a bug in it: In org.jboss.tm.TxManager line 314, the new timeout in milliseconds is calculated with the expression: timeout = 1000 * seconds; I guess it should have been timeout = 1000L * seconds; to enforce widening _before_ the multiplication. Maybe Integer.MAX_VALUE/1000 is long enough for you until i get around to committing a fix? Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] hrm....
Jason Dillon wrote: perhaps Integer.MAX_VALUE isn't the best thing to set the default tx timeout too. Does anyone know what happens with this value is 0 ? Is there any way to turn this off altogether? No, it cannot be turned off completely. It was meant to be able to be set to a value higher than the expected lifetime of the server, but due to a bug in TxManager, it can currently not be set to values higher than about four years :-) Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss test dependencies
Hi, Scott M Stark wrote: No, the WebIntegrationTestCase doesn't apply unless the server has a web container configured. The test checks for the existence of a web container and set the webServerAvailable accordingly. Strange, when searching the main branch sources, i see this field referenced only within the WebServerIntegrationTestCase, and here it is never modified from its default value. Maybe in some other branch? In the main branch, it looks like Jetty runs fine, and (apart from some tests failing) I have no problems changing this field to true, and changing the field baseURL to the value http://localhost:8080/;. Best Regards, Ole Husgaard. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Ole Husgaard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 25, 2001 2:05 PM Subject: Re: [JBoss-dev] jboss test dependencies Hi, I committed this. When manually deploying the ear and browsing to the URL of the test servlet I wrote, an exception is thrown as expected when I have not yet added a fix for the bug. With my bug fix added, the servlet runs fine. But when running the test using the WebIntegrationTestCase the test case passes even if the bugfix is not applied. This seems to be because the static boolean field webServerAvailable defaults to false. I am a bit confused about this. For the web test suite to make sense, shouldn't this field be true, and shouldn't the field baseURL have the value http://localhost:8080/; instead of the default null value? If I make these changes, my UserTransaction test fails as expected. Unfortunately also makes the testSnoopJSP, testClientLoginServlet, testSecureServlet, testSecureEJBAccess and testIncludeEJB tests fail. Best Regards, Ole Husgaard ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/tm/usertx/client ServerVMClientUserTransaction.java ClientUserTransaction.java ClientUserTransactionObjectFactory.java
User: sparre
Date: 01/09/26 13:50:21
Modified:src/main/org/jboss/tm/usertx/client
ClientUserTransaction.java
ClientUserTransactionObjectFactory.java
Added: src/main/org/jboss/tm/usertx/client
ServerVMClientUserTransaction.java
Log:
Fixed bug #463790
Revision ChangesPath
1.3 +4 -38
jboss/src/main/org/jboss/tm/usertx/client/ClientUserTransaction.java
Index: ClientUserTransaction.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/tm/usertx/client/ClientUserTransaction.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ClientUserTransaction.java2001/08/03 17:15:57 1.2
+++ ClientUserTransaction.java2001/09/26 20:50:21 1.3
@@ -46,7 +46,7 @@
* propagation contexts of the transactions started here.
*
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class ClientUserTransaction
implements UserTransaction,
@@ -79,19 +79,9 @@
*/
private ClientUserTransaction()
{
- // See if we have a local TM
- try {
- new InitialContext().lookup(java:/TransactionManager);
-
- // This instance lives in the server.
- isInServer = true;
- } catch (NamingException ex) {
- // This instance lives in a stand-alone client.
- isInServer = false;
-
- // No local TM: Set TPC Factory on GenericProxy.
- GenericProxy.setTPCFactory(this);
- }
+ // Tell the proxy that this is the factory for
+ // transaction propagation contexts.
+ GenericProxy.setTPCFactory(this);
}
// Public
@@ -103,9 +93,6 @@
public void begin()
throws NotSupportedException, SystemException
{
- if (isInServer)
- throw new SystemException(Cannot use this in the server.);
-
ThreadInfo info = getThreadInfo();
try {
@@ -130,9 +117,6 @@
IllegalStateException,
SystemException
{
- if (isInServer)
- throw new SystemException(Cannot use this in the server.);
-
ThreadInfo info = getThreadInfo();
try {
@@ -165,9 +149,6 @@
IllegalStateException,
SystemException
{
- if (isInServer)
- throw new SystemException(Cannot use this in the server.);
-
ThreadInfo info = getThreadInfo();
try {
@@ -192,9 +173,6 @@
throws IllegalStateException,
SystemException
{
- if (isInServer)
- throw new SystemException(Cannot use this in the server.);
-
ThreadInfo info = getThreadInfo();
try {
@@ -215,9 +193,6 @@
public int getStatus()
throws SystemException
{
- if (isInServer)
- throw new SystemException(Cannot use this in the server.);
-
ThreadInfo info = getThreadInfo();
Object tpc = info.getTpc();
@@ -240,9 +215,6 @@
public void setTransactionTimeout(int seconds)
throws SystemException
{
- if (isInServer)
- throw new SystemException(Cannot use this in the server.);
-
getThreadInfo().setTimeout(seconds);
}
@@ -279,12 +251,6 @@
// Private ---
-
- /**
-* Flag that this instance is living in the server.
-* Instances living in the server VM cannot be used.
-*/
- private boolean isInServer;
/**
* The RMI remote interface to the real tx service
1.4 +35 -5
jboss/src/main/org/jboss/tm/usertx/client/ClientUserTransactionObjectFactory.java
Index: ClientUserTransactionObjectFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/tm/usertx/client/ClientUserTransactionObjectFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ClientUserTransactionObjectFactory.java 2001/08/03 17:15:57 1.3
+++ ClientUserTransactionObjectFactory.java 2001/09/26 20:50:21 1.4
@@ -10,10 +10,13 @@
import java.util.Hashtable;
import javax.naming.Context;
+import javax.naming.InitialContext;
import javax.naming.Reference;
import javax.naming.Name;
+import javax.naming.NamingException;
import javax.naming.spi.ObjectFactory;
+import javax.transaction.UserTransaction;
/**
* This is an object factory for producing client
@@ -21,21 +24,48 @@
* usage for standalone clients.
*
* @author a href=mailto:[EMAIL
[JBoss-dev] CVS update: jboss/src/main/org/jboss/tm TxManager.java
User: sparre
Date: 01/09/26 14:01:24
Modified:src/main/org/jboss/tm TxManager.java
Log:
Setting extremely high timeout values could lead to and undetected integer
multiplication overflow and wrong timeout settings.
Revision ChangesPath
1.33 +2 -2 jboss/src/main/org/jboss/tm/TxManager.java
Index: TxManager.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/tm/TxManager.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- TxManager.java2001/08/11 02:38:33 1.32
+++ TxManager.java2001/09/26 21:01:24 1.33
@@ -35,7 +35,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
- * @version $Revision: 1.32 $
+ * @version $Revision: 1.33 $
*/
public class TxManager
implements TransactionManager,
@@ -311,7 +311,7 @@
*/
public void setDefaultTransactionTimeout(int seconds)
{
- timeOut = 1000 * seconds;
+ timeOut = 1000L * seconds;
if (debug) {
log.debug(default tx timeout is now: + seconds + s);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx/mbeanlocaldir - New directory
User: d_jencks Date: 01/09/26 14:24:57 jbosstest/src/resources/jmx/mbeanlocaldir - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx/mbeane - New directory
User: d_jencks Date: 01/09/26 14:24:57 jbosstest/src/resources/jmx/mbeane - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss test dependencies
Its set at line 76 of org.jboss.test.web.test.WebIntegrationUnitTestCase: webServerAvailable = getServer().isRegistered(deployerName); - Original Message - From: Ole Husgaard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 2:02 PM Subject: Re: [JBoss-dev] jboss test dependencies Hi, Scott M Stark wrote: No, the WebIntegrationTestCase doesn't apply unless the server has a web container configured. The test checks for the existence of a web container and set the webServerAvailable accordingly. Strange, when searching the main branch sources, i see this field referenced only within the WebServerIntegrationTestCase, and here it is never modified from its default value. Maybe in some other branch? In the main branch, it looks like Jetty runs fine, and (apart from some tests failing) I have no problems changing this field to true, and changing the field baseURL to the value http://localhost:8080/;. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmx/mbeane - New directory
User: d_jencks Date: 01/09/26 14:24:57 jbosstest/src/main/org/jboss/test/jmx/mbeane - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx/mbeanlocaldir/local-directory - New directory
User: d_jencks Date: 01/09/26 14:31:02 jbosstest/src/resources/jmx/mbeanlocaldir/local-directory - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx/mbeanlocaldir/local-directory examplefile.xml
User: d_jencks Date: 01/09/26 14:47:06 Added: src/resources/jmx/mbeanlocaldir/local-directory examplefile.xml Log: ServiceDeployer: added local dir support, undeploy support for depends, reworked classpath dependencies. Changed config files to work. REMOVE core-service.xml or build.sh cleancvs update -d -P update11.log Revision ChangesPath 1.1 jbosstest/src/resources/jmx/mbeanlocaldir/local-directory/examplefile.xml Index: examplefile.xml === ?xml version=1.0 encoding=UTF-8? !-- EXAMPLE META-INF/jboss-service.xml file for the connector stuff in deploy/lib No classpath is specified here as it points to the same jsr file You can nevertheless specify a URL classpath that points outside the jar -- server mbean code=org.jboss.test.jmx.mbean.TestDeployer name=test:name=TestDeployer/ /server ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx/mbeand/META-INF jboss-service.xml
User: d_jencks Date: 01/09/26 14:47:06 Modified:src/resources/jmx/mbeand/META-INF jboss-service.xml Log: ServiceDeployer: added local dir support, undeploy support for depends, reworked classpath dependencies. Changed config files to work. REMOVE core-service.xml or build.sh cleancvs update -d -P update11.log Revision ChangesPath 1.3 +6 -4 jbosstest/src/resources/jmx/mbeand/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/jmx/mbeand/META-INF/jboss-service.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jboss-service.xml 2001/09/26 21:47:05 1.2 +++ jboss-service.xml 2001/09/26 21:47:05 1.3 @@ -3,10 +3,12 @@ !-- test META-INF/jboss-service.xml file for the depends element-- server - dependstest:name=TestDeployerA/depends - dependstest:name=TestDeployerC/depends + classpath +codebase=. +archives=testdeploya.sar,testdeployb.sar + / - mbean code=org.jboss.test.jmx.mbeand.TestDeployerD - name=test:name=TestDeployerD/ + mbean code=org.jboss.test.jmx.mbeane.TestDeployerE + name=test:name=TestDeployerE/ /server ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: d_jencks
Date: 01/09/26 14:47:04
Modified:.build.xml
Log:
ServiceDeployer: added local dir support, undeploy support for depends, reworked
classpath dependencies. Changed config files to work. REMOVE core-service.xml or
build.sh cleancvs update -d -P update11.log
Revision ChangesPath
1.31 +18 -8 jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss/build.xml,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- build.xml 2001/09/16 05:27:44 1.30
+++ build.xml 2001/09/26 21:47:03 1.31
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.30 2001/09/16 05:27:44 d_jencks Exp $ --
+!-- $Id: build.xml,v 1.31 2001/09/26 21:47:03 d_jencks Exp $ --
project default=main name=JBoss/Server
@@ -558,6 +558,8 @@
include name=org/jboss/deployment/ServiceDeployerMBean.class/
include name=org/jboss/deployment/ServiceDeployer**.class/
include name=org/jboss/deployment/DeployerMBean.class/
+include name=org/jboss/deployment/DeployerMBeanSupport.class/
+include name=org/jboss/deployment/DeployerMBeanSupport**.class/
include name=org/jboss/deployment/DeploymentException.class/
/fileset
/jar
@@ -605,8 +607,8 @@
fileset dir=${build.resources}/org/jboss/verifier/
/jar
-!-- Build jmx-rmi-connector-server.jsr (should try to use jlink for this)--
-jar jarfile=${build.lib}/jmx-rmi-connector-server.jsr
+!-- Build jmx-rmi-connector-server.sar (should try to use jlink for this)--
+jar jarfile=${build.lib}/jmx-rmi-connector-server.sar
!-- manifest=${build.etc}/rmiconnector.mf --
fileset dir=${build.classes}
include name=org/jboss/jmx/ObjectHandler**/
@@ -644,8 +646,8 @@
/fileset
/jar
-!-- Build jmx-ejb-connector-server.jsr (should try to use jlink for this)--
-jar jarfile=${build.lib}/jmx-ejb-connector-server.jsr
+!-- Build jmx-ejb-connector-server.sar (should try to use jlink for this)--
+jar jarfile=${build.lib}/jmx-ejb-connector-server.sar
!-- manifest=${build.etc}/ejb-connector-server.mf --
fileset dir=${build.classes}
include name=org/jboss/jmx/connector/notification/**/
@@ -656,9 +658,9 @@
/fileset
/jar
-!-- Build jmx-html-adaptor.jsr (should try to use jlink for this)--
+!-- Build jmx-html-adaptor.sar (should try to use jlink for this)--
unjar src=${sun.jmx.lib}/jmxtools.jar dest=${build.classes}/
-jar jarfile=${build.lib}/jmx-html-adaptor.jsr
+jar jarfile=${build.lib}/jmx-html-adaptor.sar
!-- manifest=${build.etc}/rmiconnector.mf --
fileset dir=${build.classes}
include name=org/jboss/jmx/interfaces/**/
@@ -741,9 +743,17 @@
/jar
!-- Build jms-ra.rar --
-jar jarfile=${build.lib}/jms-ra.rar
+!-- First build the inside jar --
+jar jarfile=${build.lib}/jms-ra.jar
fileset dir=${build.classes}
include name=org/jboss/jms/ra/**/
+ /fileset
+/jar
+
+!-- Now build the rar containing the jar and the ra.xml --
+jar jarfile=${build.lib}/jms-ra.rar
+ fileset dir=${build.lib}
+include name=jms-ra.jar/
/fileset
fileset dir=${build.resources}/org/jboss/jms/ra/
include name=**/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx/mbeand/META-INF jboss-service.xml
User: d_jencks Date: 01/09/26 14:47:05 Modified:src/resources/jmx/mbeand/META-INF jboss-service.xml Log: ServiceDeployer: added local dir support, undeploy support for depends, reworked classpath dependencies. Changed config files to work. REMOVE core-service.xml or build.sh cleancvs update -d -P update11.log Revision ChangesPath 1.2 +3 -5 jbosstest/src/resources/jmx/mbeand/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/jmx/mbeand/META-INF/jboss-service.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jboss-service.xml 2001/09/08 16:57:06 1.1 +++ jboss-service.xml 2001/09/26 21:47:05 1.2 @@ -1,12 +1,10 @@ ?xml version=1.0 encoding=UTF-8? -!-- test META-INF/jboss-service.xml file for a recursive deployment.-- +!-- test META-INF/jboss-service.xml file for the depends element-- server - classpath -codebase=. -archives=testdeployc.sar - / + dependstest:name=TestDeployerA/depends + dependstest:name=TestDeployerC/depends mbean code=org.jboss.test.jmx.mbeand.TestDeployerD name=test:name=TestDeployerD/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jmx/connector/ejb/META-INF jboss-service.xml
User: d_jencks Date: 01/09/26 14:47:05 Modified:src/main/org/jboss/jmx/connector/ejb/META-INF jboss-service.xml Log: ServiceDeployer: added local dir support, undeploy support for depends, reworked classpath dependencies. Changed config files to work. REMOVE core-service.xml or build.sh cleancvs update -d -P update11.log Revision ChangesPath 1.3 +1 -4 jboss/src/main/org/jboss/jmx/connector/ejb/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jmx/connector/ejb/META-INF/jboss-service.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jboss-service.xml 2001/09/13 07:38:15 1.2 +++ jboss-service.xml 2001/09/26 21:47:05 1.3 @@ -2,8 +2,5 @@ server - classpath archives= - jmx-ejb-connector-server.jar - / - +!--why not create the mbean in this-- /server ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.xml
User: d_jencks
Date: 01/09/26 14:47:03
Modified:jettybuild.xml
Log:
ServiceDeployer: added local dir support, undeploy support for depends, reworked
classpath dependencies. Changed config files to work. REMOVE core-service.xml or
build.sh cleancvs update -d -P update11.log
Revision ChangesPath
1.9 +22 -4 contrib/jetty/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- build.xml 2001/09/12 00:08:42 1.8
+++ build.xml 2001/09/26 21:47:03 1.9
@@ -245,6 +245,7 @@
!-- Where source files live --
property name=source.java value=${module.source}/main/
property name=source.etc value=${module.source}/etc/
+property name=source.resources value=${module.source}/resources/
!-- Where build generated files will go --
property name=build.classes value=${module.output}/classes/
@@ -252,6 +253,7 @@
property name=build.api value=${module.output}/api/
property name=build.etc value=${module.output}/etc/
property name=build.reports value=${module.output}/reports/
+property name=build.resources value=${module.output}/resources/
!-- Install/Release structure --
property name=install.id value=${module.name}-${module.version}/
@@ -305,7 +307,7 @@
| documentation compiles.
--
target name=compile
- depends=compile-classes, compile-etc
+ depends=compile-classes, compile-etc, compile-resources
description=Compile all source files./
!-- Compile all class files --
@@ -338,7 +340,18 @@
/copy
/target
+ !-- Compile resource files --
+ target name=compile-resources depends=init
+mkdir dir=${build.resources}/
+copy todir=${build.resources} filtering=yes
+ fileset dir=${source.resources}
+ include name=**/*/
+ /fileset
+/copy
+ /target
+
+
!-- == --
!-- Archives --
!-- == --
@@ -346,16 +359,21 @@
!--
| Build all jar files.
--
- target name=jars depends=compile description=Builds all jar files.
+
+ target name=jars depends=compile description=Build the Service
+Archive
mkdir dir=${build.lib}/
-!-- Build the module jar --
-jar jarfile=${build.lib}/${module.name}.jar
+jar jarfile=${build.lib}/${module.name}.sar
fileset dir=${build.classes}
+include name=**/
+ /fileset
+ fileset dir=${build.resources}/jetty-plugin
include name=**/*/
/fileset
/jar
/target
+
!-- == --
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx/mbean/META-INF jboss-service.xml
User: d_jencks Date: 01/09/26 14:47:06 Modified:src/resources/jmx/mbean/META-INF jboss-service.xml Log: ServiceDeployer: added local dir support, undeploy support for depends, reworked classpath dependencies. Changed config files to work. REMOVE core-service.xml or build.sh cleancvs update -d -P update11.log Revision ChangesPath 1.2 +2 -0 jbosstest/src/resources/jmx/mbean/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/jmx/mbean/META-INF/jboss-service.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jboss-service.xml 2001/09/08 16:57:05 1.1 +++ jboss-service.xml 2001/09/26 21:47:06 1.2 @@ -6,6 +6,8 @@ -- server + + local-directory path=local-directory/ mbean code=org.jboss.test.jmx.mbean.TestDeployer name=test:name=TestDeployer/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx/mbeanlocaldir/local-directory/sub-directory - New directory
User: d_jencks Date: 01/09/26 14:40:15 jbosstest/src/resources/jmx/mbeanlocaldir/local-directory/sub-directory - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
User: d_jencks
Date: 01/09/26 14:47:04
Modified:src/main/org/jboss Main.java
Log:
ServiceDeployer: added local dir support, undeploy support for depends, reworked
classpath dependencies. Changed config files to work. REMOVE core-service.xml or
build.sh cleancvs update -d -P update11.log
Revision ChangesPath
1.50 +6 -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.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- Main.java 2001/09/19 01:20:51 1.49
+++ Main.java 2001/09/26 21:47:04 1.50
@@ -43,7 +43,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
- * @version $Revision: 1.49 $
+ * @version $Revision: 1.50 $
*
* bRevisions:/b
* p
@@ -128,7 +128,11 @@
while (bootURLs.hasNext())
{
// The libraries will register themselves with the libraries
-new URLClassLoader(new URL[]{(URL)bootURLs.next()});
+URL thisUrl = (URL)bootURLs.next();
+//Only the boot urls are keyed on themselves:
+//everything else is copied for loading but keyed on the
+//original deployed url.
+new URLClassLoader(new URL[]{thisUrl}, thisUrl);
}
// Create MBeanClassLoader for the base system
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/system ServiceController.java ServiceLibraries.java URLClassLoader.java URLClassLoaderMBean.java
User: d_jencks
Date: 01/09/26 14:47:05
Modified:src/main/org/jboss/system ServiceController.java
ServiceLibraries.java URLClassLoader.java
URLClassLoaderMBean.java
Log:
ServiceDeployer: added local dir support, undeploy support for depends, reworked
classpath dependencies. Changed config files to work. REMOVE core-service.xml or
build.sh cleancvs update -d -P update11.log
Revision ChangesPath
1.8 +10 -5 jboss/src/main/org/jboss/system/ServiceController.java
Index: ServiceController.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/ServiceController.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ServiceController.java2001/09/20 18:23:41 1.7
+++ ServiceController.java2001/09/26 21:47:05 1.8
@@ -40,7 +40,7 @@
* @see org.jboss.system.Service
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.7 $ p
+ * @version $Revision: 1.8 $ p
*
* bRevisions:/b p
*
@@ -229,15 +229,12 @@
*/
public void undeploy(ObjectName objectName) throws Exception
{
- if (log.isDebugEnabled()) {
- log.debug(undeploying + objectName + from server);
- }
// Do we have a deployed MBean?
if (server.isRegistered(objectName))
{
if (log.isDebugEnabled()) {
-log.debug(undeploying + objectName + from server);
+log.debug(undeploying + objectName + from server);
}
//Remove from local maps
@@ -252,6 +249,14 @@
new ObjectName(ZClassLoaders:id= + objectName.hashCode());
server.unregisterMBean(loader);
}
+ else
+ {
+ if (log.isDebugEnabled()) {
+log.debug(no need to undeploy + objectName + from server);
+ }
+
+ } // end of else
+
}
// MBeanRegistration implementation
1.4 +3 -3 jboss/src/main/org/jboss/system/ServiceLibraries.java
Index: ServiceLibraries.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/ServiceLibraries.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ServiceLibraries.java 2001/09/08 17:08:32 1.3
+++ ServiceLibraries.java 2001/09/26 21:47:05 1.4
@@ -29,7 +29,7 @@
*
* @see related
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @version $Revision: 1.3 $ p
+ * @version $Revision: 1.4 $ p
*
* b20010830 marc fleury:/b
* ulinitial import
@@ -184,11 +184,11 @@
if (!classLoaders.contains(cl))
{
classLoaders.add(cl);
-System.out.println(Libraries adding URLClassLoader + cl.hashCode() +
URL + ((URLClassLoader)cl).getURL().toString());
+System.out.println(Libraries adding URLClassLoader + cl.hashCode() +
key URL + ((URLClassLoader)cl).getKeyURL().toString());
}
else
{
-System.out.println(Libraries skipping duplicate URLClassLoader for URL
+ ((URLClassLoader)cl).getURL().toString());
+System.out.println(Libraries skipping duplicate URLClassLoader for key
URL + ((URLClassLoader)cl).getKeyURL().toString());
}
}
}
1.4 +40 -35jboss/src/main/org/jboss/system/URLClassLoader.java
Index: URLClassLoader.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/URLClassLoader.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- URLClassLoader.java 2001/09/12 02:10:23 1.3
+++ URLClassLoader.java 2001/09/26 21:47:05 1.4
@@ -29,7 +29,7 @@
*resources and classes.
*
* @author a href=[EMAIL PROTECTED]Marc Fleury/a
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*
* pb20010830 marc fleury:/b
* ul
@@ -40,10 +40,15 @@
extends java.net.URLClassLoader
implements URLClassLoaderMBean
{
- /** One URL per classLoader in our case */
- private URL url = null;
+ /** One URL per classLoader in our case
+* This is just a key used for identifying the classloader,
+* nothing is actually loaded from it. Classes and resources are
+* loaded from local copies or unpacked local copies.
+*/
+ private URL keyUrl = null;
+
/** An SCL can also be loading on behalf of an MBean */
- private ObjectName mbean = null;
+//private ObjectName mbean = null; not used
[JBoss-dev] CVS update: jbosstest build.xml
User: d_jencks
Date: 01/09/26 14:47:05
Modified:.build.xml
Log:
ServiceDeployer: added local dir support, undeploy support for depends, reworked
classpath dependencies. Changed config files to work. REMOVE core-service.xml or
build.sh cleancvs update -d -P update11.log
Revision ChangesPath
1.32 +21 -1 jbosstest/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosstest/build.xml,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- build.xml 2001/09/25 18:07:10 1.31
+++ build.xml 2001/09/26 21:47:05 1.32
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.31 2001/09/25 18:07:10 sparre Exp $ --
+!-- $Id: build.xml,v 1.32 2001/09/26 21:47:05 d_jencks Exp $ --
project default=main name=JBoss/Testsuite
@@ -906,6 +906,26 @@
/fileset
fileset dir=${build.resources}/jmx/mbeand
include name=META-INF/jboss-service.xml/
+ /fileset
+/jar
+
+jar jarfile=${build.lib}/testdeploye.sar
+ fileset dir=${build.classes}
+include name=org/jboss/test/jmx/mbeane/**/
+ /fileset
+ fileset dir=${build.resources}/jmx/mbeane
+include name=META-INF/jboss-service.xml/
+ /fileset
+/jar
+
+!--build test sar for testing local directory copy deployment --
+jar jarfile=${build.lib}/testcopylocaldir.sar
+ fileset dir=${build.classes}
+include name=org/jboss/test/jmx/mbean/**/
+ /fileset
+ fileset dir=${build.resources}/jmx/mbeanlocaldir
+include name=META-INF/jboss-service.xml/
+include name=local-directory/**/
/fileset
/jar
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default hsql-default-service.xml j2eedeployment-service.xml jboss-service.xml jms-service.xml core-service.xml
User: d_jencks Date: 01/09/26 14:47:04 Modified:src/etc/conf/default hsql-default-service.xml j2eedeployment-service.xml jboss-service.xml jms-service.xml Removed: src/etc/conf/default core-service.xml Log: ServiceDeployer: added local dir support, undeploy support for depends, reworked classpath dependencies. Changed config files to work. REMOVE core-service.xml or build.sh cleancvs update -d -P update11.log Revision ChangesPath 1.3 +6 -2 jboss/src/etc/conf/default/hsql-default-service.xml Index: hsql-default-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/hsql-default-service.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- hsql-default-service.xml 2001/09/11 02:48:05 1.2 +++ hsql-default-service.xml 2001/09/26 21:47:04 1.3 @@ -7,18 +7,22 @@ !-- -- !-- = -- -!-- $Id: hsql-default-service.xml,v 1.2 2001/09/11 02:48:05 dmaplesden Exp $ -- +!-- $Id: hsql-default-service.xml,v 1.3 2001/09/26 21:47:04 d_jencks Exp $ -- server dependsJBOSS-SYSTEM:service=Naming/depends dependsJBOSS-SYSTEM:service=TransactionManager/depends + dependsJCA:service=ConnectionManagerFactoryLoader,name=MinervaSharedLocalCMFactory/depends + dependsJCA:service=RARDeployer/depends classpath archives= hsql.jar, - jbosscx.sar, hsql-plugin.jar/ +!--rely on ConnectionFactoryLoader packages with ConnectionManagerFactoryLoader-- + !--classpath codebase=. archives= + jbosscx.sar/-- !-- -- !-- JDBC - Initialize the databases -- 1.5 +8 -1 jboss/src/etc/conf/default/j2eedeployment-service.xml Index: j2eedeployment-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/j2eedeployment-service.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- j2eedeployment-service.xml2001/09/17 00:59:04 1.4 +++ j2eedeployment-service.xml2001/09/26 21:47:04 1.5 @@ -10,7 +10,7 @@ !-- -- mbean code=org.jboss.ejb.ContainerFactory - name=:service=ContainerFactory + name=JBOSS-SYSTEM:service=ContainerFactory attribute name=VerifyDeploymentstrue/attribute attribute name=ValidateDTDsfalse/attribute attribute name=MetricsEnabledfalse/attribute @@ -37,5 +37,12 @@ attribute name=WarDeployerNameJBOSS-SYSTEM:service=Jetty/attribute /mbean -- + !-- -- + !-- RAR deployment -- + !-- -- + + mbean code=org.jboss.resource.RARDeployer + name=JCA:service=RARDeployer + /mbean /server 1.13 +130 -16 jboss/src/etc/conf/default/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss-service.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- jboss-service.xml 2001/09/12 23:06:40 1.12 +++ jboss-service.xml 2001/09/26 21:47:04 1.13 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: jboss-service.xml,v 1.12 2001/09/12 23:06:40 dmaplesden Exp $ -- +!-- $Id: jboss-service.xml,v 1.13 2001/09/26 21:47:04 d_jencks Exp $ -- !-- | This is where you can add and configure your MBeans. @@ -33,21 +33,12 @@ classpath archives= castor.jar, castor-jdo-plugin.jar, - org.mortbay.jetty.jar, - org.mortbay.jetty.jmx.jar, - org.mortbay.tools.jar, concurrent.jar, - crimson.jar, - cryptix-sasl-jetty.jar, gnu-regexp.jar, - hsql.jar, - hsql-plugin.jar, jaas.jar, - javac.jar, JavaGroups.jar, javax.servlet.jar, javax-sasl.jar, - jaxp.jar, jbossha.jar, jboss-j2ee.jar, jboss.jar, @@ -55,7 +46,6 @@ jbosspool.jar, jbosssx.jar, jcert.jar, - jetty-plugin.jar, jmxtools.jar, jndi.jar, jnet.jar, @@ -66,20 +56,86 @@ jsse.jar, jts.jar,
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmx/mbeane TestDeployerE.java TestDeployerEMBean.java
User: d_jencks
Date: 01/09/26 14:47:05
Added: src/main/org/jboss/test/jmx/mbeane TestDeployerE.java
TestDeployerEMBean.java
Log:
ServiceDeployer: added local dir support, undeploy support for depends, reworked
classpath dependencies. Changed config files to work. REMOVE core-service.xml or
build.sh cleancvs update -d -P update11.log
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/jmx/mbeane/TestDeployerE.java
Index: TestDeployerE.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.test.jmx.mbeane;
import javax.management.InstanceNotFoundException;
import javax.management.MBeanException;
import javax.management.MBeanServer;
import javax.management.MalformedObjectNameException;
import javax.management.ObjectName;
import javax.management.ReflectionException;
import javax.management.RuntimeMBeanException;
import javax.management.loading.MLet;
import org.jboss.system.Service;
import org.jboss.system.ServiceMBeanSupport;
/**
* This is a do-nothing mbean to test service archive deployment.
*
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
* @version$Revision: 1.1 $ p
*
* b20010901 david jencks/b
* ulinitial import
*li
* /ul
*
*/
public class TestDeployerE
extends ServiceMBeanSupport
implements TestDeployerEMBean
{
public String getName()
{
return TestDeployerE;
}
}
1.1
jbosstest/src/main/org/jboss/test/jmx/mbeane/TestDeployerEMBean.java
Index: TestDeployerEMBean.java
===
/*
* JBoss, the OpenSource J2EE server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.test.jmx.mbeane;
import javax.management.ObjectName;
import org.w3c.dom.Element;
import org.w3c.dom.Document;
import org.jboss.system.Service;
import org.jboss.system.ServiceMBean;
/**
* This is a little class to test deploying jsrs
*
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
*
* @version $Revision: 1.1 $
*
* pbdavid jencks:/b
* ul
* initial import
* li
* /ul
*/
public interface TestDeployerEMBean
extends Service, ServiceMBean
{
// Public
/** The default object name. */
public static final String OBJECT_NAME = test:service=TestDeployerE;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/tm TxManager.java
User: sparre
Date: 01/09/26 14:50:41
Modified:src/main/org/jboss/tm Tag: Branch_2_4 TxManager.java
Log:
Setting extremely high timeout values could give an undetected integer
multiplication overflow, leading to unexpected results.
Revision ChangesPath
No revision
No revision
1.28.4.1 +2 -2 jboss/src/main/org/jboss/tm/TxManager.java
Index: TxManager.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/tm/TxManager.java,v
retrieving revision 1.28
retrieving revision 1.28.4.1
diff -u -r1.28 -r1.28.4.1
--- TxManager.java2001/04/27 16:41:06 1.28
+++ TxManager.java2001/09/26 21:50:41 1.28.4.1
@@ -36,7 +36,7 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @version $Revision: 1.28 $
+ * @version $Revision: 1.28.4.1 $
*/
public class TxManager
implements TransactionManager,
@@ -254,7 +254,7 @@
*/
public void setDefaultTransactionTimeout(int seconds)
{
- timeOut = 1000 * seconds;
+ timeOut = 1000L * seconds;
}
/**
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmx/test DeployServiceUnitTestCase.java
User: d_jencks
Date: 01/09/26 14:47:05
Modified:src/main/org/jboss/test/jmx/test
DeployServiceUnitTestCase.java
Log:
ServiceDeployer: added local dir support, undeploy support for depends, reworked
classpath dependencies. Changed config files to work. REMOVE core-service.xml or
build.sh cleancvs update -d -P update11.log
Revision ChangesPath
1.5 +255 -66
jbosstest/src/main/org/jboss/test/jmx/test/DeployServiceUnitTestCase.java
Index: DeployServiceUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/test/DeployServiceUnitTestCase.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DeployServiceUnitTestCase.java2001/09/20 18:23:41 1.4
+++ DeployServiceUnitTestCase.java2001/09/26 21:47:05 1.5
@@ -29,7 +29,7 @@
/**
* @see related
* @authora href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public class DeployServiceUnitTestCase
extends JBossTestCase
@@ -231,13 +231,6 @@
//we'll believe from testDeployJSR that the classes are available.
- //deploy the test jsrs again, should undeploy and redeploy.
- deployService(testUrlA);
-
- //check deployment registered expected mbeans
- assertTrue(test mbean not registered after redeploy,
getServer().isRegistered(testObjectNameA));
- assertTrue(test mbean not registered after redeploy,
getServer().isRegistered(testObjectNameB));
- assertTrue(test mbean not registered after redeploy,
getServer().isRegistered(testObjectNameC));
//undeploy test xml doc.
undeployService(testUrlA);
@@ -247,40 +240,24 @@
assertTrue(test mbean C still registered after undeploy of A,
!getServer().isRegistered(testObjectNameC));
assertTrue(test mbean B unregistered after undeploy of A,
getServer().isRegistered(testObjectNameB));
- //check the class for C is not available
- try
- {
-ObjectInstance oe =
getServer().createMBean(org.jboss.test.jmx.mbean.TestDeployerC, testObjectName3,
classLoaderObjectName);
-fail(created mbean when class should not be present: object instance:
+ oe);
- }
- catch (ReflectionException re)
- {
-Exception e = re.getTargetException();
-if (!(e instanceof ClassNotFoundException))
-{
- fail(Wrong exception thrown when trying to create mbean + e);
-}
- }
-
//Now undeploy B, should prevent redeploy of C when A is redeployed.
- /*
- * not working, skip for now
- * undeployService(testObjectNameB);
- * assertTrue(test mbean B is registered after undeploy of B,
!getServer().isRegistered(testObjectNameB));
- *
- */
+
+ // not working, skip for now
+ undeployService(testUrlB);
+ assertTrue(test mbean B is registered after undeploy of B,
!getServer().isRegistered(testObjectNameB));
+
//deploy the test jsr A doc a second time.
deployService(testUrlA);
- /*
- * check deployment registered expected mbeans
- * assertTrue(test mbean A not registered after deploy of A,
getServer().isRegistered(testObjectNameA));
- *
- * assertTrue(test mbean B is registered after deploy of A,
!getServer().isRegistered(testObjectNameB));
- *
- * assertTrue(test mbean C is registered after deploy of A, with B
unregistered, !getServer().isRegistered(testObjectNameC));
- */
+
+ // check deployment registered expected mbeans
+ assertTrue(test mbean A not registered after deploy of A,
getServer().isRegistered(testObjectNameA));
+
+ assertTrue(test mbean B is registered after deploy of A,
!getServer().isRegistered(testObjectNameB));
+
+ assertTrue(test mbean C is registered after deploy of A, with B
unregistered, !getServer().isRegistered(testObjectNameC));
+
//now redeploy B, should also redeploy C
- //deployService(testUrlB);
+ deployService(testUrlB);
//check deployment registered expected mbeans- all three should be
registered
assertTrue(test mbean A not registered after deploy of B,
getServer().isRegistered(testObjectNameA));
@@ -311,15 +288,16 @@
/**
-* Test recursive deployment/undeployment of sars. D depends on C, C on A and
-* B. Deploying D should deploy A, B, C, D.
+* Test depends tag D depends on mbeans in A and C.
+* Deploying D should wait
[JBoss-dev] CVS update: jbosstest/src/resources/jmx/mbeanlocaldir/local-directory/sub-directory examplejar.jar
User: d_jencks Date: 01/09/26 14:47:06 Added: src/resources/jmx/mbeanlocaldir/local-directory/sub-directory examplejar.jar Log: ServiceDeployer: added local dir support, undeploy support for depends, reworked classpath dependencies. Changed config files to work. REMOVE core-service.xml or build.sh cleancvs update -d -P update11.log Revision ChangesPath 1.1 jbosstest/src/resources/jmx/mbeanlocaldir/local-directory/sub-directory/examplejar.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource RARDeployer.java
User: d_jencks
Date: 01/09/26 14:47:03
Modified:src/main/org/jboss/resource RARDeployer.java
Log:
ServiceDeployer: added local dir support, undeploy support for depends, reworked
classpath dependencies. Changed config files to work. REMOVE core-service.xml or
build.sh cleancvs update -d -P update11.log
Revision ChangesPath
1.11 +59 -313 jbosscx/src/main/org/jboss/resource/RARDeployer.java
Index: RARDeployer.java
===
RCS file: /cvsroot/jboss/jbosscx/src/main/org/jboss/resource/RARDeployer.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- RARDeployer.java 2001/09/11 18:38:58 1.10
+++ RARDeployer.java 2001/09/26 21:47:03 1.11
@@ -17,7 +17,7 @@
import java.net.JarURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
-import java.net.URLClassLoader;
+//import java.net.URLClassLoader;Replaced with org.jboss.system.URLClassLoader.
import java.util.ArrayList;
import java.util.Collection;
import java.util.Enumeration;
@@ -33,6 +33,8 @@
import org.jboss.deployment.DeploymentException;
import org.jboss.logging.Logger;
import org.jboss.metadata.XmlFileLoader;
+import org.jboss.system.ServiceLibraries;
+import org.jboss.system.URLClassLoader;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
@@ -46,7 +48,7 @@
*
* @author Toby Allsopp ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
-* @version$Revision: 1.10 $
+* @version$Revision: 1.11 $
* @seeorg.jboss.resource.ConnectionFactoryLoader p
*
* bRevisions:/b p
@@ -74,27 +76,12 @@
// Attributes
- /*
-* log4j Category for logging
-*/
- private Logger category = Logger.create(RARDeployer.class);
/**
-* The directory that will contain local copies of deployed RARs
-*/
- private File rarTmpDir;
-
- /**
* The next sequence number to be used in notifications about (un)deployment
*/
private int nextMessageNum = 0;
- private static String generateUniqueDirName(URL u)
- {
- int thisNum = nextNum++;
- return rar. + thisNum;
- }
-
// Static
// Constructors --
@@ -160,121 +147,36 @@
return null;
}
- /**
-* #Description of the Method
-*
-* @exception Exception Description of Exception
-*/
- public void initService()
- throws Exception
- {
- // find the temp directory - referenced to jboss.system.home property
- File jbossHomeDir = new File(System.getProperty(jboss.system.home));
- File tmpDir = new File(jbossHomeDir, tmp+File.separator);
-
- // Create our temp directory
- File deployTmpDir = new File(tmpDir, deploy);
- rarTmpDir = new File(deployTmpDir, getName());
- if (rarTmpDir.exists())
- {
- category.info(Found a temp directory left over from a previous run - +
- deleting it.);
- // What could it mean?
- if (!recursiveDelete(rarTmpDir))
- {
-category.warn(Unable to recursively delete temp directory ' +
- rarTmpDir + ' that appears to be left over from +
- the previous run. This might cause problems.);
- }
- }
- if (!rarTmpDir.exists() !rarTmpDir.mkdirs())
- {
- throw new DeploymentException(Can't create temp directory ' +
- rarTmpDir + ');
- }
- }
-
- /**
-* #Description of the Method
-*/
- public void destroyService()
- {
- // Remove our temp directory
- if (!recursiveDelete(rarTmpDir))
- {
- category.warn(Unable to recursively delete the temp directory ' +
- rarTmpDir + ' - it should be cleaned up when the +
- server is next restarted.);
- }
- }
-
- protected Object deploy(URL url)
+/**
+ * The codedeploy/code method deploys a rar at the given url.
+ *
+ * @param url The codeURL/code location of the rar to deploy.
+ * @return an codeObject/code to identify this deployment.
+ * @exception IOException if an error occurs
+ * @exception DeploymentException if an error occurs
+ */
+protected Object deploy(URL url)
throws IOException, DeploymentException
{
category.info(Attempting to deploy RAR at ' + url + ');
-
- // We want to take a local copy of the RAR so that we don't run
- // into problems if the original is removed/replaced. We also
- // need the RAR in
[JBoss-dev] CVS update: build/jboss build.xml
User: d_jencks
Date: 01/09/26 14:47:03
Modified:jbossbuild.xml
Log:
ServiceDeployer: added local dir support, undeploy support for depends, reworked
classpath dependencies. Changed config files to work. REMOVE core-service.xml or
build.sh cleancvs update -d -P update11.log
Revision ChangesPath
1.30 +22 -14build/jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/build/jboss/build.xml,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- build.xml 2001/09/16 18:04:29 1.29
+++ build.xml 2001/09/26 21:47:02 1.30
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.29 2001/09/16 18:04:29 jules_gosnell Exp $ --
+!-- $Id: build.xml,v 1.30 2001/09/26 21:47:02 d_jencks Exp $ --
project default=main name=JBoss/Build
@@ -659,19 +659,20 @@
/fileset
/copy
-!-- Copy the core service xml snippet (deploy) --
+!-- No way, ray. in jboss-service.xml that gets deployed first.
+ Copy the core service xml snippet (deploy) - -
copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/etc/conf/default
include name=core-service.xml/
/fileset
-/copy
+/copy--
-!-- Copy the jetty service xml snippet (deploy) --
+!-- Copy the jetty service xml snippet (deploy) - -
copy todir=${install.deploy} filtering=no
fileset dir=${_module.output}/etc/conf/default
include name=jetty-service.xml/
/fileset
-/copy
+/copy--
!-- Copy the jms service xml snippet (deploy) --
copy todir=${install.deploy} filtering=no
@@ -701,24 +702,24 @@
/fileset
/copy
-!-- Copy the jmx-ejb-connector-server.jsr (deploy/lib) --
+!-- Copy the jmx-ejb-connector-server.sar (deploy/lib) --
copy todir=${install.deploy.lib} filtering=no
fileset dir=${_module.output}/lib
- include name=jmx-ejb-connector-server.jsr/
+ include name=jmx-ejb-connector-server.sar/
/fileset
/copy
-!-- Copy the jmx-html-adaptor.jsr (deploy/lib) --
+!-- Copy the jmx-html-adaptor.sar (deploy/lib) --
copy todir=${install.deploy.lib} filtering=no
fileset dir=${_module.output}/lib
- include name=jmx-html-adaptor.jsr/
+ include name=jmx-html-adaptor.sar/
/fileset
/copy
-!-- Copy the jmx-rmi-connector-server.jsr (deploy/lib) --
+!-- Copy the jmx-rmi-connector-server.sar (deploy/lib) --
copy todir=${install.deploy.lib} filtering=no
fileset dir=${_module.output}/lib
- include name=jmx-rmi-connector-server.jsr/
+ include name=jmx-rmi-connector-server.sar/
/fileset
/copy
@@ -889,7 +890,6 @@
mkdir dir=${install.lib.ext}/
copy todir=${install.lib.ext} filtering=no
fileset dir=${_module.output}/lib
- include name=jbosscx.sar/
include name=RARDeployer.jar/
/fileset
/copy
@@ -898,6 +898,7 @@
mkdir dir=${install.deploy.lib}/
copy todir=${install.deploy.lib} filtering=no
fileset dir=${_module.output}/lib
+ include name=jbosscx.sar/
include name=*.rar/
!--include name=*.sar/--!--autodeploy interferes with jbossmq--
/fileset
@@ -1161,13 +1162,20 @@
property name=_module.output override=true
value=${project.root}/${_module.name}/output/
-!-- Copy the generated libraries (lib/ext) --
+!-- Copy the jetty-plugin.sar (deploy) --
+copy todir=${install.deploy}/lib filtering=no
+ fileset dir=${_module.output}/lib
+ include name=jetty-plugin.sar/
+ /fileset
+/copy
+
+!-- Copy the generated libraries (lib/ext)- now jetty-plugin.sar already
copied - -
mkdir dir=${install.lib.ext}/
copy todir=${install.lib.ext} filtering=no
fileset dir=${_module.output}/lib
include name=**/*/
/fileset
-/copy
+/copy--
!-- Copy the default configuration files (conf/default) --
mkdir dir=${install.conf.default}/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MDB non-xa cf tx timeout
That shouldn't happen. Just looked into the code I wrote, and it looks like you have found a bug in it: In org.jboss.tm.TxManager line 314, the new timeout in milliseconds is calculated with the expression: timeout = 1000 * seconds; I guess it should have been timeout = 1000L * seconds; to enforce widening _before_ the multiplication. Maybe Integer.MAX_VALUE/1000 is long enough for you until i get around to committing a fix? I notice that Integer.MAX_VALUE was producing a -1 when looking at the JMX console, so I played around a little and ended up using 200 (which is about 24 days). I re-ran my tests with no errors. I am rerunning them now with a 24 hour timeout, to see what happens when these long transactions complete. My guess is nothing, but just to be sure. I can try Integer.MAX_VALUE/1000 and see if that works too. I just need something that is insainly high, since I don't want _any_ tx to timeout on the node where this stuff is running. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-465416 ] ServiceDeployer changes [+ RARDeployer]
Change Notes item #465416, was opened at 2001-09-26 15:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=465416group_id=22866 Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: Nobody/Anonymous (nobody) Summary: ServiceDeployer changes [+ RARDeployer] Initial Comment: IMPORTANT NOTE: do a build.sh clean or remove core-service.xml from deploy/lib after you receive these changes! Changes to ServiceDeployer: Added local directory copy functionality. Include one or more local-directory path=path/ elements in your jboss-service.xml file and the contents of path in your sar will be copied verbatim into the db directory. If the contents are already there they will not be overwritten, and nothing is removed on undeploy. Added undeploy functionality to depends tag. If a package P has a depends tag indicating it requires mbean x, not only will deployment of the package's mbeans wait for x, if x is undeployed (from a package undeployment), the mbeans from P will be undeployed. Separated classpath and mbean functionality from sar deployment. Previously deploying a sar S1 with a sar S2 in the jboss-service.xml classpath element caused recursive deployment of S2, including its mbeans. Now, this scenario will only add S2 to the system classpath: to get the mbeans for S2, you have to explicitly deploy S2. You can do this before or after S2 has been added to the classpath. This change makes the effects of deployment and undeployment considerably easier to predict. Suspension now works like this: if sar S1 has package J1 in its classpath, undeploying J1 will undeploy S1's mbeans, leaving S1's classes in the classpath. Redeploying J1 will redeploy the mbeans from S1. Again, this localizes the effects of redeployment. In addition, the RARDeployer now adds the rar classes to the system classloader rather than a rar-specific classloader. This means you don't need an extra copy of the InteractionSpec etc classes or interfaces in the system classpath in order to use them. The DeployerMBeanSupport now will not undeploy a deployed package if you try to [re]deploy it. You have to undeploy it explicitly, then deploy it again. I plan to modify the autodeployer shortly to explicitly undeploy and deploy when it detects a timestamp change. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=465416group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss test dependencies
Hi, Scott M Stark wrote: Its set at line 76 of org.jboss.test.web.test.WebIntegrationUnitTestCase: webServerAvailable = getServer().isRegistered(deployerName); I think I found it. This was present in revision 1.2 of this file, but it was removed with the commit to revision 1.3. Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss test dependencies
That's an old version -- looks like I broke it on sept 18. Since Jetty is now supposed to be integrated in standard jboss, shouldn't we eliminate the test for a web deployer? Also, I couldn't get the test for a web deployer to work, which is why I took it out... apparently I didn't notice the real reason all the tests then worked! So, I'd like to remove webServerAvailable and all the tests for it. OK? david jencks On 2001.09.26 17:25:59 -0400 Scott M Stark wrote: Its set at line 76 of org.jboss.test.web.test.WebIntegrationUnitTestCase: webServerAvailable = getServer().isRegistered(deployerName); - Original Message - From: Ole Husgaard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 2:02 PM Subject: Re: [JBoss-dev] jboss test dependencies Hi, Scott M Stark wrote: No, the WebIntegrationTestCase doesn't apply unless the server has a web container configured. The test checks for the existence of a web container and set the webServerAvailable accordingly. Strange, when searching the main branch sources, i see this field referenced only within the WebServerIntegrationTestCase, and here it is never modified from its default value. Maybe in some other branch? In the main branch, it looks like Jetty runs fine, and (apart from some tests failing) I have no problems changing this field to true, and changing the field baseURL to the value http://localhost:8080/;. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] when updating jboss/manual
please make sure that you generate the html docs. the website build depends on this working, so when there is a syntax error in the xdocs the site will not update. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs jbossdocs.xml
User: user57 Date: 01/09/26 15:29:00 Modified:src/xdocs jbossdocs.xml Log: o /pubdate - /pubdate Revision ChangesPath 1.9 +2 -2 manual/src/xdocs/jbossdocs.xml Index: jbossdocs.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/jbossdocs.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- jbossdocs.xml 2001/09/26 07:19:17 1.8 +++ jbossdocs.xml 2001/09/26 22:29:00 1.9 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=UTF-8? -!-- $Id: jbossdocs.xml,v 1.8 2001/09/26 07:19:17 gropi Exp $ -- +!-- $Id: jbossdocs.xml,v 1.9 2001/09/26 22:29:00 user57 Exp $ -- !DOCTYPE book SYSTEM file:@oasis.docbook.xml.root@/docbookx.dtd [ !ENTITY preface.xml SYSTEM preface.xml !ENTITY jbossintro.xml SYSTEM jbossintro.xml @@ -52,7 +52,7 @@ year2001/year holderJBoss Organization/holder /copyright - pubdate@TODAY@/pubdate + pubdate@TODAY@/pubdate /bookinfo preface.xml; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] when updating jboss/manual
jason, to be very honest I don't think it is a good idea i mean updating the website and each time going through the xdoc generation is a pain. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Wednesday, September 26, 2001 6:30 PM |To: [EMAIL PROTECTED]; [EMAIL PROTECTED] |Subject: [JBoss-dev] when updating jboss/manual | | |please make sure that you generate the html docs. the website |build depends |on this working, so when there is a syntax error in the xdocs the site will |not update. | |--jason | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite build.xml
User: user57
Date: 01/09/26 15:25:29
Modified:.build.xml
Log:
o copy of dtd's needs to be done from compile-snapshots, or by a target
which depends on it, since it uses the checked out server module to
get these file... which is a bad idea, but at least now this project
will build again.
Revision ChangesPath
1.13 +16 -10newsite/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/newsite/build.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- build.xml 2001/09/26 20:16:36 1.12
+++ build.xml 2001/09/26 22:25:29 1.13
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.12 2001/09/26 20:16:36 starksm Exp $ --
+!-- $Id: build.xml,v 1.13 2001/09/26 22:25:29 user57 Exp $ --
project default=main name=JBoss/Website
@@ -264,8 +264,13 @@
| different type of compile that needs to be performed, short of
| documentation compiles.
--
- target name=compile depends=init, compile-docs, compile-metadata,
compile-bin, compile-snapshots
- description=Compile all source files./
+ target name=compile
+ description=Compile all source files.
+ depends=init,
+compile-docs,
+ compile-metadata,
+ compile-bin,
+ compile-snapshots/
!-- Compile doc sources support files --
target name=compile-docs depends=init
@@ -275,13 +280,6 @@
include name=**/*/
/fileset
/copy
- !-- Make the JBoss DTDs available under j2ee/dtd --
- mkdir dir=${build.docs}/j2ee/dtd/
-copy todir=${build.docs}/j2ee/dtd filtering=no
- fileset
dir=${build.snapshots}/jboss-all/server/src/resources/org/jboss/metadata
- include name=*.dtd/
- /fileset
-/copy
/target
!-- Compile metadata --
@@ -339,6 +337,14 @@
include name=**/*/
/fileset
/zip
+
+!-- Make the JBoss DTDs available under j2ee/dtd --
+mkdir dir=${build.docs}/j2ee/dtd/
+copy todir=${build.docs}/j2ee/dtd filtering=no
+ fileset
dir=${build.snapshots}/jboss-all/server/src/resources/org/jboss/metadata
+ include name=*.dtd/
+ /fileset
+/copy
/target
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MDB non-xa cf tx timeout
Jason Dillon wrote: That shouldn't happen. Just looked into the code I wrote, and it looks like you have found a bug in it: In org.jboss.tm.TxManager line 314, the new timeout in milliseconds is calculated with the expression: timeout = 1000 * seconds; I guess it should have been timeout = 1000L * seconds; to enforce widening _before_ the multiplication. Maybe Integer.MAX_VALUE/1000 is long enough for you until i get around to committing a fix? I notice that Integer.MAX_VALUE was producing a -1 when looking at the JMX console, so I played around a little and ended up using 200 (which is about 24 days). I re-ran my tests with no errors. I am rerunning them now with a 24 hour timeout, to see what happens when these long transactions complete. My guess is nothing, but just to be sure. I can try Integer.MAX_VALUE/1000 and see if that works too. I just need something that is insainly high, since I don't want _any_ tx to timeout on the node where this stuff is running. I just committed the fix to the main and 2.4 branches. Please let me know it it fixes your problem. You should be avare that even though the TM timeout is set extremely high, there may be other timeouts in the transactional resources that could still time out. If a transactional resource times out before the transaction you will end up with a heuristic. So be careful about which resources you use, and if possible raise their timeouts so they will not start making heuristic decisions too soon. Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss and log4j version 1.2
Hello Jason, There is no firm release date for 1.2. It will be released when it is ready. However, 1.2alpha0 is available since yesterday. :-) Is there any compelling reason why we should switch to this alpha? I am all for the new API, but I am very weary of alpha/beta product. Extending the interface of Logger (i.e. Category) with new printing methods such as trace() is considered bad practice, at least by me. I understand that adding printing methods is consistent with the rest of the API, easy on the fingers and eyes. That is not good enough a reason. Log4j can never guarantee that a given category will be of a certain type, say org.jboss.logging.log4j.JBossCategory instead of org.apache.log4j.Logger. ClassCastException when instantiating a Category subclass is one example of this problem. See also http://jakarta.apache.org/log4j/docs/TROUBLESHOOT.html#cce I see your point here, but the suggested usage for implementing trace() is just plain ugly. I would still suggest that we use our own Logger class which has all of the features and niceness which we desire, but uses Log4j as the underlying mechanism. I have been playing with logging systems for several years now, and I am coming to the conclusion that there is no single perfect logging api for application use. I am starting to think that each platform (like JBoss) should provide it's own interface, but leave the details of event management, configuration and the like, to a package like Log4j. I have not looked into the new LogManager and related classes yet, but I am glad to see things moving in this direction. I can totally see that I might want to completly disable logging via a NullLogger for some components, where I might want full thread dumps from others. Having one class handle both of these extremes will slow things down. Anyways, I would suggest that JBoss alter Logger to extend Object and make it a thin proxy to a Log4j logger. This way we don't have to worry about any class cast issues, and we can have a trace(), plus other features. In the future, I expect that Application Servers or Servlet Containers will impose a particular org.apache.log4j.Logger implementation (for security reasons). It will not be up to an embedded component to decide the logger subclass. Thus, you will not be able to rely on a org.jboss.logging.log4j.JBossCategory being returned even if you set the categoryFactory to org.jboss.logging.log4j.JBossCategory$JBossCategoryFactory in the configuration file. As I mentioned before, I would still expect our core components and plugins to use the JBoss Logger.create() methods to get an instance of a Logger. Log4j support in JBoss is particularly important. I suggest that you look into the LogManager, RepositorySelector and LoggerRepository code. See also http://jakarta.apache.org/log4j/docs/manual/manual.html#AEN718 Logging in an application server and the applications which run in it is very, very important. I have been playing with my own Bliss planet57.log api for a while now, but have finally concieded the backed to Log4j, since you do it much better than I could hope to given the time I have to work on it. The whole construction is intended to allow Application Servers to select the appropriate LoggerRepository depending on the embedded application. Let me give an example. Assume we have to applications App-A and App-B running inside JBoss. We want App-A and App-B to live in separate logging universes. We achieve this by having App-A and App-B use different LoggerRepositories (LoggerRepository is the new name for Hierarchies in log4j 1.2). Clients still call Logger.getLogger(name) to retrieve a logger (= category). However, we want to vary the LoggerRepository (~hierarchy) depending on the caller. For a call to Logger.getLogger(name) emanating from code in App-A, we want JBoss to detect that the caller is in App-A and use the LoggerRepository specific to App-A. Similarly, calling Logger.getLogger(name) within App-B should use a LoggerRepository specific to App-B. Sounds very, very interesting. I will have to look into this more. Since JBoss is the top-level application, JBoss is free to impose the RepositorySelector to the LogManager. JBoss' implementation of RepositorySelector can use different methods to track the caller (the particular application), for example by setting a ThreadLocal variable to track applications by Thread. Regarding your last question, the DOMConfigurator offers more services than ProppertyConfigurator and is considered as stable. Don't hesitate to contact me if you encounter problems when migrating to the DOMConfigurator. Thanks, --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss and log4j version 1.2
I see your point here, but the suggested usage for implementing trace() is just plain ugly. I would still suggest that we use our own Logger class which has all of the features and niceness which we desire, but uses Log4j as the underlying mechanism. I have been playing with logging systems for several years now, and I am coming to the conclusion that there is no single perfect logging api for application use. I am starting to think that each platform (like JBoss) should provide it's own interface, but leave the details of event management, configuration and the like, to a package like Log4j. I used to be of the same opinion, but think that when you have logging disabled you want it as fast as possible (AFAIK it involves keeping as little inheritance as possible and so on). Unless you keep programming in the isDebugEnabled() way or implement it again in that thin layer, you'll get a bit slower system (remember that the log is called hundreds of times). You can also wait until the API JSR047 that Sun is developing matures and see what it's like: http://jcp.org/aboutJava/communityprocess/review/jsr047/index.html P.S.: The isDebugEnabled way as far as I remember from memory, involves checking the debugging state before calling the log method, to avoid calculating the parameters when there is no need: if (isDebugEnabled()) log.debug(Parameters = + param1 + , + param2); ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jboss-docs] RE: [JBoss-dev] when updating jboss/manual
to be very honest I don't think it is a good idea i mean updating the website and each time going through the xdoc generation is a pain. Think of it as compling your .java before commiting the changes... or if you prefer, once you commit a whole bit build the docs. I don't suggest running the entire jboss-website build, just make sure changes that are made actually work. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MDB non-xa cf tx timeout
Sorry for the late response. I don't *think* this is an issue currently. There are no other resources involved except the jms bits to pull a msg off from and hand it to the mdb. --jason On Tue, 25 Sep 2001, David Jencks wrote: Jason, I have no idea if this is relevant... I discovered in the ConnectionManager/pool code that the scheduling is kind of awful, and that under high load, if the pool gets emptied and a request has to wait, that request is apt to wait more or less forever, since it is blocking and new requests take any available connections without blocking. (I discovered this by putting a blocking timeout in the pool and running the high stress (10 threads, 1000 iterations) bank test. After a little while I got a few exceptions from blocking timeout.) Is there any chance this is happening to you? A crude fix that might work would be to make every new request block if any request is blocking when the new one comes in: this gives everyone a chance at intercepting the returned notifyAll(). I've been wondering about how or if to implement strict scheduling, and kind of forgot this code is used by jmsra in 2.4. If you think this might be relevant and want me to suggest a more specific fix let me know. Thanks david jencks On 2001.09.25 16:31:44 -0400 Jason Dillon wrote: I ran some tests last night with the TransactionManager.TransactionTimeout set to Integer.MAX_VALUE, and I am still getting these messages: org.jboss.tm.TxCapsule [Thread-5] () - Transaction XidImpl [FormatId=257, GlobalId=eng-ecr5a//0, BranchQual=] timed out. status=STATUS_ACTIVE This is still off of a pre-3.0 release... I have been resistent to moving to 3.0 due to the months of work that I had to do (and the stress to stabilize the system) to make everything work with the jms ra, entity locking and so on. I guess I should probably look into this a little bit more though, since it is going to be very difficult to track down this problem on an old build... =( --jason On Mon, 24 Sep 2001, Hiram Chirino wrote: The problem is that I want to basicly use a local TX with a MQ XAConnection. If knew how to generate vaid XIDs to feed the XAResource, then we could emulate the TM. But I'm not 100% on how to generate XIDs, so hacked a JBossMQ specific solution. Anybody know how to generate valid XIDs??? At least valid enough to control a 1 phase commit resource??? Regards, Hiram From: Jason Dillon [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] MDB non-xa cf tx timeout Date: Mon, 24 Sep 2001 18:17:23 -0700 (PDT) Why does StdServerSession hard code JBossMQ specifics (JBossMQTXInterface the related classnames and such)? --jason On Mon, 24 Sep 2001, Hiram Chirino wrote: No, Not yet... I guess I should also do the same for CMT that has NotSupported right??? Regards, Hiram From: Jason Dillon [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] MDB non-xa cf tx timeout Date: Sun, 23 Sep 2001 20:06:12 -0700 (PDT) Hey, sorry for the late reply. What about CMT? Shouldn't CMT behave the same in this case? The system I run this under uses the old style config. Is this change relavent for integration with 2.4.x? I think I might switch over to that for production use... head is changing to quickly. --jason On Thu, 20 Sep 2001, Hiram Chirino wrote: Hi Jason, Anyways, I think there is still an issue with the tx recipts for an MDB. I have to set the default tx timeout insainly high to avoid this problem. I remember there were a few suggestions on how to fix this, but I am not sure what happend to them... I just commited chanages to HEAD that should fix this for MDB with BMT. Pease test and let me know if it worked. Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development
Re: [JBoss-dev] jboss test dependencies
Ok, fine. - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 3:29 PM Subject: Re: [JBoss-dev] jboss test dependencies That's an old version -- looks like I broke it on sept 18. Since Jetty is now supposed to be integrated in standard jboss, shouldn't we eliminate the test for a web deployer? Also, I couldn't get the test for a web deployer to work, which is why I took it out... apparently I didn't notice the real reason all the tests then worked! So, I'd like to remove webServerAvailable and all the tests for it. OK? david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/web/test WebIntegrationUnitTestCase.java
User: d_jencks
Date: 01/09/26 17:18:48
Modified:src/main/org/jboss/test/web/test
WebIntegrationUnitTestCase.java
Log:
Turned web tests back on -- oops. Also used logging
Revision ChangesPath
1.5 +6 -37
jbosstest/src/main/org/jboss/test/web/test/WebIntegrationUnitTestCase.java
Index: WebIntegrationUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/web/test/WebIntegrationUnitTestCase.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- WebIntegrationUnitTestCase.java 2001/09/25 18:07:19 1.4
+++ WebIntegrationUnitTestCase.java 2001/09/27 00:18:48 1.5
@@ -34,13 +34,12 @@
with a role of 'AuthorizedUser' in the servlet container.
@author [EMAIL PROTECTED]
- @version $Revision: 1.4 $
+ @version $Revision: 1.5 $
*/
public class WebIntegrationUnitTestCase extends JBossTestCase
{
- private static boolean setUp;
- private static boolean webServerAvailable;
- private static String baseURL;
+
+ private String baseURL = http://jduke:theduke@localhost:; +
Integer.getInteger(web.port, 8080) + /;
public WebIntegrationUnitTestCase(String name)
{
@@ -52,9 +51,6 @@
*/
public void testEJBOnStartupServlet() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/EJBOnStartupServlet);
accessURL(url);
}
@@ -62,9 +58,6 @@
*/
public void testENCServlet() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/ENCServlet);
accessURL(url);
}
@@ -72,9 +65,6 @@
*/
public void testEJBServlet() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/EJBServlet);
accessURL(url);
}
@@ -82,9 +72,6 @@
*/
public void testUserTransactionServlet() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/UserTransactionServlet);
accessURL(url);
}
@@ -92,9 +79,6 @@
*/
public void testSnoopJSP() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/snoop.jsp);
accessURL(url);
}
@@ -102,9 +86,6 @@
*/
public void testClientLoginServlet() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/ClientLoginServlet);
accessURL(url);
}
@@ -112,9 +93,6 @@
*/
public void testSecureServlet() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/restricted/SecureServlet);
accessURL(url);
}
@@ -122,9 +100,6 @@
*/
public void testSecureEJBAccess() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/restricted/SecureEJBAccess);
accessURL(url);
}
@@ -132,9 +107,6 @@
*/
public void testIncludeEJB() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/restricted/include_ejb.jsp);
accessURL(url);
}
@@ -142,9 +114,6 @@
*/
public void testUnsecureEJBAccess() throws Exception
{
- if( webServerAvailable == false )
- return;
-
URL url = new URL(baseURL+jbosstest/UnsecureEJBAccess);
accessURL(url, true);
}
@@ -157,15 +126,15 @@
{
try
{
- System.out.println(Connecting to: +url);
+ getLog().debug(Connecting to: +url);
HttpClient httpConn = new HttpClient(url);
int responseCode = httpConn.getResponseCode();
String response = httpConn.getResponseMessage();
- System.out.println(responseCode=+responseCode+, response=+response);
+ getLog().debug(responseCode=+responseCode+, response=+response);
if( responseCode != HttpURLConnection.HTTP_OK )
{
StringBuffer content = httpConn.getContent();
-System.out.println(content);
+getLog().debug(content);
if( shouldFail == false )
fail(Access to: +url+ failed with responseCode=+responseCode);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
[JBoss-dev] jboss/testsuite build failure
snip truncated=true _jars-jmx: [jar] Building jar: /nfs/home/jason/ws/jboss/jboss-all/testsuite/output/lib/jmxtest.jar [jar] Building jar: /nfs/home/jason/ws/jboss/jboss-all/testsuite/output/lib/testdeploy.sar [jar] Building jar: /nfs/home/jason/ws/jboss/jboss-all/testsuite/output/lib/testdeploya.sar [jar] Building jar: /nfs/home/jason/ws/jboss/jboss-all/testsuite/output/lib/testdeployb.sar [jar] Building jar: /nfs/home/jason/ws/jboss/jboss-all/testsuite/output/lib/testdeployc.sar [jar] Building jar: /nfs/home/jason/ws/jboss/jboss-all/testsuite/output/lib/testdeployd.sar BUILD FAILED /nfs/home/jason/ws/jboss/jboss-all/testsuite/build.xml:912: /nfs/home/jason/ws/jboss/jboss-all/testsuite/output/resources/jmx/mbeane not found. snip/ Is there supposed to be a src/resources/jmx/mbeane directory? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jcert.jar jnet.jar jsse.jar
User: starksm Date: 01/09/26 18:03:00 Added: src/lib Tag: Branch_2_4 jcert.jar jnet.jar jsse.jar Log: Add the JSSE 1.0.2 global jars Revision ChangesPath No revision No revision 1.2.2.1 +0 -0 jboss/src/lib/Attic/jcert.jar Binary file 1.2.2.1 +0 -0 jboss/src/lib/Attic/jnet.jar Binary file 1.2.2.1 +0 -0 jboss/src/lib/Attic/jsse.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/build build.xml
User: starksm
Date: 01/09/26 18:07:05
Modified:catalina/src/build build.xml
Log:
Update build for new catalina-service.jar
Revision ChangesPath
1.3 +171 -32 contrib/catalina/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/catalina/src/build/build.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.xml 2001/09/14 12:45:00 1.2
+++ build.xml 2001/09/27 01:07:05 1.3
@@ -1,51 +1,190 @@
-project name=Catalina default=tomcatservice basedir=../
- target name=init
-tstamp/
-property name=build.compiler value=classic/
-property name=debug value=on/
-property name=optimize value=on/
-property name=deprecation value=on/
+?xml version=1.0 encoding=UTF-8 ?
+!-- $Id: build.xml,v 1.3 2001/09/27 01:07:05 starksm Exp $ --
-property name=src.dir value=${basedir}/main/
+!-- An Ant build file for the catalina-service jar and the
+JBoss/Tomcat bundle. The buildfile requires a JBoss dist
+be specified via the jboss.dist property as well as a
+catalina dist be specified via the catalina.dist property.
+--
+
+project name=catalina-service default=jar basedir=../..
+
+!-- Default values for jboss.dist catalina.dist that should be overriden --
+property name=jboss.dist value=${basedir}/../../jboss/dist/
+property name=catalina.dist value=${basedir}/jakarta-tomcat-4.0/
+
+property name=name value=catalina-service/
property name=lib.dir value=${basedir}/lib/
-property name=build.dir value=${basedir}/../build/
+property name=src.dir value=${basedir}/src/main/
+property name=src.resources value=${basedir}/src/resources/
+property name=etc.dir value=${basedir}/src/etc/
+property name=build.dir value=${basedir}/build/
property name=build.classes.dir value=${build.dir}/classes/
-property name=dist.dir value=${basedir}/../dist/
-
-property file=${basedir}/build/build.properties/
-
-property name=classpath
value=${tomcat.home}/bin/bootstrap.jar;${tomcat.home}/server/lib/catalina.jar;${tomcat.home}/server/lib/crimson.jar;${tomcat.home}/server/lib/jaxp.jar;${jboss.home}/lib/ext/jboss.jar;${jboss.home}/lib/jmxri.jar;${jboss.home}/lib/ext/log4j.jar;${tomcat.home}/common/lib/servlet.jar/
-echo message=${classpath}/
+property name=jar.file value=${name}.jar/
+property name=test.client value=tomcat-test/
+property name=bundle.name value=JBoss-2.4.1_Tomcat-4.0 /
+property name=bundle.dir value=bundle /
+property name=bundle.root value=${bundle.dir}/${bundle.name} /
+path id=base.path_24
+pathelement location=${jboss.dist}/client/jaas.jar/
+pathelement location=${jboss.dist}/client/jbosssx-client.jar/
+pathelement location=${jboss.dist}/client/jnp-client.jar/
+pathelement location=${jboss.dist}/client/jta-spec1_0_1.jar/
+pathelement location=${jboss.dist}/lib/jdbc2_0-stdext.jar/
+pathelement location=${jboss.dist}/lib/jaxp.jar/
+pathelement location=${jboss.dist}/lib/crimson.jar/
+pathelement location=${jboss.dist}/lib/jmxri.jar/
+pathelement location=${jboss.dist}/lib/jboss-jaas.jar/
+pathelement location=${jboss.dist}/lib/ext/jboss-j2ee.jar/
+pathelement location=${jboss.dist}/lib/ext/jboss.jar/
+pathelement location=${jboss.dist}/lib/ext/jbosssx.jar/
+pathelement location=${jboss.dist}/lib/ext/log4j.jar/
+pathelement location=${catalina.dist}/server/lib/catalina.jar/
+pathelement location=${catalina.dist}/common/lib/servlet.jar/
+pathelement location=${build.classes.dir}/
+/path
+
+
+target name=init
+available property=classpath_id value=base.path_24
file=${jboss.dist}/client/jboss-j2ee.jar /
+property name=classpath refid=${classpath_id} /
+echo message=Using jboss.dist=${jboss.dist} /
+echo message=Using catalina.dist=${catalina.dist} /
+echo message=Using classpath=${classpath} /
+/target
+
+
+!-- === --
+!-- Prepares the build directory--
+!-- === --
+target name=prepare depends=init
+mkdir dir=${build.dir}/
+/target
+
+
+!-- === --
+!-- Compiles the source code--
+!-- === --
+target name=compile depends=prepare
+mkdir dir=${build.classes.dir}/
+javac srcdir=${src.dir}
+
[JBoss-dev] CVS update: thirdparty/gnu/getopt - Imported sources
User: user57 Date: 01/09/26 18:10:51 Log: o import of GNU getopt 1.0.8 Status: Vendor Tag: gnu Release Tags: getopt_1_0_8 N thirdparty/gnu/getopt/lib/getopt.jar No conflicts created by this import ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss.conf
User: starksm Date: 01/09/26 18:20:19 Modified:src/etc/conf/default Tag: Branch_2_4 jboss.conf Log: Remove the commentted out entries Revision ChangesPath No revision No revision 1.19.4.1 +1 -15 jboss/src/etc/conf/default/Attic/jboss.conf Index: jboss.conf === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/Attic/jboss.conf,v retrieving revision 1.19 retrieving revision 1.19.4.1 diff -u -r1.19 -r1.19.4.1 --- jboss.conf2001/04/25 20:45:41 1.19 +++ jboss.conf2001/09/27 01:20:19 1.19.4.1 @@ -32,21 +32,7 @@ /MLET -!-- Uncomment to add Tomcat classes to classpath - -- MLET CODE = org.jboss.util.ClassPathExtension ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ - -- ARG TYPE=java.lang.String VALUE=path to tomcat /lib goes here - -- ARG TYPE=java.lang.String VALUE=Tomcat - -- /MLET - -- - -!-- Uncomment to add Jetty classes to classpath (make sure Arg1 ends in a slash) - -- MLET CODE = org.jboss.util.ClassPathExtension ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ - -- ARG TYPE=java.lang.String VALUE=path to Jetty/lib/ e.g. /usr/local/Jetty3/lib/ - -- ARG TYPE=java.lang.String VALUE=Jetty - -- /MLET - -- - -MLET CODE = org.jboss.configuration.ConfigurationService ARCHIVE=jboss.jar,../xml.jar CODEBASE=../../lib/ext/ +MLET CODE = org.jboss.configuration.ConfigurationService ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ /MLET MLET CODE = org.jboss.util.Shutdown ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss.jcml
User: starksm Date: 01/09/26 18:28:08 Modified:src/etc/conf/default Tag: Branch_2_4 jboss.jcml Log: Remove undocumented sercurity mbeans Revision ChangesPath No revision No revision 1.40.2.7 +0 -21 jboss/src/etc/conf/default/Attic/jboss.jcml Index: jboss.jcml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/Attic/jboss.jcml,v retrieving revision 1.40.2.6 retrieving revision 1.40.2.7 diff -u -r1.40.2.6 -r1.40.2.7 --- jboss.jcml2001/09/26 06:08:31 1.40.2.6 +++ jboss.jcml2001/09/27 01:28:08 1.40.2.7 @@ -53,32 +53,11 @@ !-- Security -- !-- -- - !-- Uncomment to enable the sample SRPVerifierStore service - mbean code=org.jboss.security.srp.SRPVerifierStoreService name=Security:name=SRPVerifierStoreService -attribute name=JndiNameSRPDefaultVerifierSource/attribute -attribute name=StoreFileSRPVerifierStore.ser/attribute - /mbean --- - !-- Uncomment to enable the SRP login service - mbean code=org.jboss.security.srp.SRPService name=service:name=SRPService -attribute name=JndiNameSRPServerInterface/attribute -attribute name=VerifierSourceJndiNameSRPDefaultVerifierSource/attribute -attribute name=AuthenticationCacheJndiNameSRPAuthenticationCache/attribute -attribute name=ServerPort10099/attribute - /mbean --- - !-- JAAS security manager and realm mapping -- mbean code=org.jboss.security.plugins.JaasSecurityManagerService name=Security:name=JaasSecurityManager attribute name=SecurityManagerClassNameorg.jboss.security.plugins.JaasSecurityManager/attribute /mbean - !-- Uncomment to enable the XML implementation of the JAAS policy - mbean code=org.jboss.security.plugins.SecurityPolicyService name=Security:name=SecurityPolicyService -attribute name=JndiNameDefaultSecurityPolicy/attribute -attribute name=PolicyFilesample_policy.xml/attribute - /mbean --- !-- -- !-- JDBC -- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/etc/conf - New directory
User: starksm Date: 01/09/26 18:35:25 contrib/catalina/src/etc/conf - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/etc - New directory
User: starksm Date: 01/09/26 18:35:17 contrib/catalina/src/etc - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/etc/conf/catalina jboss.conf.patch jboss.jcml.patch
User: starksm Date: 01/09/26 18:36:25 Added: catalina/src/etc/conf/catalina jboss.conf.patch jboss.jcml.patch Log: Add patch files for creating the embedded catalina jboss.conf and jboss.jcml Revision ChangesPath 1.1 contrib/catalina/src/etc/conf/catalina/jboss.conf.patch Index: jboss.conf.patch === *** jboss.confWed Sep 26 18:24:36 2001 --- jboss.conf.catalina Wed Sep 26 18:25:13 2001 *** *** 32,38 /MLET ! MLET CODE = org.jboss.configuration.ConfigurationService ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ /MLET MLET CODE = org.jboss.util.Shutdown ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ --- 32,56 /MLET ! !-- Uncomment to add Tomcat classes to classpath -- ! MLET CODE = org.jboss.util.ClassPathExtension ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ ! ARG TYPE=java.lang.String VALUE=../../../catalina/common/lib/ ! ARG TYPE=java.lang.String VALUE=CatalinaCommon ! /MLET ! MLET CODE = org.jboss.util.ClassPathExtension ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ ! ARG TYPE=java.lang.String VALUE=../../../catalina/server/lib/ ! ARG TYPE=java.lang.String VALUE=CatalinaServer ! /MLET ! MLET CODE = org.jboss.util.ClassPathExtension ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ ! ARG TYPE=java.lang.String VALUE=../../../catalina/bin/ ! ARG TYPE=java.lang.String VALUE=CatalinaBin ! /MLET ! MLET CODE = org.jboss.util.ClassPathExtension ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ ! ARG TYPE=java.lang.String VALUE=../../../catalina/lib/ ! ARG TYPE=java.lang.String VALUE=CatalinaLib ! /MLET ! ! MLET CODE = org.jboss.configuration.ConfigurationService ARCHIVE=jboss.jar,../xml.jar CODEBASE=../../lib/ext/ /MLET MLET CODE = org.jboss.util.Shutdown ARCHIVE=jboss.jar CODEBASE=../../lib/ext/ 1.1 contrib/catalina/src/etc/conf/catalina/jboss.jcml.patch Index: jboss.jcml.patch === 60a61,68 mbean code=org.jboss.security.plugins.JaasSecurityDomain name=Security:securityDomain=other constructor arg type=java.lang.String value=other / /constructor attribute name=KeyStoreFile.keystore/attribute attribute name=KeyStoreTypeJKS/attribute attribute name=KeyStorePasschangeit/attribute /mbean 117,119c125,127 !-- Uncomment to add embedded tomcat service mbean code=org.jboss.tomcat.EmbeddedTomcatServiceSX name=DefaultDomain:service=EmbeddedTomcat / -- --- !-- Uncomment to add embedded tomcat service -- mbean code=org.jboss.web.catalina.EmbeddedCatalinaServiceSX name=DefaultDomain:service=EmbeddedCatalina /mbean 205c213 !-- Make sure you change EmbeddedTomcat to Jetty if you are using Jetty -- --- !-- Make sure you change EmbeddedCatalina to Jetty if you are using Jetty -- 209c217 attribute name=WarDeployerName:service=EmbeddedTomcat/attribute --- attribute name=WarDeployerName:service=EmbeddedCatalina/attribute ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/etc/conf/catalina - New directory
User: starksm Date: 01/09/26 18:35:32 contrib/catalina/src/etc/conf/catalina - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily build failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE _jars-cts: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/ctstest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/cts.jar _jars-hello: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/hellotest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/hello.jar _jars-idgen: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/idgentest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/idgen.jar _jars-dbtest: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/dbtestclient.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/dbtest.jar _jars-jmsra: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/jmsratest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/jmsra.jar _jars-mdb: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/mdbtest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/mdb.jar _jars-lock: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/locktestclient.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/locktest.jar _jars-readahead: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/readaheadtest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/readahead.jar _jars-xa: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/xatestclient.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/xatest.jar _jars-jmx: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/jmxtest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeploy.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeploya.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeployb.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeployc.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeployd.sar BUILD FAILED /home/lubega/jbossro/jboss-all/testsuite/build.xml:912: /home/lubega/jbossro/jboss-all/testsuite/output/resources/jmx/mbeane not found. Total time: 5 minutes 50 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE os.arch: x86 os.version: 2.4.3-12 jbosstest.iterationcount: 1000 jbosstest.threadcount: 10 jbosstest.beancount: 100 compile-classes: compile-etc: compile-stylesheets: compile-resources: compile-bin: compile: _jars-bank: _jars-bmp: _jars-cts: _jars-hello: _jars-idgen: _jars-dbtest: _jars-jmsra: _jars-mdb: _jars-lock: _jars-readahead: _jars-xa: _jars-jmx: BUILD FAILED /home/lubega/jbossro/jboss-all/testsuite/build.xml:912: /home/lubega/jbossro/jboss-all/testsuite/output/resources/jmx/mbeane not found. Total time: 7 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/build build.xml
User: starksm
Date: 01/09/26 18:55:45
Modified:catalina/src/build build.xml
Log:
Update the bundle version
Revision ChangesPath
1.4 +5 -39 contrib/catalina/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/catalina/src/build/build.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- build.xml 2001/09/27 01:07:05 1.3
+++ build.xml 2001/09/27 01:55:45 1.4
@@ -1,5 +1,5 @@
?xml version=1.0 encoding=UTF-8 ?
-!-- $Id: build.xml,v 1.3 2001/09/27 01:07:05 starksm Exp $ --
+!-- $Id: build.xml,v 1.4 2001/09/27 01:55:45 starksm Exp $ --
!-- An Ant build file for the catalina-service jar and the
JBoss/Tomcat bundle. The buildfile requires a JBoss dist
@@ -21,8 +21,7 @@
property name=build.dir value=${basedir}/build/
property name=build.classes.dir value=${build.dir}/classes/
property name=jar.file value=${name}.jar/
-property name=test.client value=tomcat-test/
-property name=bundle.name value=JBoss-2.4.1_Tomcat-4.0 /
+property name=bundle.name value=JBoss-2.4.2_Tomcat-4.0 /
property name=bundle.dir value=bundle /
property name=bundle.root value=${bundle.dir}/${bundle.name} /
path id=base.path_24
@@ -38,6 +37,7 @@
pathelement location=${jboss.dist}/lib/ext/jboss-j2ee.jar/
pathelement location=${jboss.dist}/lib/ext/jboss.jar/
pathelement location=${jboss.dist}/lib/ext/jbosssx.jar/
+pathelement location=${jboss.dist}/lib/ext/jnet.jar/
pathelement location=${jboss.dist}/lib/ext/log4j.jar/
pathelement location=${catalina.dist}/server/lib/catalina.jar/
pathelement location=${catalina.dist}/common/lib/servlet.jar/
@@ -105,7 +105,7 @@
!-- Creates a jboss-catalina bundle using the jboss.dist and catalina.dist
contents and ${etc.dir}/conf/catalina patch files --
!-- === --
- target name=bundle depends=jar,client
+ target name=bundle depends=jar
mkdir dir=${bundle.root} /
copy todir=${bundle.root}/catalina
fileset dir=${catalina.dist} /
@@ -135,49 +135,15 @@
chmod dir=${bundle.root}/jboss/bin perm=ugo+rx includes=*.sh /
fixcrlf srcdir=${bundle.root}/jboss/bin cr=add eof=remove
includes=*.bat /
-copy file=${build.dir}/${test.client}.ear
- tofile=${bundle.root}/jboss/deploy/${test.client}.ear /
/target
target name=bundle.zip depends=bundle
zip zipfile=${bundle.name}.zip basedir=${bundle.dir} /
/target
- target name=bundle.tgz depends=bundle,client
+ target name=bundle.tgz depends=bundle
tar tarfile=${bundle.name}.tar basedir=${bundle.dir} /
gzip src=${bundle.name}.tar zipfile=${bundle.name}.tgz /
- /target
-
- !-- === --
- !-- Creates the test client ear file--
- !-- === --
- target name=client depends=compile
- copy todir=${build.classes.dir}
- fileset dir=${src.resources}/test /
- /copy
- jar jarfile=${build.classes.dir}/${test.client}.jar
- basedir=${build.classes.dir}
-
includes=org/jboss/test/tomcat/ejb/**,META-INF/ejb-jar.xml,META-INF/jboss.xml
- /
- copy
todir=${build.classes.dir}/WEB-INF/classes/org/jboss/test/tomcat/servlet
- fileset dir=${build.classes.dir}/org/jboss/test/tomcat/servlet /
- /copy
- !-- copy
todir=${build.classes.dir}/WEB-INF/classes/org/jboss/test/tomcat/ejb/interfaces
- fileset dir=${build.classes.dir}/org/jboss/test/tomcat/ejb/interfaces /
- /copy --
- jar jarfile=${build.classes.dir}/${test.client}.war
- basedir=${build.classes.dir}
- manifest=${src.resources}/web.mf
- includes=WEB-INF/**,index.html
- /
- jar jarfile=${build.classes.dir}/client.jar
- basedir=${build.classes.dir}
- includes=org/jboss/test/tomcat/ejb/interfaces/**
- /
- jar jarfile=${build.dir}/${test.client}.ear
- basedir=${build.classes.dir}
-
includes=${test.client}.jar,${test.client}.war,client.jar,META-INF/application.xml
- /
/target
!-- === --
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/etc/conf/catalina jboss.jcml.patch
User: starksm Date: 01/09/26 18:56:23 Modified:catalina/src/etc/conf/catalina jboss.jcml.patch Log: Remove the other SecurityDomain configuration Revision ChangesPath 1.2 +0 -9 contrib/catalina/src/etc/conf/catalina/jboss.jcml.patch Index: jboss.jcml.patch === RCS file: /cvsroot/jboss/contrib/catalina/src/etc/conf/catalina/jboss.jcml.patch,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jboss.jcml.patch 2001/09/27 01:36:25 1.1 +++ jboss.jcml.patch 2001/09/27 01:56:23 1.2 @@ -1,12 +1,3 @@ -60a61,68 - mbean code=org.jboss.security.plugins.JaasSecurityDomain name=Security:securityDomain=other - constructor -arg type=java.lang.String value=other / - /constructor - attribute name=KeyStoreFile.keystore/attribute - attribute name=KeyStoreTypeJKS/attribute - attribute name=KeyStorePasschangeit/attribute - /mbean 117,119c125,127 !-- Uncomment to add embedded tomcat service mbean code=org.jboss.tomcat.EmbeddedTomcatServiceSX name=DefaultDomain:service=EmbeddedTomcat / ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily build failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE _jars-cts: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/ctstest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/cts.jar _jars-hello: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/hellotest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/hello.jar _jars-idgen: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/idgentest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/idgen.jar _jars-dbtest: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/dbtestclient.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/dbtest.jar _jars-jmsra: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/jmsratest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/jmsra.jar _jars-mdb: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/mdbtest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/mdb.jar _jars-lock: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/locktestclient.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/locktest.jar _jars-readahead: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/readaheadtest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/readahead.jar _jars-xa: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/xatestclient.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/xatest.jar _jars-jmx: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/jmxtest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeploy.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeploya.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeployb.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeployc.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeployd.sar BUILD FAILED /home/lubega/jbossro/jboss-all/testsuite/build.xml:912: /home/lubega/jbossro/jboss-all/testsuite/output/resources/jmx/mbeane not found. Total time: 3 minutes 48 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE os.arch: i386 os.version: 2.4.3-12 jbosstest.iterationcount: 1000 jbosstest.threadcount: 10 jbosstest.beancount: 100 compile-classes: compile-etc: compile-stylesheets: compile-resources: compile-bin: compile: _jars-bank: _jars-bmp: _jars-cts: _jars-hello: _jars-idgen: _jars-dbtest: _jars-jmsra: _jars-mdb: _jars-lock: _jars-readahead: _jars-xa: _jars-jmx: BUILD FAILED /home/lubega/jbossro/jboss-all/testsuite/build.xml:912: /home/lubega/jbossro/jboss-all/testsuite/output/resources/jmx/mbeane not found. Total time: 6 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily build failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE _jars-cts: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/ctstest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/cts.jar _jars-hello: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/hellotest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/hello.jar _jars-idgen: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/idgentest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/idgen.jar _jars-dbtest: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/dbtestclient.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/dbtest.jar _jars-jmsra: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/jmsratest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/jmsra.jar _jars-mdb: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/mdbtest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/mdb.jar _jars-lock: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/locktestclient.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/locktest.jar _jars-readahead: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/readaheadtest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/readahead.jar _jars-xa: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/xatestclient.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/xatest.jar _jars-jmx: [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/jmxtest.jar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeploy.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeploya.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeployb.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeployc.sar [jar] Building jar: /home/lubega/jbossro/jboss-all/testsuite/output/lib/testdeployd.sar BUILD FAILED /home/lubega/jbossro/jboss-all/testsuite/build.xml:912: /home/lubega/jbossro/jboss-all/testsuite/output/resources/jmx/mbeane not found. Total time: 9 minutes 16 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE os.arch: i386 os.version: 2.4.3-12 jbosstest.iterationcount: 1000 jbosstest.threadcount: 10 jbosstest.beancount: 100 compile-classes: compile-etc: compile-stylesheets: compile-resources: compile-bin: compile: _jars-bank: _jars-bmp: _jars-cts: _jars-hello: _jars-idgen: _jars-dbtest: _jars-jmsra: _jars-mdb: _jars-lock: _jars-readahead: _jars-xa: _jars-jmx: BUILD FAILED /home/lubega/jbossro/jboss-all/testsuite/build.xml:912: /home/lubega/jbossro/jboss-all/testsuite/output/resources/jmx/mbeane not found. Total time: 17 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
