[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562836#action_12562836 ] Vamsavardhana Reddy commented on GERONIMO-3757: --- "try to load with all available providers" is the first option I tried. And the results from IBMJDK 1.5, SunJDK 1.5 and Harmony 5.0M4 are not at all satisfying. It is much worse when the keystore password is not known (which is the case when a new keystore file is dropped in the keystores directory). Harmony won't load anything without the password; IBMJDK chooses wrong keystoreType etc. So, I decided to go with the file extension (which will allow users to drop any type of keystore file into the keystores directory) or defaultType when there is no extension and the user will be able to access the keystore from admin console right away. I was under the impression that when a new keystore is dropped in keystores directory, it won't be recognized by KeystoreManager unless a KeystoreInstance GBean is added to config.xml. But then I was wrong and KeystoreManager is dynamically adding the required KeystoreInstance gbean. If we don't decide upon the type at the type of the keystore at the time KeystoreManager adds the gbean, Option1: the user will have to stop the server, edit config.xml to correct the keystoreType and start the server, Option 2: make the keystoreType attribute manageable and add keystorePortlet pages to let the user change the type through admin console etc (which will be used only for new keystores added directly to keystores directory). So, I took the easy way out as it also keeps things simple :) > KeyStore type can't be changed > -- > > Key: GERONIMO-3757 > URL: https://issues.apache.org/jira/browse/GERONIMO-3757 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.0.2, 2.0.x, 2.1 >Reporter: Vasily Zakharov > Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch, > Geronimo-3757.patch, GERONIMO-3757.patch > > > For now (r612905), Geronimo is hardcoded to use JKS keystore type, which > prevents Geronimo from running on Harmony or other JDKs that have no JKS > implementation: > org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: > KeyStore tempKeystore = KeyStore.getInstance(JKS); > org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: > KeyStore keystore = > KeyStore.getInstance(FileKeystoreInstance.JKS); > To workaround this issue, one can change JKS to KeyStore.getDefaultType() > (this returns "BKS" for Harmony) or particular other keystore type, but this > requires source recompilation. Replacing > var/security/keystores/geronimo-default with the proper keystore type file is > not a problem. > A proper solution seems to apply the fix above to use the JDK-default > keystore type, and provide FileKeystoreInstance with an additional > configuration option, keystoreType, that would allow to change the keystore > type through config.xml without recompilation, like this: > > > PKCS12 > name="keystorePath">var/security/keystores/geronimo-pkcs12 > > > This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562832#action_12562832
]
Vamsavardhana Reddy commented on GERONIMO-3757:
---
for(String type: tempKeystoreTypes) {
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
break;
}
}
The reason for the above piece of code is that defaultType and the
corresponding algorithm name got from the Service need not be of same case.
For e.g. defaultType is "jks" where as the one we get from available types is
"JKS". Nothing more :). I did not want the keystoreTypes to show "jks" and
"JKS" at the sametime. I wanted the defaultType to have a value from
keystoreTypes so that the following line in createKeystore.jsp enables
selecting the defaultType:
selected>${keystoreType}
> KeyStore type can't be changed
> --
>
> Key: GERONIMO-3757
> URL: https://issues.apache.org/jira/browse/GERONIMO-3757
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: security
>Affects Versions: 2.0.2, 2.0.x, 2.1
>Reporter: Vasily Zakharov
> Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch,
> Geronimo-3757.patch, GERONIMO-3757.patch
>
>
> For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
> prevents Geronimo from running on Harmony or other JDKs that have no JKS
> implementation:
> org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
> KeyStore tempKeystore = KeyStore.getInstance(JKS);
> org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
> KeyStore keystore =
> KeyStore.getInstance(FileKeystoreInstance.JKS);
> To workaround this issue, one can change JKS to KeyStore.getDefaultType()
> (this returns "BKS" for Harmony) or particular other keystore type, but this
> requires source recompilation. Replacing
> var/security/keystores/geronimo-default with the proper keystore type file is
> not a problem.
> A proper solution seems to apply the fix above to use the JDK-default
> keystore type, and provide FileKeystoreInstance with an additional
> configuration option, keystoreType, that would allow to change the keystore
> type through config.xml without recompilation, like this:
>
>
> PKCS12
> name="keystorePath">var/security/keystores/geronimo-pkcs12
>
>
> This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Clustering of SFSB - Heads-up
Hello, David B. kindly reminded me I should mention the SFSB clustering work I am currently working on on the OpenEJB dev. list - so far, I only mentioned this work on the Geronimo dev. list. Firstly, apology for only mentioning this work now. Now, let me talk a little bit of this work: I will soon add support for the clustering of SFSB. By now, this clustering is only available with OpenEJB embedded within Geronimo. It should be easy to have this feature available with the standalone OpenEJB container by moving across an upcoming Geronimo sub-project to a new OpenEJB sub-project. For the history, my initial attempt had clustering classes in openejb- core and I discovered these clustering classes should be packaged in a separate JAR for class loading reasons - it was not such a big surprise. The clustering of SFSB is based on the same approach than for the clustering of Jetty or Tomcat Web-applications over WADI: we add a clustered SFSB container. When an EJB invocation enters this container, it traverses a stack of WADI Contextualisers whose responsibility is to locate the SFSB being invoked and ensure that the invoked SFSB instance is available locally, i.e. in this JVM by the SFSB instance manager. When the SFSB being invoked is on a remote clustered SFSB container, it is first passivated on this remote container and then activated on the container processing the EJB invocation. When an EJB client initially performs a remote JNDI lookup for a SFSB deployed to the clustered SFSB container, it connects to the configured Context.PROVIDER_URL. In the case of a successful lookup, the JNDI response contains the locations, e.g. [ejbd://localhost: 4201, ejbd://localhost:4202], of the clustered SFSB containers running the looked up SFSB. Based on these locations, the client knows where the SFSB is currently running and, hence, it can fail- over to another clustered SFSB container if the "primary" container becomes unavailable. On each EJB invocations, an updated list of locations may be returned with EJB responses if client locations differ from server-side ones. The server knows that it needs to provide an updated list of locations based on a non collision free integer derived from client locations which is attached to each EJB invocations. Clustered SFSB instances are replicated as per the same approach than for HTTPSessions in the case of Jetty or Tomcat Web-applications: configure the number of replicas to be maintained. As for HTTPSessions, it is possible to only replicate field level changes by leveraging the wadi-aop module. I will ping the list once again when my integration tests are completed. Meanwhile, if there are any concerns, then please feel free to raise them. Thanks, Gianny
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562806#action_12562806
]
Vasily Zakharov commented on GERONIMO-3757:
---
Summarizing, it seems we can assume the following things to be true:
- KeyStore.getDefaultType() is never null,
- KeyStore.getInstance(KeyStore.getDefaultType()) doesn't throw exceptions,
- KeyStore.getDefaultType() value is always present in providers list.
Right?
With these taken into account, we probably could use the following code for
initialization:
{code:java}
static {
// Get all the KeyStore algorithms supported.
keystoreTypes = new HashSet();
defaultType = KeyStore.getDefaultType();
Provider[] providers = Security.getProviders();
char[] emptystore = "emptystore".toCharArray();
for(Provider provider: providers) {
for(Provider.Service service: provider.getServices()) {
if(service.getType().equals("KeyStore")) {
// Not all types of keystores can be saved to disk when
empty.
// Do not add those types that will fail creation of an
empty keystore.
ByteArrayOutputStream baos = null;
try {
KeyStore ks = KeyStore.getInstance(type);
ks.load(null);
baos = new ByteArrayOutputStream();
ks.store(baos, emptystore);
String type = service.getAlgorithm();
keystoreTypes.add(type);
} catch(Throwable t) {
} finally {
if(baos != null) {
try {baos.close();} catch(Exception ignored){}
}
}
}
}
}
}
{code}
Objections?
As of loading keystore files, using default or file extensions sounds ok, but
it seems still possible to try to determine the keystore file type by trying to
load it with all available providers. What are disadvantages of this idea? It
seems pretty reliable. What about an algorithm like the following:
- Check file extension, if provider with such name exist, use that type.
- If extension is not identified, try to load with all available providers.
- If failed, use default type.
Considerations?
> KeyStore type can't be changed
> --
>
> Key: GERONIMO-3757
> URL: https://issues.apache.org/jira/browse/GERONIMO-3757
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: security
>Affects Versions: 2.0.2, 2.0.x, 2.1
>Reporter: Vasily Zakharov
> Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch,
> Geronimo-3757.patch, GERONIMO-3757.patch
>
>
> For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
> prevents Geronimo from running on Harmony or other JDKs that have no JKS
> implementation:
> org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
> KeyStore tempKeystore = KeyStore.getInstance(JKS);
> org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
> KeyStore keystore =
> KeyStore.getInstance(FileKeystoreInstance.JKS);
> To workaround this issue, one can change JKS to KeyStore.getDefaultType()
> (this returns "BKS" for Harmony) or particular other keystore type, but this
> requires source recompilation. Replacing
> var/security/keystores/geronimo-default with the proper keystore type file is
> not a problem.
> A proper solution seems to apply the fix above to use the JDK-default
> keystore type, and provide FileKeystoreInstance with an additional
> configuration option, keystoreType, that would allow to change the keystore
> type through config.xml without recompilation, like this:
>
>
> PKCS12
> name="keystorePath">var/security/keystores/geronimo-pkcs12
>
>
> This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3243) ActiveMQ violates System Properties
[
https://issues.apache.org/jira/browse/GERONIMO-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562785#action_12562785
]
solprovider commented on GERONIMO-3243:
---
If you are worried about disabling the locking, just fix ActiveMQ. If you can
compile Java-1.5, easy instructions are in the fourth comment:
https://issues.apache.org/activemq/browse/AMQ-1254
2007-04-01: ActiveMQ-4.1.1 released broken. This bug was in previous releases.
2007-05-28: Bug is reported.
2007-07-07: Fix submitted.
2007-07-23: Fix added to ActiveMQ-Trunk.
2007-10-18: Geronimo's most recent release did not include the fix..
2007-12-17: ActiveMQ-5.0.0 release includes the fix. .
An ActiveMQ or Geronimo Committer should apply the fix to the ActiveMQ-4.1.1
release (and rename to ActiveMQ-4.1.1a?) Code violating basic Java should not
remain unpatched.
> ActiveMQ violates System Properties
> ---
>
> Key: GERONIMO-3243
> URL: https://issues.apache.org/jira/browse/GERONIMO-3243
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: ActiveMQ
>Affects Versions: 2.0.1, 2.0.2
>Reporter: solprovider
>Priority: Blocker
> Fix For: 2.1
>
>
> The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
> Geronimo development please add all affected versions?)
> ActiveMQ adds a HashMap as a global Property named
> "org.apache.activeio.journal.active.lockMap".
> Properties must use Strings for keys and values per
> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
> This causes any code reading all the Properties and expecting Strings to
> error.
> {code:title=Test Code|borderStyle=solid}
>boolean test(){ //true = passes, false = failed.
> boolean test = true;
> java.util.Properties properties = System.getProperties();
> java.util.Enumeration enumeration = properties.elements();
> while(test & enumeration.hasMoreElements()) test=
> String.class.equals(enumeration.nextElement().getClass());
> enumeration = properties.keys();
> while(test & enumeration.hasMoreElements()) test=
> String.class.equals(enumeration.nextElement().getClass());
> return test;
>}
> {code}
> The permanent fix is for Geronimo to update to a better version of ActiveMQ,
> either downgrading to before the bug was programmed or wait for the ActiveMQ
> team to follow the standards. That is unlikely to be tested and released
> quickly.
> The quick fix is to disable the offensive code. For Geronimo 1.2 on
> Windows, add this line at the beginning of STARTUP.BAT:
> SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
> %GERONIMO_OPTS%
> David Jencks suggested that Geronimo can set the
> org.apache.activeio.journal.active.DisableLocking property in a Geronimo
> SystemProperties gbean, there's one called ServerSystemProperties in
> j2ee-server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562786#action_12562786 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 615417 in branches\2.0 and trunk (2.1) o NestedJarFile should close the baseJar only if it is created by itself. o This is sort of correcting the previous rev 615389 which may close the parent jar in one case (I doubt if we will be hitting that instance in Geronimo, but just to keep things straight...) > DeployerReaper fails to cleanup the temp directories left behind by deployer > > > Key: GERONIMO-3764 > URL: https://issues.apache.org/jira/browse/GERONIMO-3764 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 >Reporter: Vamsavardhana Reddy >Assignee: Vamsavardhana Reddy > Fix For: 2.0.x, 2.1 > > Attachments: GERONIMO-3764-2.0.patch, > GERONIMO-3764-deploymentutil.patch > > > Deployer creates a temporary directory and cleans up the directory once > deployment operation is completed. When deletion of a temp dir fails, the > deployer leaves it upto DeployerReaper to cleanup the directory later on. > DeployerReaper is failing to cleanup these directories as only the dir name > (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3789) ConfigurationUtil ERROR log when executing gsh command
ConfigurationUtil ERROR log when executing gsh command -- Key: GERONIMO-3789 URL: https://issues.apache.org/jira/browse/GERONIMO-3789 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1 Reporter: Kevan Miller Fix For: 2.1 When executing the following command: 'gsh deploy/list-modules', I received the following log ERROR message: coltrane:bin kevan$ ./gsh deploy/list-modules Apache Geronimo (2.1-SNAPSHOT) Type 'help' for more information. -- Connecting to Geronimo server: localhost:1099 Username: system Password: *** 18:42:21,866 ERROR [ConfigurationUtil] Cound not determine the installation directory of Apache Geronimo, because the startup jar could not be found in the current class loader. Connection established Found 84 modules + org.apache.geronimo.configs/activemq-broker/2.1-SNAPSHOT/car -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3744) Shorten the option names for OpenejbRemoteLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3744. -- Resolution: Fixed Fix Version/s: (was: 2.0.x) Only found one more login module, fixed in rev 615401. > Shorten the option names for OpenejbRemoteLoginModule > - > > Key: GERONIMO-3744 > URL: https://issues.apache.org/jira/browse/GERONIMO-3744 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 2.0.2 >Reporter: Jonathan Chen >Assignee: David Jencks >Priority: Minor > Fix For: 2.1 > > Attachments: p > > > The option keys for org.apache.geronimo.openejb.OpenejbRemoteLoginModule are > very long, ie: >org.apache.geronimo.openejb.OpenejbRemoteLoginModule.RemoteSecurityRealm >org.apache.geronimo.openejb.OpenejbRemoteLoginModule.ServerURI > making for some very long entries within a JAAS configuration file. IMHO, > having the class-name as part of the option key serves no purpose, as the > option key are only visible to OpenejbRemoteLoginModule. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3744) Shorten the option names for OpenejbRemoteLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562761#action_12562761 ] David Jencks commented on GERONIMO-3744: Fixed that login module in rev 615397, preserving use of long names too. Should do this for the other g. login modules as well. Don't know what I was thinking with the long option names :-( > Shorten the option names for OpenejbRemoteLoginModule > - > > Key: GERONIMO-3744 > URL: https://issues.apache.org/jira/browse/GERONIMO-3744 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 2.0.2 >Reporter: Jonathan Chen >Assignee: David Jencks >Priority: Minor > Fix For: 2.0.x, 2.1 > > Attachments: p > > > The option keys for org.apache.geronimo.openejb.OpenejbRemoteLoginModule are > very long, ie: >org.apache.geronimo.openejb.OpenejbRemoteLoginModule.RemoteSecurityRealm >org.apache.geronimo.openejb.OpenejbRemoteLoginModule.ServerURI > making for some very long entries within a JAAS configuration file. IMHO, > having the class-name as part of the option key serves no purpose, as the > option key are only visible to OpenejbRemoteLoginModule. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3744) Shorten the option names for OpenejbRemoteLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-3744: -- Assignee: David Jencks > Shorten the option names for OpenejbRemoteLoginModule > - > > Key: GERONIMO-3744 > URL: https://issues.apache.org/jira/browse/GERONIMO-3744 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 2.0.2 >Reporter: Jonathan Chen >Assignee: David Jencks >Priority: Minor > Fix For: 2.0.x, 2.1 > > Attachments: p > > > The option keys for org.apache.geronimo.openejb.OpenejbRemoteLoginModule are > very long, ie: >org.apache.geronimo.openejb.OpenejbRemoteLoginModule.RemoteSecurityRealm >org.apache.geronimo.openejb.OpenejbRemoteLoginModule.ServerURI > making for some very long entries within a JAAS configuration file. IMHO, > having the class-name as part of the option key serves no purpose, as the > option key are only visible to OpenejbRemoteLoginModule. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562747#action_12562747 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 615389 in branches\2.0 and trunk (2.1) o NestedJarFile should close the baseJar irrespective of whether it is packed or not. In case of inPlace deployment of an ear file, not closing baseJar is resulting in a lock on DUMMY_JAR_FILE. > DeployerReaper fails to cleanup the temp directories left behind by deployer > > > Key: GERONIMO-3764 > URL: https://issues.apache.org/jira/browse/GERONIMO-3764 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 >Reporter: Vamsavardhana Reddy >Assignee: Vamsavardhana Reddy > Fix For: 2.0.x, 2.1 > > Attachments: GERONIMO-3764-2.0.patch, > GERONIMO-3764-deploymentutil.patch > > > Deployer creates a temporary directory and cleans up the directory once > deployment operation is completed. When deletion of a temp dir fails, the > deployer leaves it upto DeployerReaper to cleanup the directory later on. > DeployerReaper is failing to cleanup these directories as only the dir name > (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2814) Add a second repository to Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-2814: --- Fix Version/s: (was: 2.1) Wish List This is probably suitable for a plugin we don't supply installed in geronimo. Updating to a 2.1 plugin would be great. > Add a second repository to Geronimo > --- > > Key: GERONIMO-2814 > URL: https://issues.apache.org/jira/browse/GERONIMO-2814 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.1.x, 2.0-M2 >Reporter: Ted Kirby >Priority: Minor > Fix For: Wish List > > Attachments: GERONIMO-2814-J2EEServerImpl.patch, JIRA-2814-2.0.patch, > repo2-1.2-plan.xml, repo2-111-plan.xml, repo2-ag20-plan.xml, > repo2-ag20-plan2.xml, ServerRepository-ag20-export.zip, > ServerRepository-ag20-plan.xml > > > It would be nice to allow for a second repository for applications separate > from the default repository used by geronimo. > One use case would be for multiple server instances where the geronimo > repository would be read-only, and each server instance would have its own > read-write repository. > I have attached a 2.0 plan for a second repository, called repo2.xml. > Here is how to use it: > mkdir /repo2 > deploy repo2.xml > The target names are long and cumbersome: > >java deployer.jar list-targets > Available Targets: > > org.example.configs/myrepo/2.0-SNAPSHOT/car?ServiceModule=org.example.configs/myrepo/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local2 > > org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local > Use of environment variables recommended for command-line use. > To deploy to the new repo, use: > deploy --targets %REPO2% sample.war > deploy list-modules also gives those long target names on each module. > However, deploy list-modules %REPO2% gives the accustomed short output. > >java deployer.jar undeploy "%REPO2%|geronimo/jsp-examples/1.1.1/war" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3123) Create a template/var directory for creating additional instances of geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3123: --- Fix Version/s: (was: 2.1) Wish List didn't get into 2.1 either, but now I am even more certain that the way to do this is with plugins. An extreme example is the geronimo-boilerplate-minimal plugin which sets up all the stuff needed for a base server, except the additional stuff installed from other plugins. However it should certainly be possible to set up a new var directory and a repo gbean to point into it using a plugin. > Create a template/var directory for creating additional instances of geronimo > - > > Key: GERONIMO-3123 > URL: https://issues.apache.org/jira/browse/GERONIMO-3123 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.0-M6 > Environment: All >Reporter: Anita Kulshreshtha >Assignee: Anita Kulshreshtha >Priority: Minor > Fix For: Wish List > > Attachments: asm.patch > > > Related discussions: > http://www.nabble.com/Naming-the-servers-tf3655401s134.html > http://www.nabble.com/Re%3A-Help-needed-with-geronimo.sh-p10200885s134.html > Create a template/var and /var in GHOME. If the server is > started using java -jar bin\server.jar, the default will be used. It is not > necessary to use the default server. > The instances can be named using > set > GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=thisIsWhereTheServerInstanceDataIsLocatedIfYourLookingForIt/geronimo01, > portOffset=0, i.e. it behaves like the default server > set > GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=thisIsWhereTheServerInstanceDataIsLocatedIfYourLookingForIt/geronimo02, > portOffset=10, > ... > copy 'var' to > GHOME/thisIsWhereTheServerInstanceDataIsLocatedIfYourLookingForIt/geronimo01 > and use bin\startup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3604) Problem with JCA connectors
[ https://issues.apache.org/jira/browse/GERONIMO-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3604. -- Resolution: Fixed Fix Version/s: (was: 2.0.x) No response so I'll believe Jacek that it's fixed. > Problem with JCA connectors > --- > > Key: GERONIMO-3604 > URL: https://issues.apache.org/jira/browse/GERONIMO-3604 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.0.2 >Reporter: ivica cardic > Fix For: 2.1 > > > I have JCA connector and it is registered and started correctly. Then I stop > it and try to start again and after that I get this exception: > 11:49:56,670 ERROR [OpenEjbSystemGBean] Unable to deploy mdb container > orcConnector.rar.Orc Inbound Resource > Adapter-hr.in2.invest.iba.connectors.orc.mdb.OrcMessageListener > org.apache.openejb.OpenEJBException: Cannot bind Container with id > orcConnector.rar.Orc Inbound Resource > Adapter-hr.in2.invest.iba.connectors.orc.mdb.OrcMessageListener: null > at > org.apache.openejb.assembler.classic.Assembler.createContainer(Assembler.java:719) > at > org.apache.geronimo.openejb.OpenEjbSystemGBean.addResourceAdapter(OpenEjbSystemGBean.java:262) > at > org.apache.geronimo.openejb.OpenEjbSystemGBean.access$000(OpenEjbSystemGBean.java:84) > at > org.apache.geronimo.openejb.OpenEjbSystemGBean$1.memberAdded(OpenEjbSystemGBean.java:208) > at > org.apache.geronimo.gbean.runtime.ProxyCollection.addTarget(ProxyCollection.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanCollectionReference.targetAdded(GBeanCollectionReference.java:96) > at > org.apache.geronimo.gbean.runtime.GBeanCollectionReference.addTarget(GBeanCollectionReference.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanCollectionReference$1.running(GBeanCollectionReference.java:110) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:511) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$3ce6eb59.startConfiguration() > at > org.apache.geronimo.console.configmanager.ConfigManagerPortlet.processAction(ConfigManagerPortlet.java:208) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) >
[jira] Closed: (GERONIMO-3340) Take apache directory plugin out of the main build, put it in plugins.
[ https://issues.apache.org/jira/browse/GERONIMO-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3340. -- Resolution: Fixed well, its out of the main build. I think we should track progress on making the plugin work and releasing it in separate issues. > Take apache directory plugin out of the main build, put it in plugins. > -- > > Key: GERONIMO-3340 > URL: https://issues.apache.org/jira/browse/GERONIMO-3340 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 2.0-M6 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1 > > Attachments: GERONIMO-3340-patch.txt > > > I'm not sure updating the directory plugin to 1.0 or 1.5 will happen before > 2.0 is cut and shipping the current version is pretty useless. This way we > can decouple the releases a bit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3512) Need TranQL vendor plugins for trunk
[ https://issues.apache.org/jira/browse/GERONIMO-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3512. -- Resolution: Fixed Assignee: David Jencks Someone added them they are pulled in by the sysdb-console-jetty/tomcat > Need TranQL vendor plugins for trunk > > > Key: GERONIMO-3512 > URL: https://issues.apache.org/jira/browse/GERONIMO-3512 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: databases, Plugins >Affects Versions: 2.1 >Reporter: Donald Woods >Assignee: David Jencks > Fix For: 2.1 > > > These were added to the 2.0.2 release, but are missing from the trunk (2.1) > release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3416) make some -test artifacts that for instance start up a mock server suitable for testing deployment parts
[ https://issues.apache.org/jira/browse/GERONIMO-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3416: --- Fix Version/s: (was: 2.1) Wish List > make some -test artifacts that for instance start up a mock server suitable > for testing deployment parts > > > Key: GERONIMO-3416 > URL: https://issues.apache.org/jira/browse/GERONIMO-3416 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0 >Reporter: David Jencks >Assignee: David Jencks > Fix For: Wish List > > > There's a lot of duplicated code among the deployer tests. A lot of it could > be simplified if we had one or two -test.jar artifacts from appropriate > modules (kernel and system come to mind) that for instance set up a "mock > server" with config stores, repos, etc etc started. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3448) New threads launched from an EJB do not run as the same Subject as the launching thread
[ https://issues.apache.org/jira/browse/GERONIMO-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3448: --- Fix Version/s: (was: 2.1) (was: 2.0.x) Wish List > New threads launched from an EJB do not run as the same Subject as the > launching thread > --- > > Key: GERONIMO-3448 > URL: https://issues.apache.org/jira/browse/GERONIMO-3448 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.0.x, 2.1 >Reporter: Vamsavardhana Reddy > Fix For: Wish List > > > New threads launched from an EJB context do not run as the same Subject as > the thread that launched it. This causes a failure when this new thread > calls an EJB with restricted method permissions. Looks like JBoss and BEA > Weblogic carry over Subjects to new threads that are launched from within an > EJB. > See http://marc.info/?l=geronimo-dev&m=118819475331338&w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2401) Upgrade commons-logging to 1.1
[ https://issues.apache.org/jira/browse/GERONIMO-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-2401: --- Fix Version/s: (was: 2.1) Wish List Definitely important but will not get into 2.1 > Upgrade commons-logging to 1.1 > -- > > Key: GERONIMO-2401 > URL: https://issues.apache.org/jira/browse/GERONIMO-2401 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: dependencies, Logging >Affects Versions: 1.2, 2.0-M5 >Reporter: Jason Dillon >Assignee: Jason Dillon > Fix For: Wish List > > > Upgrade commons-logging to the latest release 1.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3417) Implement JASPI
[ https://issues.apache.org/jira/browse/GERONIMO-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3417: --- Fix Version/s: (was: 2.1) Wish List Not happening for 2.1 > Implement JASPI > --- > > Key: GERONIMO-3417 > URL: https://issues.apache.org/jira/browse/GERONIMO-3417 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.0 >Reporter: David Jencks >Assignee: David Jencks > Fix For: Wish List > > > We should implement JASPI (jsr-196) > Guillaume already implemented the spec jar for an earlier version of the spec > and did some work on implementation classes. I've updated the spec jar to > the latest spec and started moving the implementation into geronimo-security. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3779) Server assembly is not respecting version specified in pom
[ https://issues.apache.org/jira/browse/GERONIMO-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3779. -- Resolution: Fixed Fixed in rev 615381. Unfortunately I don't really see how to write a test for this. > Server assembly is not respecting version specified in pom > -- > > Key: GERONIMO-3779 > URL: https://issues.apache.org/jira/browse/GERONIMO-3779 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.1 >Reporter: David Jencks >Assignee: David Jencks >Priority: Blocker > Fix For: 2.1 > > > I noticed that if I get geronimo-jsp_2.1_spec-1.0.1-SNAPSHOT into my local > repo it shows up in the server instead of the 1.0 version specified in the > (root) pom. Apparently filtering the local maven repo to show only stuff > specified in the pom is not working correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3783) MessageDrivenBean delivery problem
[ https://issues.apache.org/jira/browse/GERONIMO-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562155#action_12562155 ] beniamin edited comment on GERONIMO-3783 at 1/25/08 2:25 PM: - Example to show my problem. Requirements: 1. installed Geronimo 2.1-snapshot 2. Ant 1.7.0 3. not to have Junit 3 on the classpath You need to: - edit build.properties file - run targets: - deploy - test / test-with-report was (Author: beniamin): Example to show my problem. Requirements: 1. installed Geronimo 2.1-snapshot You need to: - edit build.properties file - run targets: - deploy - test / test-with-report > MessageDrivenBean delivery problem > -- > > Key: GERONIMO-3783 > URL: https://issues.apache.org/jira/browse/GERONIMO-3783 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.1 > Environment: Windows XP Professional, 2GB ram, Java6SE, Geronimo > 2.1-snapshot (2008-01-02) >Reporter: Tomasz Mazan >Priority: Critical > Attachments: mdb-issue.zip > > > MessageDrivenBean that listens on the Queue receive (and process) some > messages and then stop receiving any new message until next module's restart. > After restart a few next messages are delivered to MDB, and it stops again. > Some additional information I put here > http://www.nabble.com/Strange-plug-with-delivering-messages-to-MDB-td14923100s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562692#action_12562692
]
cap edited comment on GERONIMO-3757 at 1/25/08 1:32 PM:
{quote}
1. defaultType can not be null. Ideally,
KeyStore.getInstance(KeyStore.getDefaultType()) is expected to not throw any
exceptions.
{quote}
Yes, we expect that KeyStore.getDefaultType() will not throw an exception.
But the code
{code:java}
for(String type: tempKeystoreTypes) {
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
break;
}
}
{code}
assumes that it is possible that there will not be default type in the type
list. Otherwise it can be changed to simple
{code:java}
defaultType = KeyStore.getDefaultType();
{code}
{quote}
2. The keystoreTypes is the list of types that will be shown for selection
while creating a keystore using Keystores portlet. It does not matter what the
defaultType is. If defaultType is in keystoreTypes, it will be selected,
otherwise the first one in the list will be selected. We are using these to
prevent users from selecting a keystore type that can not have an empty
keystore.
{quote}
ok. thanks.
was (Author: cap):
{quote}
1. defaultType can not be null. Ideally,
KeyStore.getInstance(KeyStore.getDefaultType()) is expected to not throw any
exceptions.
{quote}
Yes, we expect that KeyStore.getDefaultType() will not throw an exception.
But the code
{code:java}
for(String type: tempKeystoreTypes) {
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
break;
}
}
{code}
assumes that it is possible that there will not be default type in the type
list. Otherwise it can be changed to simple
{code:java}
defaultType =KeyStore.getDefaultType();
{quote}
2. The keystoreTypes is the list of types that will be shown for selection
while creating a keystore using Keystores portlet. It does not matter what the
defaultType is. If defaultType is in keystoreTypes, it will be selected,
otherwise the first one in the list will be selected. We are using these to
prevent users from selecting a keystore type that can not have an empty
keystore.
{quote}
ok. thanks.
> KeyStore type can't be changed
> --
>
> Key: GERONIMO-3757
> URL: https://issues.apache.org/jira/browse/GERONIMO-3757
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: security
>Affects Versions: 2.0.2, 2.0.x, 2.1
>Reporter: Vasily Zakharov
> Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch,
> Geronimo-3757.patch, GERONIMO-3757.patch
>
>
> For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
> prevents Geronimo from running on Harmony or other JDKs that have no JKS
> implementation:
> org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
> KeyStore tempKeystore = KeyStore.getInstance(JKS);
> org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
> KeyStore keystore =
> KeyStore.getInstance(FileKeystoreInstance.JKS);
> To workaround this issue, one can change JKS to KeyStore.getDefaultType()
> (this returns "BKS" for Harmony) or particular other keystore type, but this
> requires source recompilation. Replacing
> var/security/keystores/geronimo-default with the proper keystore type file is
> not a problem.
> A proper solution seems to apply the fix above to use the JDK-default
> keystore type, and provide FileKeystoreInstance with an additional
> configuration option, keystoreType, that would allow to change the keystore
> type through config.xml without recompilation, like this:
>
>
> PKCS12
> name="keystorePath">var/security/keystores/geronimo-pkcs12
>
>
> This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562692#action_12562692
]
Alexey Petrenko commented on GERONIMO-3757:
---
{quote}
1. defaultType can not be null. Ideally,
KeyStore.getInstance(KeyStore.getDefaultType()) is expected to not throw any
exceptions.
{quote}
Yes, we expect that KeyStore.getDefaultType() will not throw an exception.
But the code
{code:java}
for(String type: tempKeystoreTypes) {
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
break;
}
}
{code}
assumes that it is possible that there will not be default type in the type
list. Otherwise it can be changed to simple
{code:java}
defaultType =KeyStore.getDefaultType();
{quote}
2. The keystoreTypes is the list of types that will be shown for selection
while creating a keystore using Keystores portlet. It does not matter what the
defaultType is. If defaultType is in keystoreTypes, it will be selected,
otherwise the first one in the list will be selected. We are using these to
prevent users from selecting a keystore type that can not have an empty
keystore.
{quote}
ok. thanks.
> KeyStore type can't be changed
> --
>
> Key: GERONIMO-3757
> URL: https://issues.apache.org/jira/browse/GERONIMO-3757
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: security
>Affects Versions: 2.0.2, 2.0.x, 2.1
>Reporter: Vasily Zakharov
> Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch,
> Geronimo-3757.patch, GERONIMO-3757.patch
>
>
> For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
> prevents Geronimo from running on Harmony or other JDKs that have no JKS
> implementation:
> org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
> KeyStore tempKeystore = KeyStore.getInstance(JKS);
> org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
> KeyStore keystore =
> KeyStore.getInstance(FileKeystoreInstance.JKS);
> To workaround this issue, one can change JKS to KeyStore.getDefaultType()
> (this returns "BKS" for Harmony) or particular other keystore type, but this
> requires source recompilation. Replacing
> var/security/keystores/geronimo-default with the proper keystore type file is
> not a problem.
> A proper solution seems to apply the fix above to use the JDK-default
> keystore type, and provide FileKeystoreInstance with an additional
> configuration option, keystoreType, that would allow to change the keystore
> type through config.xml without recompilation, like this:
>
>
> PKCS12
> name="keystorePath">var/security/keystores/geronimo-pkcs12
>
>
> This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3777) Console/Plugin Installer - Remote Repo: Trying to download plugin with wrong naming convention
[ https://issues.apache.org/jira/browse/GERONIMO-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong resolved GERONIMO-3777. Resolution: Fixed Fixed in Revision 614105, Was reading wrong meta file '/' allowed the search to recurse to current path. Commited by Jarek > Console/Plugin Installer - Remote Repo: Trying to download plugin with wrong > naming convention > -- > > Key: GERONIMO-3777 > URL: https://issues.apache.org/jira/browse/GERONIMO-3777 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 > Environment: Ubuntu 7.10, Firefox 2.0.0.6 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1 > > > In Admin Console, when attempting to use the plugin installer to install from > a remote repo, the location of the file being download is being generated > incorrectly. Fails to append timestamp-build, thus leading to failure in > plugin installation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562675#action_12562675 ] Vamsavardhana Reddy commented on GERONIMO-3757: --- I also curious about CreateKeystoreHandler.defaultType variable... 1. As far as I understood from the code you want this variable to be null if KeyStore.getDefaultType() is not in the list of available keystore types. Is this possible? >From the other hand null type treated as KeyStore.getDefaultType() later in >the code. It is a bit confusing for me... 2. How will we handle situation if defaultType variable is not null but it is impossible to create empty store for this type and the type will be removed from the list on next step? Response: 1. defaultType can not be null. Ideally, KeyStore.getInstance(KeyStore.getDefaultType()) is expected to not throw any exceptions. 2. The keystoreTypes is the list of types that will be shown for selection while creating a keystore using Keystores portlet. It does not matter what the defaultType is. If defaultType is in keystoreTypes, it will be selected, otherwise the first one in the list will be selected. We are using these to prevent users from selecting a keystore type that can not have an empty keystore. > KeyStore type can't be changed > -- > > Key: GERONIMO-3757 > URL: https://issues.apache.org/jira/browse/GERONIMO-3757 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.0.2, 2.0.x, 2.1 >Reporter: Vasily Zakharov > Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch, > Geronimo-3757.patch, GERONIMO-3757.patch > > > For now (r612905), Geronimo is hardcoded to use JKS keystore type, which > prevents Geronimo from running on Harmony or other JDKs that have no JKS > implementation: > org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: > KeyStore tempKeystore = KeyStore.getInstance(JKS); > org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: > KeyStore keystore = > KeyStore.getInstance(FileKeystoreInstance.JKS); > To workaround this issue, one can change JKS to KeyStore.getDefaultType() > (this returns "BKS" for Harmony) or particular other keystore type, but this > requires source recompilation. Replacing > var/security/keystores/geronimo-default with the proper keystore type file is > not a problem. > A proper solution seems to apply the fix above to use the JDK-default > keystore type, and provide FileKeystoreInstance with an additional > configuration option, keystoreType, that would allow to change the keystore > type through config.xml without recompilation, like this: > > > PKCS12 > name="keystorePath">var/security/keystores/geronimo-pkcs12 > > > This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3243) ActiveMQ violates System Properties
[
https://issues.apache.org/jira/browse/GERONIMO-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562673#action_12562673
]
Aman Nanner commented on GERONIMO-3243:
---
We are experiencing this problem as well. I'm not sure what the effect is of
disabling ActiveMQ journal locking though, so I'm not sure how practical the
workaround is.
> ActiveMQ violates System Properties
> ---
>
> Key: GERONIMO-3243
> URL: https://issues.apache.org/jira/browse/GERONIMO-3243
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: ActiveMQ
>Affects Versions: 2.0.1, 2.0.2
>Reporter: solprovider
>Priority: Blocker
> Fix For: 2.1
>
>
> The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
> Geronimo development please add all affected versions?)
> ActiveMQ adds a HashMap as a global Property named
> "org.apache.activeio.journal.active.lockMap".
> Properties must use Strings for keys and values per
> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
> This causes any code reading all the Properties and expecting Strings to
> error.
> {code:title=Test Code|borderStyle=solid}
>boolean test(){ //true = passes, false = failed.
> boolean test = true;
> java.util.Properties properties = System.getProperties();
> java.util.Enumeration enumeration = properties.elements();
> while(test & enumeration.hasMoreElements()) test=
> String.class.equals(enumeration.nextElement().getClass());
> enumeration = properties.keys();
> while(test & enumeration.hasMoreElements()) test=
> String.class.equals(enumeration.nextElement().getClass());
> return test;
>}
> {code}
> The permanent fix is for Geronimo to update to a better version of ActiveMQ,
> either downgrading to before the bug was programmed or wait for the ActiveMQ
> team to follow the standards. That is unlikely to be tested and released
> quickly.
> The quick fix is to disable the offensive code. For Geronimo 1.2 on
> Windows, add this line at the beginning of STARTUP.BAT:
> SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
> %GERONIMO_OPTS%
> David Jencks suggested that Geronimo can set the
> org.apache.activeio.journal.active.DisableLocking property in a Geronimo
> SystemProperties gbean, there's one called ServerSystemProperties in
> j2ee-server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562651#action_12562651 ] Vamsavardhana Reddy commented on GERONIMO-3757: --- I thought it would be possible to determine the keystore type by trying to load the keystore file with various keystore implementations available in the JVM. After experimenting with IBMJDK 1.5, Sun JDK 1.5 and Harmony 5.0 M4 JRE, it appears to me that either using default keystore type or type based on file extension is the best option. This is applicable to only keystore files added directly to var/security/keystores directory. The keystores created using Keystores portlet need not have any extension in the name and can be of any type. > KeyStore type can't be changed > -- > > Key: GERONIMO-3757 > URL: https://issues.apache.org/jira/browse/GERONIMO-3757 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.0.2, 2.0.x, 2.1 >Reporter: Vasily Zakharov > Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch, > Geronimo-3757.patch, GERONIMO-3757.patch > > > For now (r612905), Geronimo is hardcoded to use JKS keystore type, which > prevents Geronimo from running on Harmony or other JDKs that have no JKS > implementation: > org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: > KeyStore tempKeystore = KeyStore.getInstance(JKS); > org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: > KeyStore keystore = > KeyStore.getInstance(FileKeystoreInstance.JKS); > To workaround this issue, one can change JKS to KeyStore.getDefaultType() > (this returns "BKS" for Harmony) or particular other keystore type, but this > requires source recompilation. Replacing > var/security/keystores/geronimo-default with the proper keystore type file is > not a problem. > A proper solution seems to apply the fix above to use the JDK-default > keystore type, and provide FileKeystoreInstance with an additional > configuration option, keystoreType, that would allow to change the keystore > type through config.xml without recompilation, like this: > > > PKCS12 > name="keystorePath">var/security/keystores/geronimo-pkcs12 > > > This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3788) Plugin installer's continue form generating errors
Plugin installer's continue form generating errors -- Key: GERONIMO-3788 URL: https://issues.apache.org/jira/browse/GERONIMO-3788 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1 After installing plugin components, the Continue Form page that the user is being redirected to is generating errors. 500 -Error -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3782) tld files may not be getting their schema upgraded correctly
[ https://issues.apache.org/jira/browse/GERONIMO-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3782. --- Resolution: Fixed Fix Version/s: 2.0.x Yes, there was a problem with dtd->xsd translation. Sometimes some elements were skipped during the translation (if there were the last child in a list). I committed fixes and tests to trunk (revision 615271, 615290) and branches/2.0 (revision 615305). > tld files may not be getting their schema upgraded correctly > > > Key: GERONIMO-3782 > URL: https://issues.apache.org/jira/browse/GERONIMO-3782 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0 >Reporter: David Jencks >Assignee: Jarek Gawor > Fix For: 2.0.x, 2.1 > > > A user reports that a tld file > http://jakarta.apache.org/taglibs/standard/scriptfree (apparently in > standard.jar) which starts out > > PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN" > "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd";> > > 1.0 > 1.2 > scriptfree > http://jakarta.apache.org/taglibs/standard/scriptfree > has schema info added properly but inside the validator element init-params > are not getting upgraded properly, they look like: > > allowDeclarations > false > Controls whether or not declarations are considered > valid. > > We need to investigate if this is consistent with the original dtd and if so > fix the upgrade code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3773) hostname lookup causes long startup time when offline
[ https://issues.apache.org/jira/browse/GERONIMO-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-3773. Resolution: Fixed Committed revision 615302. This is just the change to the yoko code to avoid the timeout issue. The repository version in geronimo will need replacing to enable the fix. > hostname lookup causes long startup time when offline > - > > Key: GERONIMO-3773 > URL: https://issues.apache.org/jira/browse/GERONIMO-3773 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: CORBA >Affects Versions: 2.1 >Reporter: Kevan Miller >Priority: Minor > Fix For: 2.1 > > > Noticed that when running offline (without any network connectivity), the > server startup time is much slower. Looks like yoko is trying to resolve the > local hostname from a name server. Is this required? can we use a dotted ip > address instead? Here's the stack trace: > "main" prio=5 tid=0x01001b80 nid=0xb0801000 runnable [0xb07ff000..0xb0800188] > at java.net.Inet6AddressImpl.getHostByAddr(Native Method) > at java.net.InetAddress$1.getHostByAddr(InetAddress.java:842) > at java.net.InetAddress.getHostFromNameService(InetAddress.java:532) > at java.net.InetAddress.getCanonicalHostName(InetAddress.java:503) > at org.apache.yoko.orb.OB.Net.getCanonicalHostname(Net.java:49) > at > org.apache.yoko.orb.OCI.IIOP.AccFactory_impl.create_acceptor(AccFactory_impl.java:153) > at > org.apache.yoko.orb.OBPortableServer.POAManagerFactory_impl.create_POAManager(POAManagerFactory_impl.java:251) > - locked <0x06dbe108> (a java.util.Hashtable) > at > org.apache.yoko.orb.OBPortableServer.POA_impl.create_POA(POA_impl.java:672) > - locked <0x056ad388> (a java.util.Hashtable) > at > org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.initialize(TransientNameService.java:139) > at > org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.run(TransientNameService.java:115) > at > org.apache.geronimo.yoko.ORBConfigAdapter.createNameService(ORBConfigAdapter.java:175) > at org.apache.geronimo.corba.NameService.doStart(NameService.java:164) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:998) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) > - locked <0x06dbaaf0> (a > org.apache.geronimo.gbean.runtime.GBeanDependency) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) > - locked <0x06dbaaf0> (a > org.apache.geronimo.gbean.runtime.GBeanDependency) > at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:534) > - locked <0x05bd8bf8> (a > org.apache.geronimo.kernel.config.EditableKernelConfigurationManager) > at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.jav
Re: Geronimo v2.1 documentation
Kevan Miller wrote: On Jan 25, 2008, at 11:22 AM, Hernan Cunico wrote: Guys, I've been trying to get your attention around Geronimo 2.1 documentation since October last year. Apache Geronimo is as good as you can communicate it to the users. How do you expect the users to know all the beeps and whistles? Not a best way to tell the users HOW TO do things in Geronimo than by having a good documentation. How much of your time it would actually take to write up a page describing a component or module and how to use it? It's you writing the code, why not you writing about that code and how to use it!? There are tons of questions on the user@ and dev@ lists about how to perform basic (and some times not so basic) tasks and configurations, we get these all the time. This is a clear sign that we need to improve the way we document the things. For 2.1 the situation is even worse, we pretty much don't have any documentation and we can't continue developing documentation the way we've been doing in the past. The way it looks now, Geronimo 2.1 won't have supporting documentation. Let's discuss here what areas need to be covered and who can work on documenting them. It is your turn now. Hernan, I hear your pain. And totally agree that good docs will make things much easier for our users (as well as ourselves). I know I'm as guilty (perhaps more so) as anyone else at failing to help pitch in. Everybody's pretty busy. Also, there's a definite tendency for skilled developers to be, well, skilled *developers*. Perhaps there are some alternate ways to help this process go faster? I wonder if it would be easier for people to discuss a particular topic with you on a phone call? Hopefully providing enough information for you to transform into flowery prose and lucid illustrations? If we want, we could make this a conference call (so interested parties could join). I don't think this technique can work for all docs. We can't expect you to write everything. However, it might help kickstart the process in some critical sections... --kevan If folks think that something like this could work - I would be happy to chip in as a typist. I took a look at the shell for the documentation and realized that I know far too little to be able to write the docs from scratch. Plus, it would be useful for me to be able to get more familiar with everything. Jay
Re: Geronimo v2.1 documentation
On Jan 25, 2008, at 11:22 AM, Hernan Cunico wrote: Guys, I've been trying to get your attention around Geronimo 2.1 documentation since October last year. Apache Geronimo is as good as you can communicate it to the users. How do you expect the users to know all the beeps and whistles? Not a best way to tell the users HOW TO do things in Geronimo than by having a good documentation. How much of your time it would actually take to write up a page describing a component or module and how to use it? It's you writing the code, why not you writing about that code and how to use it!? There are tons of questions on the user@ and dev@ lists about how to perform basic (and some times not so basic) tasks and configurations, we get these all the time. This is a clear sign that we need to improve the way we document the things. For 2.1 the situation is even worse, we pretty much don't have any documentation and we can't continue developing documentation the way we've been doing in the past. The way it looks now, Geronimo 2.1 won't have supporting documentation. Let's discuss here what areas need to be covered and who can work on documenting them. It is your turn now. Hernan, I hear your pain. And totally agree that good docs will make things much easier for our users (as well as ourselves). I know I'm as guilty (perhaps more so) as anyone else at failing to help pitch in. Everybody's pretty busy. Also, there's a definite tendency for skilled developers to be, well, skilled *developers*. Perhaps there are some alternate ways to help this process go faster? I wonder if it would be easier for people to discuss a particular topic with you on a phone call? Hopefully providing enough information for you to transform into flowery prose and lucid illustrations? If we want, we could make this a conference call (so interested parties could join). I don't think this technique can work for all docs. We can't expect you to write everything. However, it might help kickstart the process in some critical sections... --kevan
[jira] Commented: (GERONIMO-3786) Command deploy.bat/sh failed to start in the exported server
[ https://issues.apache.org/jira/browse/GERONIMO-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562590#action_12562590 ] David Jencks commented on GERONIMO-3786: Try also including the geronimo-boilerplate-minimal config. > Command deploy.bat/sh failed to start in the exported server > > > Key: GERONIMO-3786 > URL: https://issues.apache.org/jira/browse/GERONIMO-3786 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1 >Reporter: YunFeng Ma > Fix For: 2.1 > > > In the exported server, command deploy.bat/sh failed to start with error: > H:\gt2.1\var\temp\--bin\-\bin>deploy --user system --password manager > list-modules > Using GERONIMO_BASE: H:\gt2.1\var\temp\--bin\- > Using GERONIMO_HOME: H:\gt2.1\var\temp\--bin\- > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:C:\Program Files\IBM\Java50\jre > 09:44:04,171 ERROR [GBeanInstanceState] Error while starting; GBean is now in > th > e FAILED state: > abstractName="org.apache.geronimo.framework/online-deployer/2.1- > SNAPSHOT/car?configurationName=org.apache.geronimo.framework/online-deployer/2.1 > -SNAPSHOT/car" > org.apache.geronimo.kernel.repository.MissingDependencyException: Missing > depend > ency: org.apache.geronimo.framework/geronimo-deploy-jsr88/2.1-SNAPSHOT/jar > at > org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(Confi > gurationResolver.java:113) > at > org.apache.geronimo.kernel.config.Configuration.buildClassPath(Config > uration.java:405) > at > org.apache.geronimo.kernel.config.Configuration.createConfigurationCl > asssLoader(Configuration.java:322) > at > org.apache.geronimo.kernel.config.Configuration.(Configuration. > java:267) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct > orAccessorImpl.java:67) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC > onstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:521) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI > nstance.java:948) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart > (GBeanInstanceState.java:268) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta > nceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j > ava:541) > at > org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.j > ava:361) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf > iguration(ConfigurationUtil.java:195) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf > iguration(ConfigurationUtil.java:159) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBoo > tConfiguration(MainConfigurationBootstrapper.java:84) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain > (MainConfigurationBootstrapper.java:57) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma > inConfigurationBootstrapper.java:38) > at > org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) > at > org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31 > ) > java.lang.IllegalStateException: GBean is not running: > org.apache.geronimo.frame > work/online-deployer/2.1-SNAPSHOT/car?configurationName=org.apache.geronimo.fram > ework/online-deployer/2.1-SNAPSHOT/car > at > org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.jav > a:304) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf > iguration(ConfigurationUtil.java:197) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf > iguration(ConfigurationUtil.java:159) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBoo > tConfiguration(MainConfigurationBootstrapper.java:84) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain > (MainConfigurationBootstrapper.java:57) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma > inConfigurationBootstrapper.java:38) > at > org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) > at > org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31 > ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the
[jira] Commented: (GERONIMO-3785) No "etc" folder in the exported server
[ https://issues.apache.org/jira/browse/GERONIMO-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562588#action_12562588 ] David Jencks commented on GERONIMO-3785: I think you didn't include the geronimo-boilerplate-minimal configuration. You have to include that or the server will be missing various required bits such as bin, lib, and etc. I am reluctant to make it a dependency of anything else because it doesn't actually have a classloader so it would just confuse the classloader hierarchy which is already far too hard to understand. Also there is nothing preventing you from replacing it with some other boilerplate. I think we need some kind of instructions about this. > No "etc" folder in the exported server > -- > > Key: GERONIMO-3785 > URL: https://issues.apache.org/jira/browse/GERONIMO-3785 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1 >Reporter: YunFeng Ma > Fix For: 2.1 > > > There is no "etc" folder in the exported server via admin console, then gsh > in the exported server fails to start with error: > H:\gt2.1\var\temp\--bin\-\bin>gsh > java.io.FileNotFoundException: > H:\gt2.1\var\temp\--bin\-\etc\gsh-classworlds.conf (can not find the > specified path。) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:135) > at java.io.FileInputStream.(FileInputStream.java:95) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La > uncher.java:385) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: > 351) > at > org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] 2.0: Failed for Revision: 615126
Geronimo Revision: 615126 built with tests included
See the full build-0200.log file at
http://geronimo.apache.org/maven/server/binaries/2.0/20080125/build-0200.log
See the unit test reports at
http://geronimo.apache.org/maven/server/binaries/2.0/20080125/unit-test-reports
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-jdbc/1.0.0/openjpa-jdbc-1.0.0.jar
1006K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-kernel-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-kernel/1.0.0/openjpa-kernel-1.0.0.jar
1098K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-jdbc-5-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-jdbc-5/1.0.0/openjpa-jdbc-5-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-jdbc-5/1.0.0/openjpa-jdbc-5-1.0.0.jar
17K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openejb/jars/openejb-axis-3.0-beta-1.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openejb/openejb-axis/3.0-beta-1/openejb-axis-3.0-beta-1.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-axis/3.0-beta-1/openejb-axis-3.0-beta-1.jar
18K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-lib-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-lib/1.0.0/openjpa-lib-1.0.0.jar
424K downloaded
Downloading:
http://download.java.net/maven/1//org.apache.openjpa/jars/openjpa-kernel-5-1.0.0.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openjpa/openjpa-kernel-5/1.0.0/openjpa-kernel-5-1.0.0.jar
28K downloaded
Downloading:
http://download.java.net/maven/1//commons-pool/jars/commons-pool-1.3.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository//commons-pool/commons-pool/1.3/commons-pool-1.3.jar
Downloading:
http://repo1.maven.org/maven2/commons-pool/commons-pool/1.3/commons-pool-1.3.jar
60K downloaded
[INFO] [compiler:compile]
[INFO] Compiling 20 source files to
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 8 source files to
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.axis.AxisWebServiceContainerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.976 sec
Results :
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/geronimo-axis-2.0.3-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-axis-2.0.3-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/2.0/modules/geronimo-axis/target/geronimo-axis-2.0.3-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/modules/geronimo-axis/2.0.3-SNAPSHOT/geronimo-axis-2.0.3-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo :: Deploy :: Common Config
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/geronimo/geronimo/2.0/modules/geronimo-deploy-config/target/classes/META-INF
[INFO] Copying 2 files to
/home/geronimo/geronimo/2.0/modules/geronimo-deploy-config/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://download.java.net/maven/1//org.apache.geronimo.specs/poms/geronimo-javaee-deployment_1.1MR3_spec-1.0.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-javaee-deployment_1.1MR3_spec/1.0/geronimo-javaee-deployment_1.1MR3_spec-1.0.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-javaee-deployment_1.1MR3_spec/1.0/geronimo-javaee-deployment_1.1MR3_spec-1.0.pom
1K downloaded
Re: DBWizard needs testing
I just tested DB2 and it seems to work. Cheers! Hernan David Jencks wrote: I discovered a lot of configuration for the db wizard got left behind in 2.0.2, apparently due to confusion over splitting up the console. I tried to bring it forward into trunk but this could definitely use some checking. Please see if db2, oracle, ,mysql, and postgres dbpools can be set up using the correct tranql db-specific wrappers. thanks david jencks
Re: Geronimo v2.1 documentation
Guys, I've been trying to get your attention around Geronimo 2.1 documentation since October last year. Apache Geronimo is as good as you can communicate it to the users. How do you expect the users to know all the beeps and whistles? Not a best way to tell the users HOW TO do things in Geronimo than by having a good documentation. How much of your time it would actually take to write up a page describing a component or module and how to use it? It's you writing the code, why not you writing about that code and how to use it!? There are tons of questions on the user@ and dev@ lists about how to perform basic (and some times not so basic) tasks and configurations, we get these all the time. This is a clear sign that we need to improve the way we document the things. For 2.1 the situation is even worse, we pretty much don't have any documentation and we can't continue developing documentation the way we've been doing in the past. The way it looks now, Geronimo 2.1 won't have supporting documentation. Let's discuss here what areas need to be covered and who can work on documenting them. It is your turn now. Cheers! Hernan Kevan Miller wrote: On Jan 10, 2008, at 5:14 PM, Hernan Cunico wrote: Hi All, some time ago I started to put together some topics for Geronimo v2.1 documentation. I tried to focus on the biggest new things we are offering now, topics we didn't have before and now we need to start from scratch. The Geronimo v2.1 documentation space is already available here http://cwiki.apache.org/GMOxDOC21/documentation.html The initial TOC includes: * Configuration changes * Deployment ** Deployment plan creator * Geronimo Administration Console enhancements * GShell * Monitoring * Pluggable console * Plugin infrastructure enhancements * RELEASE-NOTES-2.1.TXT * Sample applications * Security * Tooling * What's new? Each of these pages already contain a few lines with some initial thoughts. Need your input for adding topics to this list as well as developing them. There might be things we already had in 2.0x but we didn't cover it in the doc, pls need your comments on that as well. I think I'm finish covering *Deployment plan creator*, will do a refresh later on as new code gets in. I also created this "place holder" http://cwiki.apache.org/GMOxPMGT/geronimo-v21-list-of-functions-status.html under *Apache Geronimo Project Management* on the wiki so we can keep track there the features we have ready for prime time and those that are not so ready ;-) I could definitively use that info to build up a new set of docs, would also help users to see where we are at. Hernan, Thanks for this. Time to start pulling these docs together to prepare for release. It can't all be generated by Hernan. We'll need to chip in... --kevan
[jira] Updated: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire updated GERONIMO-3757: --- Attachment: Geronimo-3757-trunk.patch In order to be added to Geronimo, this really needs to be based on the trunk build. Here's a partial merge of the patch into the current trunk. I've made all of the changes except for the .jsp updates. The trunk jsps have changed a bit from the patch version, and I'm afraid I'm not jsp literate enough to fix up those updates. > KeyStore type can't be changed > -- > > Key: GERONIMO-3757 > URL: https://issues.apache.org/jira/browse/GERONIMO-3757 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.0.2, 2.0.x, 2.1 >Reporter: Vasily Zakharov > Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch, > Geronimo-3757.patch, GERONIMO-3757.patch > > > For now (r612905), Geronimo is hardcoded to use JKS keystore type, which > prevents Geronimo from running on Harmony or other JDKs that have no JKS > implementation: > org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: > KeyStore tempKeystore = KeyStore.getInstance(JKS); > org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: > KeyStore keystore = > KeyStore.getInstance(FileKeystoreInstance.JKS); > To workaround this issue, one can change JKS to KeyStore.getDefaultType() > (this returns "BKS" for Harmony) or particular other keystore type, but this > requires source recompilation. Replacing > var/security/keystores/geronimo-default with the proper keystore type file is > not a problem. > A proper solution seems to apply the fix above to use the JDK-default > keystore type, and provide FileKeystoreInstance with an additional > configuration option, keystoreType, that would allow to change the keystore > type through config.xml without recompilation, like this: > > > PKCS12 > name="keystorePath">var/security/keystores/geronimo-pkcs12 > > > This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Offline Deployer leaving behind temporary files
I have changed DeploymentUtil.toTempFile(URL url) and
DeploymentUtil.readAll(URL
url) to use JarFile.getInputStream() instead of URL.openStream() when the
protocol is "jar". But, the other code the uses URL.openStream() still
leaves locks on the jar files which prevent immediate deletion of temp
files. The idea that I have is to change DeploymentUtil.createJarURL() such
that when the URL is for a file inside a jar file, rewrite the content to a
temp file and return the URL to that file.
The code will look something like the following:
String urlString = "jar:" + new File(jarFile.getName()).toURL()
+ "!/" + path;
if(jarUrlRewrite) {
// To prevent the lockout of archive, instead of returning a
jar url, write the content to a
// temp file and return the url of that file.
File tempFile = null;
try {
tempFile = toTempFile(new URL(urlString));
} catch (IOException e) {
// The JarEntry does not exist!
// Return url of a file that does not exist.
try {
tempFile = createTempFile();
tempFile.delete();
} catch (IOException ignored) {
}
}
return tempFile.toURL();
} else {
return new URL(urlString);
}
And the jarUrlRewrite value (false by default, which means no change from
current behavior) can be controlled by a system property "
org.apache.geronimo.deployment.util.DeploymentUtil.jarUrlRewrite" which the
users can set either using GERONIMO_OPTS environment variable or by using
the SystemProperties GBean.
When jarUrlRewrite is true, more temporary files are created, but the
Deployer will be able to delete the temporary files immediately and it won't
be needing to use DeployerReaper. On the other hand, each temp file created
will also be calling deleteOnExit() which may be holding on to 1K of memory
until the JVM terminates (if I recall correctly). Since DeployerReaper is
doing a fairly good job in case of online deployement, I suggest we set
jarUrlRewrite system property to true for offline-deployer and let users
decide what it should be for online deployer.
Comments? Suggestions? Anything I am missing.
++Vamsi
On Jan 24, 2008 12:13 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:
> I have found the culprit. It is the URLs that we use to read content from
> an archive, for e.g., META-INF/application.xml from an ear file. The
> deployer is creating a JarFile and closing the JarFile after the deployment
> operation is completed. JarFile.close() closes all the InputStreams
> obtained from the JarFile and releases any locks.
>
> For e.g., in EARConfigBuilder.getEarPlan(), we have code like the
> following:
>
> URL applicationXmlUrl = DeploymentUtil.createJarURL(earFile,
> "META-INF/application.xml");
> specDD = DeploymentUtil.readAll (applicationXmlUrl);
>
> After this code is executed the earFile is locked until the JVM
> terminates. If you replace the above with something similar to
>
> InputStream inp = earFile.getInputStream(earFile.getJarEntry
> ("META-INF/application.xml"));
> BufferedReader br = new BufferedReader(new
> InputStreamReader(inp));
> String line;
> while((line = br.readLine()) != null) {
> specDD += line;
> }
>
> the earFile is no longer locked once earFile.close() is called and can be
> deleted anytime. This is what is observed on Win XP.
>
> ++Vamsi
>
>
> On Jan 23, 2008 8:52 PM, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
> >
> > On Jan 23, 2008, at 10:02 AM, Vamsavardhana Reddy wrote:
> >
> > > Kevan,
> > >
> > > I am testing this with an ear file. So, the EARConfiBuilder should
> > > be reading this file. I guess it is the same with other builders as
> > > well. The JarFileClassLoader has the following comment
> > >
> > > * Note: This implementation currently does not work reliably on
> > > windows, since the jar URL handler included with the Sun JavaVM
> > > * holds a read lock on the JarFile, and this lock is not released
> > > when the jar url is dereferenced. To fix this a
> > > * replacement for the jar url handler must be written.
> > >
> > > BTW, I am running G 2.0.3-SNAPSHOT on Win XP.
> >
> > I wouldn't trust that comment. Dain's commit was addressing this very
> > problem (at least within the server runtime:
> > http://svn.apache.org/viewvc?view=rev&revision=399522
> >
> > You need to check to see what type of ClassLoader is being used. If
> > it's not JarFileClassLoader, then we understand the problem. If it is
> > JarFileClassLoader, then maybe we aren't calling destroy. If we doing
> > all of these things, then obviously I'm wrong again... ;-)
> >
> > --kevan
> >
>
>
[jira] Assigned: (GSHELL-23) Command pipe-lines
[
https://issues.apache.org/jira/browse/GSHELL-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik B. Craig reassigned GSHELL-23:
---
Assignee: Erik B. Craig
> Command pipe-lines
> --
>
> Key: GSHELL-23
> URL: https://issues.apache.org/jira/browse/GSHELL-23
> Project: GShell
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: Core, Parser
>Reporter: Jason Dillon
>Assignee: Erik B. Craig
> Fix For: 1.0-alpha-2
>
>
> Add support for piping the output of one command into another, as in:
> {noformat}
> echo "hi" | cat > /tmp/foo
> {noformat}
> This should write "hi" to the /tmp/foo file.
> Follow zsh style, allowing |& to concat both stdout+stderr
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3769) artifactory 1.2.2 deployment is failing on 2.1
[ https://issues.apache.org/jira/browse/GERONIMO-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562532#action_12562532 ] Joe Bohn commented on GERONIMO-3769: Kevan suggested that this might be caused by plexus and he was correct. Updating the deployment plan as follows allows the deploy to succeed and artifactory to start. http://geronimo.apache.org/xml/ns/j2ee/web-1.1";> http://geronimo.apache.org/xml/ns/deployment-1.1";> com.joe artifactory 1.2.2 war org.codehaus.plexus /artifactory artifactory.home=/Users/bohn/downloads/artifactory-1.2.5 > artifactory 1.2.2 deployment is failing on 2.1 > -- > > Key: GERONIMO-3769 > URL: https://issues.apache.org/jira/browse/GERONIMO-3769 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.1 >Reporter: Kevan Miller >Assignee: Joe Bohn > Fix For: 2.1 > > > A deploy of artifactory is failing on 2.1. Same deploy works on 2.0.2. I'm > seeing the following exceptions on the server: > Second exception is most significant, I think: > 2008-01-20 12:42:22,616 [ERROR] 0.0].[/artifactory] - Exception sending > context initialized event to listener instance of class > org.artifactory.webapp.servlet.ArtifactoryContextConfigurer > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'maven' defined in ServletContext resource > [/WEB-INF/applicationContext.xml]: Instantiation of bean failed; nested > exception is org.springframework.beans.BeanInstantiationException: Could not > instantiate bean class [org.artifactory.maven.Maven]: Constructor threw > exception; nested exception is java.lang.NoClassDefFoundError: > org/codehaus/classworlds/NoSuchRealmException > Caused by: > org.springframework.beans.BeanInstantiationException: Could not instantiate > bean class [org.artifactory.maven.Maven]: Constructor threw exception; nested > exception is java.lang.NoClassDefFoundError: > org/codehaus/classworlds/NoSuchRealmException > Caused by: > java.lang.NoClassDefFoundError: org/codehaus/classworlds/NoSuchRealmException > at org.codehaus.plexus.embed.Embedder.(Embedder.java:62) > at > org.apache.maven.embedder.MavenEmbedder.start(MavenEmbedder.java:582) > at org.artifactory.maven.Maven.(Maven.java:99) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:85) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:170) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:773) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:716) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:386) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:279) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:360) > at > org.artifactory.webapp.servlet.ArtifactoryContextConfigurer.contextInitialized(ArtifactoryContextConfigurer.java:45) > at > org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3826) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4327) > at > org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:60) > at > org.apache.geronimo.tomcat.GeronimoStandardConte
Re: svn commit: r614754 - in /geronimo/server/trunk: ./ repository/org/apache/tomcat/ repository/org/apache/tomcat/catalina/6.0.14-G614585/ repository/org/apache/tomcat/jasper/6.0.14-G614585/
Hey Joe, I tried to make a single patch file, but when I tried to test it - it didn't work. I'm not sure why. I have gone ahead and committed the other patch file. I could rename them so that there would be two patches with the same revision in them though. Jay Joe Bohn wrote: Jay, Did you miss the new patch file when you checked this in? Actually, would it be possible to create just one patch file that includes all the changes in your tomcat source image and check that in? That way we only need to apply one patch to recreate the image and all of the revision #s would be consistent (and we could delete all of the 604245 items). Thanks, Joe [EMAIL PROTECTED] wrote: Author: jaydm Date: Wed Jan 23 16:31:35 2008 New Revision: 614754 URL: http://svn.apache.org/viewvc?rev=614754&view=rev Log: GERONIMO-3451 - Use a new snapshot of tomcat Includes security fix for webdav as well as 'restricted listeners' message Added: geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT geronimo/server/trunk/repository/org/apache/tomcat/catalina/6.0.14-G614585/ geronimo/server/trunk/repository/org/apache/tomcat/catalina/6.0.14-G614585/catalina-6.0.14-G614585.jar (with props) geronimo/server/trunk/repository/org/apache/tomcat/jasper/6.0.14-G614585/ geronimo/server/trunk/repository/org/apache/tomcat/jasper/6.0.14-G614585/jasper-6.0.14-G614585.jar (with props) Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=614754&r1=614753&r2=614754&view=diff == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Wed Jan 23 16:31:35 2008 @@ -984,7 +984,7 @@ org.apache.tomcat jasper -6.0.14-G604245 +6.0.14-G614585 @@ -1014,7 +1014,7 @@ org.apache.tomcat catalina -6.0.14-G604245 +6.0.14-G614585 @@ -1950,7 +1950,7 @@ org.apache.tomcat jasper -6.0.14-G604245 +6.0.14-G614585 Added: geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT URL: http://svn.apache.org/viewvc/geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT?rev=614754&view=auto == --- geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT (added) +++ geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT Wed Jan 23 16:31:35 2008 @@ -0,0 +1,87 @@ +Private Build of Tomcat for Geronimo. + +How to build Tomcat 6_0_14 with modifications for Geronimo: + +Checkout tomcat 6.0.14 + svn co https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14 tomcat_6_0_14 + +svn info for Tomcat image: +Path: . +URL: https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14 +Repository Root: https://svn.apache.org/repos/asf +Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 +Revision: 604245 +Node Kind: directory +Schedule: normal +Last Changed Author: remm +Last Changed Rev: 557842 +Last Changed Date: 2007-07-19 21:43:38 -0400 (Thu, 19 Jul 2007) +Properties Last Updated: 2007-12-07 14:29:52 -0500 (Fri, 07 Dec 2007) + + +Apply the custom patch for Geronimo Annotation changes, Webdav fix, and build fix. + cd tomcat_6_0_14 + patch -p0 -u < tomcat_6_0_14-G604245.patch (checked in as a peer to this file) + - Respond "y" to the 3 prompts "Reversed (or previously applied) patch detected! Assume -R? [n]" + +Force delete these three files + svn delete java/org/apache/jasper/runtime/AnnotationHelper.java --force + svn delete java/org/apache/AnnotationProcessor.java --force + svn delete java/org/apache/catalina/util/DefaultAnnotationProcessor.java --force + +Apply the 'restricted listeners' patch provided by djencks (already merged into Tomcat trunk) + patch -p0 -u < tomcat_6_0_14-G614585.patch (cheked in as a peer to this file) + +Build tomcat + cd tomcat_6_0_14 + Per tomcat build instructions install ant-1.6.5 or later and set ANT_HOME as well as add ant/bin to PATH + You must run as the super user for the first build that downloads more ant & eclipse artifacts + ant download - to setup build for tomcat + Exit super user + ant - to build tomcat artifacts + +Copy to appropriate jars and rename into geronimo/repository + cd tomcat_6_0_14 + cp output/build/lib/catalina.jar /repository/org/apache/tomcat/catalina/6.0.1
[jira] Updated: (GERONIMO-3787) Deployment on Minimal Assemblies fails complaining of a missing yoko dependency
[ https://issues.apache.org/jira/browse/GERONIMO-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3787: --- Component/s: deployment > Deployment on Minimal Assemblies fails complaining of a missing yoko > dependency > --- > > Key: GERONIMO-3787 > URL: https://issues.apache.org/jira/browse/GERONIMO-3787 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1 >Reporter: Joe Bohn > > I started the tomcat minimal assembly and attempted to deploy a simple web > application. I hit the following error: > tetra:~/g-images/trunk/geronimo-tomcat6-minimal-2.1-SNAPSHOT/bin bohn$ > ./deploy.sh deploy ~/ServerApplications/snoop.war > Using GERONIMO_BASE: > /Users/bohn/g-images/trunk/geronimo-tomcat6-minimal-2.1-SNAPSHOT > Using GERONIMO_HOME: > /Users/bohn/g-images/trunk/geronimo-tomcat6-minimal-2.1-SNAPSHOT > Using GERONIMO_TMPDIR: var/temp > Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/Home > org.apache.geronimo.kernel.config.LifecycleException: load of > default/snoop/1201271106727/war failed > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:299) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:280) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:255) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) > at > org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) > at > com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) > at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) > at > javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410) > at > javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) > at > javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247) > at java.security.AccessController.doPrivileged(Native Method) > at > javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1350) > at > javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) > at sun.rmi.transport.Transport$1.run(Transport.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:149) > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) > at java.lang.Thread
[jira] Created: (GERONIMO-3787) Deployment on Minimal Assemblies fails complaining of a missing yoko dependency
Deployment on Minimal Assemblies fails complaining of a missing yoko dependency --- Key: GERONIMO-3787 URL: https://issues.apache.org/jira/browse/GERONIMO-3787 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1 Reporter: Joe Bohn I started the tomcat minimal assembly and attempted to deploy a simple web application. I hit the following error: tetra:~/g-images/trunk/geronimo-tomcat6-minimal-2.1-SNAPSHOT/bin bohn$ ./deploy.sh deploy ~/ServerApplications/snoop.war Using GERONIMO_BASE: /Users/bohn/g-images/trunk/geronimo-tomcat6-minimal-2.1-SNAPSHOT Using GERONIMO_HOME: /Users/bohn/g-images/trunk/geronimo-tomcat6-minimal-2.1-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/Home org.apache.geronimo.kernel.config.LifecycleException: load of default/snoop/1201271106727/war failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:299) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:280) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:255) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1350) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:613) Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.configs/j2ee-corba-yoko//car at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:111) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:104)
[jira] Resolved: (GERONIMO-3738) Upgrade to Jetty 6.1.7
[ https://issues.apache.org/jira/browse/GERONIMO-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn resolved GERONIMO-3738. > Upgrade to Jetty 6.1.7 > -- > > Key: GERONIMO-3738 > URL: https://issues.apache.org/jira/browse/GERONIMO-3738 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Jetty >Reporter: Joe Bohn >Assignee: Joe Bohn > Fix For: 2.1 > > > We need to pick up the latest available version of Jetty to fix a security > issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562500#action_12562500 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Completed: At revision: 615225 in branches\2.0 and trunk (2.1) o When url.openStream() is used to read an individual file from an archive i.e. when protocol is "jar", the archive file is locked even after the stream is closed and it prevents immediate deletion of temporary files created during the deployment process. This can be avoided by using JarFile.getInputStream() instead. > DeployerReaper fails to cleanup the temp directories left behind by deployer > > > Key: GERONIMO-3764 > URL: https://issues.apache.org/jira/browse/GERONIMO-3764 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 >Reporter: Vamsavardhana Reddy >Assignee: Vamsavardhana Reddy > Fix For: 2.0.x, 2.1 > > Attachments: GERONIMO-3764-2.0.patch, > GERONIMO-3764-deploymentutil.patch > > > Deployer creates a temporary directory and cleans up the directory once > deployment operation is completed. When deletion of a temp dir fails, the > deployer leaves it upto DeployerReaper to cleanup the directory later on. > DeployerReaper is failing to cleanup these directories as only the dir name > (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Hang on shutdown on Harmony
Rick, Thanks for the detailed analysys, I'll investigate it. Vasily -Original Message- From: Rick McGuire [mailto:[EMAIL PROTECTED] Sent: Friday, January 25, 2008 1:56 PM To: dev@geronimo.apache.org Subject: Re: Hang on shutdown on Harmony I'm not sure I understand how this stack trace is occurring. Is it possible that there's an error in Harmony exception handling? Here's what's supposed to be happening here. At ORB shutdown, the socket that acceptor has issued the accept() call is closed. That's line 111 in Acceptor_impl. This should cause an I/O exception, which is what the stack trace is showing. However, there's a catch for that IOException at line 125 in Acceptor_impl that should be turning that into a org.omg.CORBA.COMM_FAILURE exception. That exception in turn should be caught GIOPServerStartedThreaded.starterRun(), which detects at that point that this is a shutdown situation and terminates the run loop on the thread. The loop that Jarek mentioned in ORBControl is waiting for the server threads to finish shutting down, but if that IOException is not getting trapped properly, this thread goes away without cleanuing up its state. I am a little puzzled about how completeServerShutdown can get caught in a loop, since it appears to have a cap on how many times it will go around that loop. Rick Zakharov, Vasily M wrote: > Hi, all, > > I observe the following stack trace when shutting down Geronimo > (branches/2.0) running on Harmony, and then Geronimo stops responding > forever. > Otherwise, Geronimo runs pretty well on Harmony, see [1], details are at > [2]. > > What is interesting is exactly similar stack and hang are observed when > running org.apache.geronimo.yoko.TSSConfigEditorTest test on Harmony, I > already wrote about it, see [3]. > > For now I couldn't find out the cause for this behavior, so if someone > has any ideas on where to look, I'd be grateful. Thanks! > > [] received stop signal > Jan 24, 2008 5:34:18 PM org.apache.yoko.orb.OCI.IIOP.Acceptor_impl > accept > SEVERE: Failure accepting connection for > host=ecwm0vmzakhar/192.168.16.2, port=2001 > Throwable occurred: java.io.IOException: Connection was closed > at > org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocke > tImpl.java:760) > at > org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSo > cketImpl.java:438) > at > org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept(SSLServ > erSocketImpl.java:256) > at > org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept(Acceptor_impl.java:111 > ) > at > org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun(GIOPServerSt > arterThreaded.java:195) > at > org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run(GIOPS > erverStarterThreaded.java:34) > > [1] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57921 > [2] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony > [3] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57396 > > Vasily Zakharov, > Intel ESSD > > > > --- > > > Closed Joint Stock Company Intel A/O > Registered legal address: 125252, Moscow, Russian Federation, > Chapayevsky Per, 14. > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[jira] Commented: (GERONIMO-3761) Add data collection and instrumentation to the AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562459#action_12562459 ] Rick McGuire commented on GERONIMO-3761: Committed revision 615192. Thanks for the update Sangjin. > Add data collection and instrumentation to the AsyncHttpClient > -- > > Key: GERONIMO-3761 > URL: https://issues.apache.org/jira/browse/GERONIMO-3761 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: AsyncHttpClient >Reporter: Rick McGuire > Attachments: GERONIMO-3761-v2.patch, GERONIMO-3761-v3.patch, > GERONIMO-3761-v4.patch, GERONIMO-3761.patch, TimeMonitor.java > > > There's been some discussion on the dev list about adding some > instrumentation to the AsyncHttpClient. This is for tracking these > additions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Hang on shutdown on Harmony
I'm not sure I understand how this stack trace is occurring. Is it possible that there's an error in Harmony exception handling? Here's what's supposed to be happening here. At ORB shutdown, the socket that acceptor has issued the accept() call is closed. That's line 111 in Acceptor_impl. This should cause an I/O exception, which is what the stack trace is showing. However, there's a catch for that IOException at line 125 in Acceptor_impl that should be turning that into a org.omg.CORBA.COMM_FAILURE exception. That exception in turn should be caught GIOPServerStartedThreaded.starterRun(), which detects at that point that this is a shutdown situation and terminates the run loop on the thread. The loop that Jarek mentioned in ORBControl is waiting for the server threads to finish shutting down, but if that IOException is not getting trapped properly, this thread goes away without cleanuing up its state. I am a little puzzled about how completeServerShutdown can get caught in a loop, since it appears to have a cap on how many times it will go around that loop. Rick Zakharov, Vasily M wrote: Hi, all, I observe the following stack trace when shutting down Geronimo (branches/2.0) running on Harmony, and then Geronimo stops responding forever. Otherwise, Geronimo runs pretty well on Harmony, see [1], details are at [2]. What is interesting is exactly similar stack and hang are observed when running org.apache.geronimo.yoko.TSSConfigEditorTest test on Harmony, I already wrote about it, see [3]. For now I couldn't find out the cause for this behavior, so if someone has any ideas on where to look, I'd be grateful. Thanks! [] received stop signal Jan 24, 2008 5:34:18 PM org.apache.yoko.orb.OCI.IIOP.Acceptor_impl accept SEVERE: Failure accepting connection for host=ecwm0vmzakhar/192.168.16.2, port=2001 Throwable occurred: java.io.IOException: Connection was closed at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocke tImpl.java:760) at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSo cketImpl.java:438) at org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept(SSLServ erSocketImpl.java:256) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept(Acceptor_impl.java:111 ) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun(GIOPServerSt arterThreaded.java:195) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run(GIOPS erverStarterThreaded.java:34) [1] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57921 [2] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony [3] http://thread.gmane.org/gmane.comp.java.geronimo.devel/57396 Vasily Zakharov, Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[BUILD] 2.1: Failed for Revision: 615137
Geronimo Revision: 615137 built with tests included See the full build-0300.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080125/build-0300.log Download the binaries from http://geronimo.apache.org/maven/server/binaries/trunk/20080125 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 30 minutes 51 seconds [INFO] Finished at: Fri Jan 25 03:38:15 EST 2008 [INFO] Final Memory: 313M/600M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://geronimo.apache.org/maven/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080125/logs-0300-tomcat/test.log Assembly: jetty = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080125/logs-0300-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 64.508 sec <<< FAILURE!
