cvs commit: jakarta-tomcat-catalina/webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp valves.jsp
billbarker2004/10/17 23:37:57 Modified:webapps/admin/WEB-INF struts-config.xml webapps/admin/WEB-INF/classes/org/apache/webapp/admin CommitChangesAction.java DumpRegistryAction.java DumpServerAction.java LogOutAction.java SetLocaleAction.java SetUpTreeAction.java TomcatTreeBuilder.java TreeControlTag.java TreeControlTestAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector AddConnectorAction.java DeleteConnectorAction.java DeleteConnectorsAction.java EditConnectorAction.java SaveConnectorAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context AddContextAction.java DeleteContextAction.java DeleteContextsAction.java EditContextAction.java SaveContextAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/host AddAliasAction.java AddHostAction.java DeleteAliasAction.java DeleteAliasesAction.java DeleteHostAction.java DeleteHostsAction.java EditHostAction.java SaveAliasAction.java SaveHostAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm AddRealmAction.java DeleteRealmAction.java DeleteRealmsAction.java EditRealmAction.java SaveDataSourceRealmAction.java SaveJDBCRealmAction.java SaveJNDIRealmAction.java SaveMemoryRealmAction.java SaveUserDatabaseRealmAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources DeleteDataSourcesAction.java DeleteEnvEntriesAction.java DeleteMailSessionsAction.java DeleteResourceLinksAction.java DeleteUserDatabasesAction.java ListDataSourcesAction.java ListEnvEntriesAction.java ListMailSessionsAction.java ListResourceLinksAction.java ListUserDatabasesAction.java ResourcesTreeBuilder.java SaveDataSourceAction.java SaveEnvEntryAction.java SaveMailSessionAction.java SaveResourceLinkAction.java SaveUserDatabaseAction.java SetUpDataSourceAction.java SetUpEnvEntryAction.java SetUpMailSessionAction.java SetUpResourceLinkAction.java SetUpUserDatabaseAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/server EditServerAction.java SaveServerAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service AddServiceAction.java DeleteServiceAction.java DeleteServicesAction.java EditServiceAction.java SaveServiceAction.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users DeleteGroupsAction.java DeleteRolesAction.java DeleteUsersAction.java GroupForm.java ListGroupsAction.java ListRolesAction.java ListUsersAction.java SaveGroupAction.java SaveRoleAction.java SaveUserAction.java SetUpGroupAction.java SetUpRoleAction.java SetUpUserAction.java UserForm.java UsersTreeBuilder.java webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve AddValveAction.java DeleteValveAction.java DeleteValvesAction.java EditValveAction.java SaveAccessLogValveAction.java SaveRemoteAddrValveAction.java SaveRemoteHostValveAction.java SaveRequestDumperValveAction.java SaveSingleSignOnValveAction.java ValveUtil.java webapps/admin/connector connector.jsp connectors.jsp webapps/admin/context context.jsp contexts.jsp webapps/admin/host host.jsp hosts.jsp webapps/admin/realm dataSourceRealm.jsp jdbcRealm.jsp jndiRealm.jsp memoryRealm.jsp realms.jsp userDatabaseRealm.jsp webapps/admin/resources dataSource.jsp dataSources.jspf envEntries.jspf envEntry.jsp listDataSources.jspf
cvs commit: jakarta-tomcat-5 build.properties.default
billbarker2004/10/17 23:45:00
Modified:.build.properties.default
Log:
Update to struts-1.2.4
Revision ChangesPath
1.138 +4 -4 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.137
retrieving revision 1.138
diff -u -r1.137 -r1.138
--- build.properties.default 5 Oct 2004 14:01:52 - 1.137
+++ build.properties.default 18 Oct 2004 06:45:00 - 1.138
@@ -205,11 +205,11 @@
nsis.loc=${base-sf.loc}/nsis/nsis20.exe
-# - Struts, version 1.1 or later -
-struts.home=${base.path}/jakarta-struts-1.1
+# - Struts, version 1.2.4 or later -
+struts.home=${base.path}/jakarta-struts-1.2.4
struts.lib=${struts.home}/lib
struts.jar=${struts.lib}/struts.jar
-struts.loc=${base-jakarta.loc}/struts/binaries/jakarta-struts-1.1.tar.gz
+struts.loc=${base-jakarta.loc}/../struts/binaries/jakarta-struts-1.2.4.tar.gz
# --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp valves.jsp
[EMAIL PROTECTED] wrote: billbarker2004/10/17 23:37:57 Log: Remove DefaultContext. Providing management for the new default context won't be hard: we would need to instantiate it as a normal StdContext, and register it in JMX with a special name. Maybe in the createMBeans stuff that is used by the admin webapp. This can be done for both the per-host default context, and for the global one. I think this would work out very well. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tina Dexter/HCUK is out of the office.
I will be out of the office starting 18/10/2004 and will not return until 19/10/2004. ** This document should only be read by those persons to whom it is addressed and is not intended to be relied upon by any person without subsequent written confirmation of its contents. Accordingly, Hyundai Car (UK) disclaim all responsibility and accept no liability (including in negligence) for the consequences for any person acting, or refraining from acting, on such information prior to the receipt by those persons of subsequent written confirmation. If you have received this E-mail message in error, please notify us immediately by telephone on +44 (0) 1494 428 690. Please also destroy and delete the message from your computer. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this E-mail message is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 31753] New: -
remove!
Gary Youssef
National Sales Manager
Royal Links USA
The Advertising Hospitality Vehicle
800.908.6937 X 321
419.944.9007 Mobile
888.766.1879 Toll Free Fax
[EMAIL PROTECTED]
www.royallinksusa.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 17, 2004 10:49 PM
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 31753] New: -
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31753.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31753
inconsistency in #authenticate(Connection, ...) for JDBCRealm and
DataSourceRealm
Summary: inconsistency in #authenticate(Connection, ...) for
JDBCRealm and DataSourceRealm
Product: Tomcat 5
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I couldn't help noticing the inconsistency in #authenticate(Connection,
String,
String) for JDBCRealm and DataSourceRealm.
- Getting dbCredentials
JDBCRealm:
if (rs.next()) {
dbCredentials = rs.getString(1);
}
DataSourceRealm:
while (rs.next()) {
dbCredentials = rs.getString(1);
}
- Getting roles
JDBCRealm:
while (rs.next()) {
String role = rs.getString(1);
if (null!=role) {
roleList.add(role.trim());
}
}
DataSourceRealm:
while (rs.next()) {
list.add(rs.getString(1).trim());
}
I think the JDBCRealm approach is better in both cases.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bug reports
Hi, Will anyone care if we stop getting Tomcat 3, 4, and Watchdog bug reports emailed to this list, and start getting Tomcat 5 bug reports? Assuming everyone concurs on the above, whom do I ask? Infrastructure? Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug reports
Shapira, Yoav wrote: Hi, Will anyone care if we stop getting Tomcat 3, 4, and Watchdog bug reports emailed to this list, and start getting Tomcat 5 bug reports? Assuming everyone concurs on the above, whom do I ask? Infrastructure? +1. I don't see much use for these lists, so is a TC 5 list actually useful ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bug reports
Hi, Will anyone care if we stop getting Tomcat 3, 4, and Watchdog bug reports emailed to this list, and start getting Tomcat 5 bug reports? Assuming everyone concurs on the above, whom do I ask? Infrastructure? +1. I don't see much use for these lists, so is a TC 5 list actually useful ? It's not useful to me personally, I delete them immediately, but then again I visit Bugzilla fairly regularly and have custom queries that mimic these bug reports. I didn't know how other people feel. So is it [EMAIL PROTECTED] that I ask to stop these messages? Maybe apmail? Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.3 Stability Rating
Shapira, Yoav wrote: Hi, Tomcat 5.5.3 has been available for about a week now, so it's time for a stability vote. I tentatively rated it Alpha when releasing as my own personal impression, but I haven't had any significant issues with it myself. It passes our internal tests, and with the StandardWrapper hotfix it passes the Servlet and JSP TCKs. So: Tomcat 5.5.3 should be rated: [ ] Alpha still, because ??? [ X ] Beta, it's getting closer to stable [what's missing?] [ ] Stable, it's rock solid My vote, as shown above, is for Beta. What's missing from Stable rating: StandardWrapper hotfix, a few minor features for the JDT compiler that are done only for the Ant compiler, JDT compiler support for J2SE 5.0, a few bells and whistles. This vote will run for about 72 hours as usual. Also as usual, only committer votes are binding, but opinions from other readers are welcome. Thanks, So do we have a first beta ? ;) (72H/24H = 3 days, so I'm getting impatient :) ) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] [RESULT] 5.5.3 Stability Rating
Hi, Per the vote in http://marc.theaimsgroup.com/?t=10975956482r=1w=2, we've decided to announce that 5.5.3 is a Beta-quality release. There were three +1 votes (Remy, Filip, myself) and no other votes of any kind. I will make the announcement on the tomcat-user list and update the web site. Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 5.5.3 Stability Rating
Hi, I was typing the RESULT message as you were typing this one ;) We're all set with the first 5.5 beta. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 10:13 AM To: Tomcat Developers List Subject: Re: [VOTE] 5.5.3 Stability Rating Shapira, Yoav wrote: Hi, Tomcat 5.5.3 has been available for about a week now, so it's time for a stability vote. I tentatively rated it Alpha when releasing as my own personal impression, but I haven't had any significant issues with it myself. It passes our internal tests, and with the StandardWrapper hotfix it passes the Servlet and JSP TCKs. So: Tomcat 5.5.3 should be rated: [ ] Alpha still, because ??? [ X ] Beta, it's getting closer to stable [what's missing?] [ ] Stable, it's rock solid My vote, as shown above, is for Beta. What's missing from Stable rating: StandardWrapper hotfix, a few minor features for the JDT compiler that are done only for the Ant compiler, JDT compiler support for J2SE 5.0, a few bells and whistles. This vote will run for about 72 hours as usual. Also as usual, only committer votes are binding, but opinions from other readers are welcome. Thanks, So do we have a first beta ? ;) (72H/24H = 3 days, so I'm getting impatient :) ) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31758] New: - Tomcat version number in error messages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31758. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31758 Tomcat version number in error messages Summary: Tomcat version number in error messages Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] There was a bug fixed in the apache webserver somewhere back in 1.3 (maybe 1.3.26 or so) to hide the exact version number in error messages. Has there been any consideration to doing the same in Tomcat? The reason for the change was that in knowing the exact version, a hacker might be able to exploit a vulnerability known in that particular version. I know there are ways to hide the exact version by creating custom errorLogValves and such, but it seems I should have to. Also, I am not sure what all classes I need to override to get rid of all the version numbers. This may seem a minor point, but security folks love to make big issues out of minor points like this. I am not sure which Tomcat component this falls into, probably several since many things handle their own error messages - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31758] - Tomcat version number in error messages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31758. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31758 Tomcat version number in error messages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-18 15:01 --- You can do it already. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config context.xml
yoavs 2004/10/18 10:30:25 Modified:webapps/docs/config Tag: TOMCAT_5_0 context.xml Log: Typo fix. Revision ChangesPath No revision No revision 1.10.2.2 +2 -2 jakarta-tomcat-catalina/webapps/docs/config/context.xml Index: context.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/context.xml,v retrieving revision 1.10.2.1 retrieving revision 1.10.2.2 diff -u -r1.10.2.1 -r1.10.2.2 --- context.xml 31 Aug 2004 14:50:41 - 1.10.2.1 +++ context.xml 18 Oct 2004 17:30:25 - 1.10.2.2 @@ -259,7 +259,7 @@ of the flag is codefalse/code./p /attribute - attribute value=tldNamespaceAware required=false + attribute name=tldNamespaceAware required=false pIf the value of this flag is codetrue/code, the TLD files XML validation will be namespace-aware. If you turn this flag on, you should probably also turn codetldValidation/code on. The @@ -268,7 +268,7 @@ /p /attribute - attribute value=tldValidation required=false + attribute name=tldValidation required=false pIf the value of this flag is codetrue/code, the TLD files will be XML validated on context startup. The default value for this flag is codefalse/code, and setting it to true will incur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DataSourceRealm + DIGEST authentication
Hi, I was working on this as part of resolving the bugzilla items in this and related areas. I have 80% of this ready to commit (and for JDBCRealm as well). Once I commit this, are you in a position to test it? The plan is that if it works I will back-port the patch to TC4 and TC5.0.x (if 5.5.x isn't stable by then). I should be in a position to commit something in the next day or so. Mark -Original Message- From: Shinobu Kawai [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 2:59 AM To: [EMAIL PROTECTED] Subject: DataSourceRealm + DIGEST authentication Hi all, I'm making a DataSourceRealm that works with DIGEST authentication. I'm planning to achieve this by extending DataSourceRealm and implementing getPassword() and getPrincipal(). I would like to reuse the credentials(Connection, String) and roles(Connection, String) methods, but they are private. Is is possible to make these methods protected? Or, is there a better way to achieve this? Relative bugzilla issues: http://issues.apache.org/bugzilla/show_bug.cgi?id=19767 http://issues.apache.org/bugzilla/show_bug.cgi?id=29048 TIA. Best regards, -- Shinobu Kawai -- Shinobu Kawai [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp valves.jsp
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, October 17, 2004 11:54 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp valves.jsp [EMAIL PROTECTED] wrote: billbarker2004/10/17 23:37:57 Log: Remove DefaultContext. Providing management for the new default context won't be hard: we would need to instantiate it as a normal StdContext, and register it in JMX with a special name. Maybe in the createMBeans stuff that is used by the admin webapp. This can be done for both the per-host default context, and for the global one. Using a normal StdContext is obviously easiest from a programming standpoint. But my guess is that it would be special enough to cause headaches (e.g. You can have a DC under a Server, but a regular Context can't go there). I think that all that is really needed is the MBean to manage the DefaultContext file. It can even be pretty dumb, since there currently isn't a good mechanism to attempt to propogate JMX-managed changes to the affected Contexts (so, just don't even try :). The only real question would be how it integrates with Peter's new 'write server.xml' logic. I think this would work out very well. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/valve accessLogValve.jsp remoteAddrValve.jsp remoteHostValve.jsp requestDumperValve.jsp singleSignOnValve.jsp valves.jsp
Bill Barker wrote: Using a normal StdContext is obviously easiest from a programming standpoint. But my guess is that it would be special enough to cause headaches (e.g. You can have a DC under a Server, but a regular Context can't go there). I think that all that is really needed is the MBean to manage the DefaultContext file. It can even be pretty dumb, since there currently isn't a good mechanism to attempt to propogate JMX-managed changes to the affected Contexts (so, just don't even try :). The only real question would be how it integrates with Peter's new 'write server.xml' logic. I mentioned using StandardContext since it has all the necessary fields and methods for subcomponents. It's used as a JavaBean in that case: it will not be added as a child of another container, inited, etc. You can also use straight MBeans, but then you need to duplicate all the methods and fields, and it's less flexible (which might be ok). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.29 JSP compilation fails when using JDK 1.5.0
Okay, I now (belatedly) understand the problem.
The issue is that by default Jaspper is setting the target release to
1.3 but leaving the source release unspecified -- resulting in the JDK
1.5 javac default source release, 1.5 -- and javac won't allow this mixture.
I am attaching a set of patches that (1) defaults the source release to
1.3 as well and (2) allows this to be controlled in a completely
independent and analogous manner to target release.
I would appreciate seeing this in 5.0.30 :-)
--
Jess Holle
--- JspC.java 2004-10-05 13:30:36.0 -0500
+++ JspC.java-new 2004-10-18 15:11:30.851472700 -0500
@@ -98,6 +98,8 @@
private static final String SWITCH_CLASS_NAME = -c;
private static final String SWITCH_FULL_STOP = --;
private static final String SWITCH_COMPILE = -compile;
+private static final String SWITCH_SOURCE = -source;
+private static final String SWITCH_TARGET = -target;
private static final String SWITCH_URI_BASE = -uribase;
private static final String SWITCH_URI_ROOT = -uriroot;
private static final String SWITCH_FILE_WEBAPP = -webapp;
@@ -145,6 +147,7 @@
private String compiler = null;
private String compilerTargetVM = 1.3;
+private String compilerSourceVM = 1.3;
private boolean classDebugInfo = true;
private Vector extensions;
@@ -276,6 +279,10 @@
}
} else if (tok.equals(SWITCH_ENCODING)) {
setJavaEncoding(nextArg());
+} else if (tok.equals(SWITCH_SOURCE)) {
+setCompilerSourceVM(nextArg());
+} else if (tok.equals(SWITCH_TARGET)) {
+setCompilerTargetVM(nextArg());
} else {
if (tok.startsWith(-)) {
throw new JasperException(Unrecognized option: + tok +
@@ -479,6 +486,22 @@
compilerTargetVM = vm;
}
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public String getCompilerSourceVM()
+{
+ return compilerSourceVM;
+}
+
+/**
+ * @see Options#getCompilerSourceVM.
+ */
+public void setCompilerSourceVM( String vm )
+{
+ compilerSourceVM = vm;
+}
+
public TldLocationsCache getTldLocationsCache() {
return tldLocationsCache;
}
@@ -1156,5 +1179,4 @@
// pass straight through
}
}
-
}
--- Options.java2004-10-05 13:30:36.0 -0500
+++ Options.java-new2004-10-18 14:46:30.631270600 -0500
@@ -117,11 +117,16 @@
public String getCompiler();
/**
- * Compiler target VM, e.g. 1.1,1.2,1.3, or 1.4.
+ * Compiler target VM, e.g. 1.1, 1.2, 1.3, 1.4, or 1.5.
*/
public String getCompilerTargetVM();
/**
+ * Compiler source VM, e.g. 1.3, 1.4, or 1.5.
+ */
+public String getCompilerSourceVM();
+
+/**
* The cache for the location of the TLD's
* for the various tag libraries 'exposed'
* by the web application.
--- Compiler.java 2004-10-05 13:30:36.0 -0500
+++ Compiler.java-new 2004-10-18 14:44:05.863104200 -0500
@@ -386,6 +386,11 @@
info.append( compilerTargetVM= + options.getCompilerTargetVM() +
\n);
}
+if (options.getCompilerSourceVM() != null) {
+javac.setSource(options.getCompilerSourceVM());
+info.append( compilerSourceVM= + options.getCompilerSourceVM() +
\n);
+}
+
// Build includes path
PatternSet.NameEntry includes = javac.createInclude();
--- EmbeddedServletOptions.java 2004-10-05 13:30:36.0 -0500
+++ EmbeddedServletOptions.java-new 2004-10-18 14:42:33.480264200 -0500
@@ -144,6 +144,11 @@
private String compilerTargetVM = 1.3;
/**
+ * The compiler source VM (1.3 by default).
+ */
+private String compilerSourceVM = 1.3;
+
+/**
* Cache for the TLD locations
*/
private TldLocationsCache tldLocationsCache = null;
@@ -303,6 +308,14 @@
return compilerTargetVM;
}
+/**
+ * @see Options#getCompilerSourceVM
+ */
+public String getCompilerSourceVM()
+{
+ return compilerSourceVM;
+}
+
public boolean getErrorOnUseBeanInvalidClassAttribute() {
return errorOnUseBeanInvalidClassAttribute;
}
@@ -571,6 +584,11 @@
this.compilerTargetVM = compilerTargetVM;
}
+String compilerSourceVM = config.getInitParameter(compilerSourceVM);
+if(compilerSourceVM != null) {
+this.compilerSourceVM = compilerSourceVM;
+}
+
String javaEncoding = config.getInitParameter(javaEncoding);
if (javaEncoding != null) {
this.javaEncoding = javaEncoding;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DataSourceRealm + DIGEST authentication
Hi Mark, I was working on this as part of resolving the bugzilla items in this and related areas. I have 80% of this ready to commit (and for JDBCRealm as well). Once I commit this, are you in a position to test it? The plan is that if it works I will back-port the patch to TC4 and TC5.0.x (if 5.5.x isn't stable by then). I should be in a position to commit something in the next day or so. If only you had answered yesterday. I already made what I needed! ;) http://sylow.no-ip.com/pub/apache/jakarta/tomcat/DigestableDataSourceRealm.java Anyways, I need something working by the end of this month. I probably won't be able to test everything thoroughly, but I will test what I need (which is DIGEST authentication). Best regards, -- Shinobu Kawai -- Shinobu Kawai [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf StringCache.java CharChunk.java ByteChunk.java
remm2004/10/18 16:16:36
Modified:util/java/org/apache/tomcat/util/buf CharChunk.java
ByteChunk.java
Added: util/java/org/apache/tomcat/util/buf StringCache.java
Log:
- Refactor toString for the buffers, and add a cache.
- The cache works in two phases:
- First phase is heavily synchronized, and keeps statistics on String usage
- When first phase is done (after a number of calls to toString), a cache array is
generated; this might be a rather expensive operation
- During the second phase, unsynchronized lookups in the static cache are done to
try to avoid expensive toString conversions
- If the cache is registered in JMX (later ...), an operation exists to get back to
the beginning of the first phase. This could be useful
after installing new applications on the fly, which could have different Strign
requirements.
- I think it works really well for ByteChunk - String, since this is a quite
expensive operation (note: some of these conversions could
be optimized by assuming US-ASCII encoding, which I'll do for the session ID
cookie value since it's so commonly used - and the String
is not cacheable, obviously - but doing the trick everywhere would lead to major
problems). For CharChunk, it's less evident, as
it is a matter of allocating a String, a char array and then using an arraycopy to
move over the chars.
- This is configured using system properties, for example in the catalina.properties
file. Byte and char can be enabled separately.
Revision ChangesPath
1.16 +6 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java
Index: CharChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- CharChunk.java29 Aug 2004 17:14:41 - 1.15
+++ CharChunk.java18 Oct 2004 23:16:36 - 1.16
@@ -489,7 +489,13 @@
// Conversion and getters
public String toString() {
+return StringCache.toString(this);
+}
+
+public String toStringInternal() {
if( buff==null ) return null;
+//System.out.println(CC toString: + new String( buff, start, end-start));
+//Thread.dumpStack();
return new String( buff, start, end-start);
}
1.22 +36 -22
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- ByteChunk.java29 Aug 2004 17:14:41 - 1.21
+++ ByteChunk.java18 Oct 2004 23:16:36 - 1.22
@@ -166,6 +166,11 @@
public void setEncoding( String enc ) {
this.enc=enc;
}
+public String getEncoding() {
+if (enc == null)
+enc=DEFAULT_CHARACTER_ENCODING;
+return enc;
+}
/**
* Returns the message bytes.
@@ -448,28 +453,37 @@
// Conversion and getters
public String toString() {
- if (null == buff) {
- return null;
- }
- String strValue=null;
- try {
- if( enc==null ) enc=DEFAULT_CHARACTER_ENCODING;
- return new String( buff, start, end-start, enc );
- /*
- Does not improve the speed too much on most systems,
- it's safer to use the clasical new String().
-
- Most overhead is in creating char[] and copying,
- the internal implementation of new String() is very close to
- what we do. The decoder is nice for large buffers and if
- we don't go to String ( so we can take advantage of reduced GC)
-
- // Method is commented out, in:
- return B2CConverter.decodeString( enc );
- */
- } catch (java.io.IOException e) {
- return null; // XXX
- }
+if (null == buff) {
+return null;
+} else if (end-start == 0) {
+return ;
+}
+return StringCache.toString(this);
+}
+
+public String toStringInternal() {
+String strValue=null;
+try {
+if( enc==null ) enc=DEFAULT_CHARACTER_ENCODING;
+strValue = new String( buff, start, end-start, enc );
+/*
+ Does not improve the speed too much on most systems,
+ it's safer to use the clasical new String().
+
+ Most overhead is in creating char[]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf CharChunk.java
remm2004/10/18 16:19:36
Modified:util/java/org/apache/tomcat/util/buf CharChunk.java
Log:
- Fix CharChunk.toString, and remove dead debug.
Revision ChangesPath
1.17 +6 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java
Index: CharChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- CharChunk.java18 Oct 2004 23:16:36 - 1.16
+++ CharChunk.java18 Oct 2004 23:19:36 - 1.17
@@ -489,14 +489,16 @@
// Conversion and getters
public String toString() {
+if (null == buff) {
+return null;
+} else if (end-start == 0) {
+return ;
+}
return StringCache.toString(this);
}
public String toStringInternal() {
- if( buff==null ) return null;
-//System.out.println(CC toString: + new String( buff, start, end-start));
-//Thread.dumpStack();
- return new String( buff, start, end-start);
+return new String(buff, start, end-start);
}
public int getInt()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf StringCache.java CharChunk.java ByteChunk.java
[EMAIL PROTECTED] wrote: remm2004/10/18 16:16:36 Modified:util/java/org/apache/tomcat/util/buf CharChunk.java ByteChunk.java Added: util/java/org/apache/tomcat/util/buf StringCache.java Log: - Refactor toString for the buffers, and add a cache. - The cache works in two phases: - First phase is heavily synchronized, and keeps statistics on String usage - When first phase is done (after a number of calls to toString), a cache array is generated; this might be a rather expensive operation - During the second phase, unsynchronized lookups in the static cache are done to try to avoid expensive toString conversions - If the cache is registered in JMX (later ...), an operation exists to get back to the beginning of the first phase. This could be useful after installing new applications on the fly, which could have different Strign requirements. - I think it works really well for ByteChunk - String, since this is a quite expensive operation (note: some of these conversions could be optimized by assuming US-ASCII encoding, which I'll do for the session ID cookie value since it's so commonly used - and the String is not cacheable, obviously - but doing the trick everywhere would lead to major problems). For CharChunk, it's less evident, as it is a matter of allocating a String, a char array and then using an arraycopy to move over the chars. - This is configured using system properties, for example in the catalina.properties file. Byte and char can be enabled separately. More optimizations: - Optimize getting session id from the session id cookies: there might be more that one cookie, and all use straight byte - String conversion (although they are conversion friendly US-ASCII encoded); this will also avoid keeping track of too much stuff in the byte cache - Enable the cache for ByteChunk by default (so that it gets tested, and optimizing away some of these expensive conversions could be quite useful) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf web.xml
luehe 2004/10/18 16:51:08 Modified:catalina/src/conf web.xml Log: Reformated prior to making changes Revision ChangesPath 1.48 +7 -6 jakarta-tomcat-catalina/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/web.xml,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- web.xml 5 Oct 2004 21:15:16 - 1.47 +++ web.xml 18 Oct 2004 23:51:08 - 1.48 @@ -111,12 +111,13 @@ !-- is the time in seconds between checks to see -- !-- if a JSP page needs to be recompiled. [300]-- !-- -- - !-- modificationTestIntervalCauses a JSP (and its dependent-- - !-- files) to not be checked for modification -- - !-- during the specified time interval -- - !-- (in seconds) from the last time the JSP was-- - !-- checked for modification. A value of 0 will-- - !-- cause the JSP to be checked on every access. -- + !-- modificationTestInterval -- + !-- Causes a JSP (and its dependent files) to not -- + !-- be checked for modification during the -- + !-- specified time interval (in seconds) from the -- + !-- last time the JSP was checked for -- + !-- modification. A value of 0 will cause the JSP -- + !-- to be checked on every access. -- !-- Used in development mode only. [4] -- !-- -- !-- compilerWhich compiler Ant should use to compile JSP -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf web.xml
luehe 2004/10/18 16:58:21 Modified:catalina/src/conf web.xml Log: Updated description of 'development' init param Revision ChangesPath 1.49 +4 -2 jakarta-tomcat-catalina/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/web.xml,v retrieving revision 1.48 retrieving revision 1.49 diff -u -r1.48 -r1.49 --- web.xml 18 Oct 2004 23:51:08 - 1.48 +++ web.xml 18 Oct 2004 23:58:21 - 1.49 @@ -131,8 +131,10 @@ !-- generated servlets? [Created dynamically -- !-- based on the current web application] -- !-- -- - !-- development Is Jasper used in development mode (will check -- - !-- for JSP modification on every access)? [true] -- + !-- development Is Jasper used in development mode? If true, -- + !-- the frequency at which JSPs are checked for-- + !-- modification may be specified via the -- + !-- modificationTestInterval parameter. [true] -- !-- -- !-- enablePooling Determines whether tag handler pooling is -- !-- enabled [true]-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf web.xml
luehe 2004/10/18 18:43:04 Modified:catalina/src/conf web.xml Log: Clarified description of 'reloading' init param. I'm about to remove this param altogether, as it is redundant and misleading (it's only evaluated in deployment mode): reloading=true should be covered by checkInterval0 reloading=false should be covered by checkInterval=0 Let me know if there are any objections to removing this param and associated APIs. This is currently only used in JspRuntimeContext to determine whether thread for background compiles should be spawn, and may be replaced as described above. Revision ChangesPath 1.50 +4 -1 jakarta-tomcat-catalina/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/web.xml,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- web.xml 18 Oct 2004 23:58:21 - 1.49 +++ web.xml 19 Oct 2004 01:43:04 - 1.50 @@ -160,7 +160,10 @@ !-- trimSpaces Should white spaces in template text between -- !-- actions or directives be trimmed? [false] -- !-- -- - !-- reloading Should Jasper check for modified JSPs? [false] -- + !-- reloading Should Jasper check for and reload modified-- + !-- JSPs in deployment mode (development is set to -- + !-- false)? If true, background compiles are -- + !-- enabled every checkInterval seconds. [false] -- !-- -- !-- suppressSmapShould the generation of SMAP info for JSR45 -- !-- debugging be suppressed? [false] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31741] - servlet request forward to jsp with jsp:include tag can cause extra request to be submitted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31741 servlet request forward to jsp with jsp:include tag can cause extra request to be submitted --- Additional Comments From [EMAIL PROTECTED] 2004-10-19 04:13 --- This does not seem to be an issue in Tomcat 5.0.28. The output I got is below and seems to be correct. -- Request: [EMAIL PROTECTED] reqNum=1: Start Request: [EMAIL PROTECTED] reqNum=1: Sleep Request: [EMAIL PROTECTED] reqNum=2: Start Request: [EMAIL PROTECTED] reqNum=2: Forward Request: [EMAIL PROTECTED] reqNum=2: Finish Request: [EMAIL PROTECTED] reqNum=1: Forward Request: [EMAIL PROTECTED] reqNum=1: Finish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31766] New: - Error getting client certificate under iPlanet 6.1/Tomact 5.0.28
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31766. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31766 Error getting client certificate under iPlanet 6.1/Tomact 5.0.28 Summary: Error getting client certificate under iPlanet 6.1/Tomact 5.0.28 Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Native:JK AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This bug seems to be basically the same as 15790, but under 5.0.28. I am using Sun One Webserver 6.1 (the latest incarnation of Netscape iPlanet) with 1.2.6 of JK. Tomcat 5.0.28 is running under Sun's J2SDK 1.4.2_05 I apologise if this is a duplicate of an existing bug. When I try to get the client certificate from the request using the code below, I get an exception. This code is called from a JSP. java.security.cert.X509Certificate[] certs = (java.security.cert.X509Certificate[]) request.getAttribute( javax.servlet.request.X509Certificate ); SEVERE: Certificate convertion failed java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data at sun.security.x509.X509CertImpl.init(X509CertImpl.java:300) at sun.security.provider.X509Factory.engineGenerateCertificate (X509Factory.java:104) at java.security.cert.CertificateFactory.generateCertificate (CertificateFactory.java:389) at org.apache.jk.server.JkCoyoteHandler.action (JkCoyoteHandler.java:478) at org.apache.coyote.Request.action(Request.java:367) at org.apache.coyote.tomcat5.CoyoteRequest.getAttribute (CoyoteRequest.java:934) at org.apache.coyote.tomcat5.CoyoteRequestFacade.getAttribute (CoyoteRequestFacade.java:214) at org.apache.jsp.icc.cert_jsp._jspService(cert_jsp.java:50) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal (StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:160) at org.apache.jk.server.JkCoyoteHandler.invoke (JkCoyoteHandler.java:300) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534)
Respuesta de En Plenitud, por favor, lea con atención
Bienvenido a En Plenitud !! Si usted nos envió TODOS los datos necearios para la inscripción, en breve recibirá la confirmación de que ya puede disfrutar de todos nuestros servicios ingresando los datos de identificación (nombre de usuario y contraseña) que nos enviara. Si usted NO no nos envió todos los datos requeridos, por favor hágalo sin omitir ninguno pues no podremos registrarlo sin ellos: Nombre: Apellido: Dirección de email: Nombre de usuario que desea utilizar: Contraseña que desea utilizar: País de residencia: Ciudad de residencia: Fecha de nacimiento: Estado civil: Profesión: Sobre todo, no olvide incluir (además del resto de los datos) el nombre de usuario y la contraseña que desea utilizar. Los mismos son elegidos por usted, y no asignados por nosotros. Tenga en cuenta que: 1- No pueden existir dos personas con el mismo nombre de usuario (sería el equivalente de dos personas con el mismo pasaporte). Si este fue el motivo por el que no pudo registrarse, de nada vale que nos escriba para que lo inscribamos con un nombre de usuario que ya está en uso, porque nosotros tampoco podemos hacerlo. Por favor, vuelva a inscribirse eligiendo otro nombre de usuario (agergándole una cifra, o un guión intermedio, por ejemplo; Juan2003 en lugar de Juan). 2- La contraseña solo puede incluir letras y números, y no otros signos ni espacios intermedios. Esperando poder serle de ayuda y que disfrute todas las ventajas de ser miembro de esta comunidad, le saluda cordialmente Equipo de En Plenitud www.enplenitud.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
