[jira] Created: (GERONIMO-1875) More work to port little-g to 1.1
More work to port little-g to 1.1 - Key: GERONIMO-1875 URL: http://issues.apache.org/jira/browse/GERONIMO-1875 Project: Geronimo Type: Bug Security: public (Regular issues) Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 This issue will be used to hold more patches for little-g modularization of geronimo 1.1. Some pieces: - additional plans for new configs - turning single valued references to ejb builder, axis builder, client builder, connector builder etc into something that will work. The problem is that all these builders can't be in the ancestor tree of j2ee-deployer, or we'd always be pulling them into the server. Therefore they need to be collection valued references. We can make a collection wrapper that returns a single element or null, or objects to the presence of more than one element, and use this to hold many of these 0..1 valued references. Both EarConfigBuilder and ClientModuleBuilder need this modification. - modify existing plans to remove gbeans now in the new plans. Be sure to update the defaultEnvironments as appropriate. - modify the assemblies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1874) synthetic ears should allow use of modules outside the g repository
synthetic ears should allow use of modules outside the g repository --- Key: GERONIMO-1874 URL: http://issues.apache.org/jira/browse/GERONIMO-1874 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 Currently synthetic ears or external modules in an ear only accept external artifacts that are in the geronimo repo, identified by an Artifact. We should also allow specification of a path that is not in the repository. Perhaps this could be resolved using ServerInfo if the path is not absolute. I think that changing the meaning of the current to actually mean a path and introducing a new element such as perhaps with all the parts to indicate an artifact in the repo would be a good idea. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SSO in Tomcat
hi Jeff, Thanks for the reply. I have tried this but am not able to get it to work. My plan looks like this for test/web/1 and test/web/2. Both apps use same Realm and Valve. http://geronimo.apache.org/xml/ns/web"; xmlns:sec="http://geronimo.apache.org/xml/ns/security"; configId="test/web/2"> /web2 false TomcatJAASRealm SSOValve geronimo-properties-realm org.apache.catalina.authenticator.SingleSignOn Regards Krish On 4/20/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > Yes, you should be able to do this. Look at the geronimo-web.xml for > the Tomcat descriptor. There is a xml tag that lets you reference a > valve in the geronimo-web.xml. > > Krishnakumar B wrote: > > Hi, > > > > I have a ? related to SSO in tomcat. > > > > I can build geronimo configuring a SSO Valve and use this in web > > applications deployed in Tomcat. This works. > > > > If i deploy a new Valve along with a web application this does not work. > > > > Can valves be deployed at application level so that it works for some > > web applications? I dont need to have a pre-built Valve enabled with > > the Server if this works. > > > > Regards > > Krish >
Re: SSO in Tomcat
Yes, you should be able to do this. Look at the geronimo-web.xml for the Tomcat descriptor. There is a xml tag that lets you reference a valve in the geronimo-web.xml. Krishnakumar B wrote: > Hi, > > I have a ? related to SSO in tomcat. > > I can build geronimo configuring a SSO Valve and use this in web > applications deployed in Tomcat. This works. > > If i deploy a new Valve along with a web application this does not work. > > Can valves be deployed at application level so that it works for some > web applications? I dont need to have a pre-built Valve enabled with > the Server if this works. > > Regards > Krish
SSO in Tomcat
Hi, I have a ? related to SSO in tomcat. I can build geronimo configuring a SSO Valve and use this in web applications deployed in Tomcat. This works. If i deploy a new Valve along with a web application this does not work. Can valves be deployed at application level so that it works for some web applications? I dont need to have a pre-built Valve enabled with the Server if this works. Regards Krish
Re: [WARNING] - Mac users
On 4/19/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> Yes...and before anyone asks...
>
> The JVM/JAVA_HOME/PATh was set to the 1.4 JVM. The OS seems to get
> mixed up about the path libs.
You beat me to it ;-).
Is there any way that we can massage the CLASSPATH as a temporary workaround?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: [WARNING] - Mac users
Yes...and before anyone asks... The JVM/JAVA_HOME/PATh was set to the 1.4 JVM. The OS seems to get mixed up about the path libs. Jeff Jeff Genender wrote: > The last Java 5 update from Apple breaks the Geronimo 1.1 build for Mac > OS X users. > > Symptoms (when tests are on) include getting the following error: > > Unable to obtain goal [multiproject:install-callback] -- > /Users/powerbook/.maven/cache/maven-test-plugin-1.7/plugin.jelly:134:-1: > java.lang.NullPointerException > > or with tests off: > > The failure will occur in the J2EE Schema module with the following error: > > Unable to obtain goal [multiproject:install-callback] -- > /Users/powerbook/.maven/cache/xmlbeans-maven-plugin-2.0.0-beta1/plugin.jelly:83:-1: > javax/xml/namespace/QName (Unsupported > major.minor version 49.0) > > This problem was corroborated by myself, Dain, David Blevins, and Alan > Cabrera. > > Currently there is no work around, but we are investigating possible fixes. > > You are recommended to *NOT* update your Apple JVM at this time. > > Jeff >
[WARNING] - Mac users
The last Java 5 update from Apple breaks the Geronimo 1.1 build for Mac OS X users. Symptoms (when tests are on) include getting the following error: Unable to obtain goal [multiproject:install-callback] -- /Users/powerbook/.maven/cache/maven-test-plugin-1.7/plugin.jelly:134:-1: java.lang.NullPointerException or with tests off: The failure will occur in the J2EE Schema module with the following error: Unable to obtain goal [multiproject:install-callback] -- /Users/powerbook/.maven/cache/xmlbeans-maven-plugin-2.0.0-beta1/plugin.jelly:83:-1: javax/xml/namespace/QName (Unsupported major.minor version 49.0) This problem was corroborated by myself, Dain, David Blevins, and Alan Cabrera. Currently there is no work around, but we are investigating possible fixes. You are recommended to *NOT* update your Apple JVM at this time. Jeff
[jira] Commented: (GERONIMO-1873) Deployment must handle dynamically-registered module builders
[ http://issues.apache.org/jira/browse/GERONIMO-1873?page=comments#action_12375248 ] David Jencks commented on GERONIMO-1873: If this requires any action someone has really broken the deployer architecture. Be sure you are not confusing a config builder, of which there can be any number, and which can decide for themselves whether they can deploy something handed to them, and the module builders that plug into the EarConfigBuilder, which are designed to support j2ee artifacts. I don't know of anything hardcoded to a particular config builder. There is certainly nothing preventing deploying a spring or servicemix config builder. > Deployment must handle dynamically-registered module builders > - > > Key: GERONIMO-1873 > URL: http://issues.apache.org/jira/browse/GERONIMO-1873 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Reporter: Aaron Mulder > Priority: Critical > Fix For: 1.1 > > Currently the deployment infrastructure does some things specific to > different module types -- like identifying the embedded deployment plan in a > xAR so it can look up the config ID, and searching for child modules of an > EAR. This is currently hardcoded to the specific set of module types > supported by Geronimo by default. It should be able to handle builders > deployed later (e.g. Spring, ServiceMix, whatever), which probably means it > needs to be able to ask something on the server-side what modules are > available, what their nested plan files are called, and what their j2eeType > would be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1872) Two meanings of META-INF/geronimo-service.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1872?page=all ] David Jencks closed GERONIMO-1872: -- Resolution: Fixed Fixed in rev 395478. This also removes versions from the constructed depedency list, see GERONIMO-1636 > Two meanings of META-INF/geronimo-service.xml > - > > Key: GERONIMO-1872 > URL: http://issues.apache.org/jira/browse/GERONIMO-1872 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.1 > > The original meaning of geronimo-service.xml files is a list of dependencies > for a jar. Recently a new meaning, of an embedded gbean plan, has been > added. This different uses should have separate names. Suggestion is to > rename the list of dependencies "geronimo-dependency.xml" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1636) Support optional version number on dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-1636?page=comments#action_12375245 ] David Jencks commented on GERONIMO-1636: In rev 395478 versions are removed from the output of the dependency plugin as well. (also generated dependency lists are now called META-INF/geronimo-dependency.xml) > Support optional version number on dependencies > --- > > Key: GERONIMO-1636 > URL: http://issues.apache.org/jira/browse/GERONIMO-1636 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: kernel > Versions: 1.0 > Reporter: Dain Sundstrom > Assignee: David Jencks > Fix For: 1.1 > > Add support for making the version number of a dependency optional. In the > case of a missing version number a pluggable strategy should choose the > actual version to load. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: We may need to rethink unversioned dependencies among server plans...
On Apr 19, 2006, at 6:27 PM, Aaron Mulder wrote: So I'm having a build problem. The root cause appears to be that my local Maven repo has both 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts. One of the server artifacts (say, j2ee-system) has a dependency on another (say, rmi-naming), and that dependency has no version. So when the packaging plugin packages j2ee-system, it asks the repository for a matching rmi-naming, and gets rmi-naming/1.2-SNAPSHOT instead of rmi-naming/1.1-SNAPSHOT I'm not sure what we can do about this. I'll think about it a bit. hmm, this appears to be working ok on my machine, maybe I don't have enough 1.2 artifacts on it. The way it's supposed to work is that the artifact resolver has a map of explicit versions to use for unversioned artifacts. This is currently etc/explicit_versions.properties for the packaging and assembly plugins. You can have entries of the form groupid/ artifactid//type=version or groupid///=version; the former are checked first. Since on my machine nothing was working when this file was missing/ incorrect, and adding entries (such as for xmlparserapis) has fixed problems, I'm inclined to think it's working properly. I did forget to bump the version number on the plugins, perhaps your problems are from an out of date plugin??? thanks david jencks Thanks, Aaron
[jira] Updated: (GERONIMO-1871) Unable to deploy Tapestry app due to classloading issue
[ http://issues.apache.org/jira/browse/GERONIMO-1871?page=all ] Bryan Noll updated GERONIMO-1871: - Priority: Critical (was: Major) Updating to critical since Tapestry does not integrate out of the box with Geronimo. > Unable to deploy Tapestry app due to classloading issue > --- > > Key: GERONIMO-1871 > URL: http://issues.apache.org/jira/browse/GERONIMO-1871 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: kernel > Versions: 1.2 > Environment: Windows XP > Reporter: Bryan Noll > Priority: Critical > > Here is the stacktrace encountered when attempting to deploy a Tapestry > application. Please scroll down to see more info after the stack trace. > org.apache.hivemind.ApplicationRuntimeException: Error: Module hivemind is > duplicated! Definition in > jar:file:/C:/tools/geronimo-1.2-SNAPSHOT/config-store/42/war/WEB-INF/lib/hivemind-1.1.jar!/META-INF/hivemodule.xml > has been ignored in favor of existing definition from > jar:file:/C:/tools/geronimo-1.2-SNAPSHOT/config-store/42/war/WEB-INF/lib/hivemind-1.1.jar!/META-INF/hivemodule.xml. > org.apache.hivemind.impl.StrictErrorHandler.error(StrictErrorHandler.java:39) > org.apache.hivemind.impl.RegistryInfrastructureConstructor.addModuleDescriptor(RegistryInfrastructureConstructor.java:202) > org.apache.hivemind.impl.RegistryBuilder.processModuleDescriptorProvider(RegistryBuilder.java:168) > org.apache.hivemind.impl.RegistryBuilder.constructRegistry(RegistryBuilder.java:143) > org.apache.tapestry.ApplicationServlet.constructRegistry(ApplicationServlet.java:253) > org.apache.tapestry.ApplicationServlet.init(ApplicationServlet.java:194) > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3915) > org.apache.catalina.core.StandardContext.start(StandardContext.java:4176) > org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:66) > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:270) > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) > org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:185) > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) > org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() > net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$7af7fb0d.addContext() > org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:416) > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) > org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke() > net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173) > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:229) > org.apache.geronimo.kernel.config.
Re: Tomcat Connector Attributes Needed
No problem...I can add em... but I need to get a reasonable build first. Matt Hogstrom wrote: > Jeff, > > I have some additional Tomcat connectotr attributes I'd like for > tweaking for 1.1. Can you add these or do you have an objection if > they're added? > > enableLookups > maxKeepAliveRequests > socketBuffer (note, there is a 'bufferSize' attribute on the Tomcat > 5.5 connector, but this is different) > useBodyEncodingForURI > > Thanks sir > > Matt
Tomcat Connector Attributes Needed
Jeff, I have some additional Tomcat connectotr attributes I'd like for tweaking for 1.1. Can you add these or do you have an objection if they're added? enableLookups maxKeepAliveRequests socketBuffer (note, there is a 'bufferSize' attribute on the Tomcat 5.5 connector, but this is different) useBodyEncodingForURI Thanks sir Matt
Re: We may need to rethink unversioned dependencies among server plans...
This is behaving as designed isn't it? I would expect the highest level version to be selected in the absence of a restriction (another dependency indicated that it required 1.1-SNAPSHOT) or a specific dependency (some dependency indicated it needed naming-1.1-SNAPSHOT). Does this sound right? Aaron Mulder wrote: So I'm having a build problem. The root cause appears to be that my local Maven repo has both 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts. One of the server artifacts (say, j2ee-system) has a dependency on another (say, rmi-naming), and that dependency has no version. So when the packaging plugin packages j2ee-system, it asks the repository for a matching rmi-naming, and gets rmi-naming/1.2-SNAPSHOT instead of rmi-naming/1.1-SNAPSHOT I'm not sure what we can do about this. I'll think about it a bit. Thanks, Aaron
We may need to rethink unversioned dependencies among server plans...
So I'm having a build problem. The root cause appears to be that my local Maven repo has both 1.1-SNAPSHOT and 1.2-SNAPSHOT artifacts. One of the server artifacts (say, j2ee-system) has a dependency on another (say, rmi-naming), and that dependency has no version. So when the packaging plugin packages j2ee-system, it asks the repository for a matching rmi-naming, and gets rmi-naming/1.2-SNAPSHOT instead of rmi-naming/1.1-SNAPSHOT I'm not sure what we can do about this. I'll think about it a bit. Thanks, Aaron
Re: Deploying Specs -- another note
Also, you'll want to kill any org.apache.geronimo.spec-*-1.0.jar files you have in your $HOME/.maven/repository as they may be the contaminated versions. -David On Apr 19, 2006, at 6:08 PM, David Blevins wrote: Seems the 1.0 jars in cvs.apache.org were getting updated. I had put them there as a convenience but it's no good if they get updated and the bad versions begin to pollute the world. To fix this, I have backed up our specs at cvs.apache.org and recreated them from scratch. You can no longer download the final 1.0 jars from cvs.apache.org. As always, those are available on ibiblio, so everyone should be fine. Our /www/cvs.apache.org/repository/org.apache.geronimo.specs directory now contains the following content: org.apache.geronimo.specs/jars org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.1- SNAPSHOT.jar org.apache.geronimo.specs/jars/geronimo-commonj_1.1_spec-1.0- SNAPSHOT.jar org.apache.geronimo.specs/jars/geronimo-corba_2.3_spec-1.1- SNAPSHOT.jar org.apache.geronimo.specs/jars/geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar org.apache.geronimo.specs/poms org.apache.geronimo.specs/poms/geronimo-javamail_1.3.1_spec-1.1- SNAPSHOT.pom org.apache.geronimo.specs/poms/geronimo-commonj_1.1_spec-1.0- SNAPSHOT.pom org.apache.geronimo.specs/poms/geronimo-corba_2.3_spec-1.1- SNAPSHOT.pom org.apache.geronimo.specs/poms/geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.pom org.apache.geronimo.specs/poms/maven-metadata-mavenOneRepository.xml org.apache.geronimo.specs/poms/specs-1.1-SNAPSHOT.pom Do not publish any 1.0 jars there. Also, please know that we do build the 1.1-SNAPSHOT specs on gbuild in our continuum install (http://ci.gbuild.org/continuum/servlet/ continuum) and those jars are rsync'ed to cvs.apache.org every hour. It's fine to deploy a SNAPSHOT spec by hand if you don't wish to wait. Thanks, David
Deploying Specs
Seems the 1.0 jars in cvs.apache.org were getting updated. I had put them there as a convenience but it's no good if they get updated and the bad versions begin to pollute the world. To fix this, I have backed up our specs at cvs.apache.org and recreated them from scratch. You can no longer download the final 1.0 jars from cvs.apache.org. As always, those are available on ibiblio, so everyone should be fine. Our /www/cvs.apache.org/repository/org.apache.geronimo.specs directory now contains the following content: org.apache.geronimo.specs/jars org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.1- SNAPSHOT.jar org.apache.geronimo.specs/jars/geronimo-commonj_1.1_spec-1.0- SNAPSHOT.jar org.apache.geronimo.specs/jars/geronimo-corba_2.3_spec-1.1-SNAPSHOT.jar org.apache.geronimo.specs/jars/geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar org.apache.geronimo.specs/poms org.apache.geronimo.specs/poms/geronimo-javamail_1.3.1_spec-1.1- SNAPSHOT.pom org.apache.geronimo.specs/poms/geronimo-commonj_1.1_spec-1.0- SNAPSHOT.pom org.apache.geronimo.specs/poms/geronimo-corba_2.3_spec-1.1-SNAPSHOT.pom org.apache.geronimo.specs/poms/geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.pom org.apache.geronimo.specs/poms/maven-metadata-mavenOneRepository.xml org.apache.geronimo.specs/poms/specs-1.1-SNAPSHOT.pom Do not publish any 1.0 jars there. Also, please know that we do build the 1.1-SNAPSHOT specs on gbuild in our continuum install (http://ci.gbuild.org/continuum/servlet/ continuum) and those jars are rsync'ed to cvs.apache.org every hour. It's fine to deploy a SNAPSHOT spec by hand if you don't wish to wait. Thanks, David
[jira] Commented: (GERONIMO-1873) Deployment must handle dynamically-registered module builders
[ http://issues.apache.org/jira/browse/GERONIMO-1873?page=comments#action_12375222 ] Aaron Mulder commented on GERONIMO-1873: See CommandSupport.loadChildren, for example > Deployment must handle dynamically-registered module builders > - > > Key: GERONIMO-1873 > URL: http://issues.apache.org/jira/browse/GERONIMO-1873 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Reporter: Aaron Mulder > Priority: Critical > Fix For: 1.1 > > Currently the deployment infrastructure does some things specific to > different module types -- like identifying the embedded deployment plan in a > xAR so it can look up the config ID, and searching for child modules of an > EAR. This is currently hardcoded to the specific set of module types > supported by Geronimo by default. It should be able to handle builders > deployed later (e.g. Spring, ServiceMix, whatever), which probably means it > needs to be able to ask something on the server-side what modules are > available, what their nested plan files are called, and what their j2eeType > would be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1873) Deployment must handle dynamically-registered module builders
Deployment must handle dynamically-registered module builders - Key: GERONIMO-1873 URL: http://issues.apache.org/jira/browse/GERONIMO-1873 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1 Currently the deployment infrastructure does some things specific to different module types -- like identifying the embedded deployment plan in a xAR so it can look up the config ID, and searching for child modules of an EAR. This is currently hardcoded to the specific set of module types supported by Geronimo by default. It should be able to handle builders deployed later (e.g. Spring, ServiceMix, whatever), which probably means it needs to be able to ask something on the server-side what modules are available, what their nested plan files are called, and what their j2eeType would be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1872) Two meanings of META-INF/geronimo-service.xml
Two meanings of META-INF/geronimo-service.xml - Key: GERONIMO-1872 URL: http://issues.apache.org/jira/browse/GERONIMO-1872 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 The original meaning of geronimo-service.xml files is a list of dependencies for a jar. Recently a new meaning, of an embedded gbean plan, has been added. This different uses should have separate names. Suggestion is to rename the list of dependencies "geronimo-dependency.xml" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: openwire-cpp question
Hi Hiram, I just finished testing 04/18 SNAPSHOT using your latest stomp c client code. I spitted this in to separate producer and consumer. Here are the observations: 1. If I have consumer running and produce messages it works fine now, not getting duplicate messages at consumer. 2. If I queue up the messages (more then 10) and then start the consumer in a loop consumer don't get any of the stored messages. It behaves like there is no message in the queue. I m using MySQL as backend storage for messages. 3. Every now and then I get following warning message on AMQ server console. "WARN ManagedTransportConnection - Failed to unregister mbean: org.apache.activemq:BrokerName=localhost,Type=Connection,ConnectorName =stomp,Connection=ID_.com-33921-1145484700831- 3_23" Thanks! Vik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Wednesday, April 19, 2006 2:02 PM To: activemq-dev@geronimo.apache.org Subject: Re: openwire-cpp question Just do a svn co svn://svn.stomp.codehaus.org/stomp/scm stomp And you'll find all the clients under there. On 4/19/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: > Hi Hiram, > > Thanks for the heads up. Can you please tell me where I can find your updated > c client? > > David: are you planning to incorporate these changes in your code soon? > > Thanks! > > Vik > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino > Sent: Wednesday, April 19, 2006 1:51 PM > To: activemq-dev@geronimo.apache.org > Subject: Re: openwire-cpp question > > On 4/19/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: > > Hey David, > > > > I was able to build this code on Sun Workshop 8, I had to put some OS > > dependant condition checks, like you have for MACOS and have to modify code > > a little bit here and there nothing major. > > > > I am able to run it with AMQ-RC2 but when I tried to run it with latest > > SNAPSHOT (04/18) it was getting stuck after receiving BROKER_INFO command. > > > > Wireformat may have changed a little.. perhaps we need to regenerate > the openwire marshaller for c++ > > > I am not sure if latest SNAPSHOT is having issues because I had the same > > problem with the STOMP C client it was getting stuck after sending the SUB > > command. > > > > There's been a small change to the stomp marshal ling. Before we were > inconsistently adding \n after the \0 frame terminator. So I changed > the activemq side to all ways consistently add the \n after the frame. > It also expects frames that are sent to it to also have the \n. > > I could rollback the requirement for frames that it receive have a \n, > but I think it would be better if the stomp protocol was a bit more > consistent and just did things 1 way. So this could be what has > broken some of the stomp clients. I've updated the c and ruby ones so > that they work once again. > > > Thanks! > > > > Vik > > > > -Original Message- > > From: David Fahlander [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 19, 2006 5:03 AM > > To: activemq-dev@geronimo.apache.org > > Subject: RE: openwire-cpp question > > > > This code compiles and runs on GCC 3, GCC 4 and Visual Studio 2005. We have > > never tried to compile it with Sun compiler. The code is tested and can > > communicate with text messages with the broker (as our test code does). > > > > Hope to get the time to make the code compile with more C++ compilers as > > soon as we get to a point where the code becomes complete. > > > > David > > > > -Original Message- > > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > > Sent: den 18 april 2006 23:37 > > To: activemq-dev@geronimo.apache.org > > Subject: RE: openwire-cpp question > > > > Hi David, > > > > I tried that code earlier and ran in to build issues, there are lots of > > things in this code what Sun Compiler didn't liked. Is this code tested? > > > > Thanks! > > > > Vik > > > > -Original Message- > > From: David Fahlander [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, April 18, 2006 2:55 AM > > To: activemq-dev@geronimo.apache.org > > Cc: Mats Forslöf > > Subject: RE: openwire-cpp question > > > > The latest code is of the openwire cpp client was uploaded as a jira patch > > at http://issues.apache.org/activemq/browse/AMQ-656. The latest version is > > called "source 060406.zip". It contains the full source tree as well as > > make files and a test program. > > > > /David > > > > -Original Message- > > From: Mittler, Nathan [mailto:[EMAIL PROTECTED] > > Sent: den 17 april 2006 17:28 > > To: activemq-dev@geronimo.apache.org > > Cc: Mats Forslöf > > Subject: RE: openwire-cpp question > > > > Hi Mats, > > Is the code in svn your latest? I remember you including unit tests and > > makefiles at some point - did these get lost when the last patch was > > applied? > > > > > > -Original Message-
[jira] Created: (GERONIMO-1871) Unable to deploy Tapestry app due to classloading issue
Unable to deploy Tapestry app due to classloading issue --- Key: GERONIMO-1871 URL: http://issues.apache.org/jira/browse/GERONIMO-1871 Project: Geronimo Type: Bug Security: public (Regular issues) Components: kernel Versions: 1.2 Environment: Windows XP Reporter: Bryan Noll Here is the stacktrace encountered when attempting to deploy a Tapestry application. Please scroll down to see more info after the stack trace. org.apache.hivemind.ApplicationRuntimeException: Error: Module hivemind is duplicated! Definition in jar:file:/C:/tools/geronimo-1.2-SNAPSHOT/config-store/42/war/WEB-INF/lib/hivemind-1.1.jar!/META-INF/hivemodule.xml has been ignored in favor of existing definition from jar:file:/C:/tools/geronimo-1.2-SNAPSHOT/config-store/42/war/WEB-INF/lib/hivemind-1.1.jar!/META-INF/hivemodule.xml. org.apache.hivemind.impl.StrictErrorHandler.error(StrictErrorHandler.java:39) org.apache.hivemind.impl.RegistryInfrastructureConstructor.addModuleDescriptor(RegistryInfrastructureConstructor.java:202) org.apache.hivemind.impl.RegistryBuilder.processModuleDescriptorProvider(RegistryBuilder.java:168) org.apache.hivemind.impl.RegistryBuilder.constructRegistry(RegistryBuilder.java:143) org.apache.tapestry.ApplicationServlet.constructRegistry(ApplicationServlet.java:253) org.apache.tapestry.ApplicationServlet.init(ApplicationServlet.java:194) org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3915) org.apache.catalina.core.StandardContext.start(StandardContext.java:4176) org.apache.geronimo.tomcat.GeronimoStandardContext.access$101(GeronimoStandardContext.java:66) org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:270) org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:185) org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:287) org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$7af7fb0d.addContext() org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:416) org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke() net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173) org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:229) org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke() net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) org.apache.geronimo.kernel.basic.BasicKe
[jira] Commented: (GERONIMO-1866) Make the packaging plugin output to target/ then JAR that into the local repo
[ http://issues.apache.org/jira/browse/GERONIMO-1866?page=comments#action_12375203 ] David Jencks commented on GERONIMO-1866: step 1: supply a target config store to Deployer.deploy. rev 395410 step 2 will be to set up another repo/config store in target. > Make the packaging plugin output to target/ then JAR that into the local repo > - > > Key: GERONIMO-1866 > URL: http://issues.apache.org/jira/browse/GERONIMO-1866 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: Maven Plugins for G > Versions: 1.0 > Reporter: Aaron Mulder > Assignee: David Jencks > Fix For: 1.1 > > It would help the Geronimo plugin process if I could insert an XML file into > the CAR during CAR construction. > It would help XML-based config stuff to review the contents of a CAR without > needing to manually unpack it out of the local Maven repo after construction > In both cases, it would be nice if the packaging plugin wrote to a directory > under target/ and then separately JAR'd that into the local repository (with > a hook to add some Jelly in between to copy in my XML file). > It seems like this could be done by set up a repo in target, building > directly into it in unpacked mode, and then packing/copying somehow into the > real local repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1870) Fix dependencies scope in the spec jars
[ http://issues.apache.org/jira/browse/GERONIMO-1870?page=all ] Guillaume Nodet updated GERONIMO-1870: -- Attachment: GERONIMO-specs.patch > Fix dependencies scope in the spec jars > --- > > Key: GERONIMO-1870 > URL: http://issues.apache.org/jira/browse/GERONIMO-1870 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: specs > Versions: 1.1 > Reporter: Guillaume Nodet > Attachments: GERONIMO-specs.patch > > The poms for the spec jars contains some bad scope for dependencies, which > means users depending on these poms will include unneeded dependencies > (transitive). This is mainly critical for the j2ee jar, which will force the > user to download both the j2ee jar and all its dependencies. > The attached patch fixes the problem -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1870) Fix dependencies scope in the spec jars
Fix dependencies scope in the spec jars --- Key: GERONIMO-1870 URL: http://issues.apache.org/jira/browse/GERONIMO-1870 Project: Geronimo Type: Bug Security: public (Regular issues) Components: specs Versions: 1.1 Reporter: Guillaume Nodet Attachments: GERONIMO-specs.patch The poms for the spec jars contains some bad scope for dependencies, which means users depending on these poms will include unneeded dependencies (transitive). This is mainly critical for the j2ee jar, which will force the user to download both the j2ee jar and all its dependencies. The attached patch fixes the problem -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ServiceMix and security
On Apr 19, 2006, at 10:40 AM, Bruce Snyder wrote: On 4/18/06, Hossam Karim <[EMAIL PROTECTED]> wrote: Just thinking: - Security is a service - A component installed inside SM can support a SM specific security contract, in which a security provider implementing this contract can be bound to one or more installed components. This provider can provide authentication, digital signature verification, XML encryption and decryption, integration with LDAP, etc. - A component that has a security provider installed should delegate all security operations to its provider. - A component that has a security provider should provide additional management operations through JMX to secure its lifecycle management. Actually I agree with Hossam here. I've always considered that security would be delegated to other components, not built into the core of each component. This will allow a wider variation of security models to be addressed and will also allow custom security components to be created to address custom security models on a per enterprise basis. When coding Geronimo, I have found that as soon as I say, "no one will ever do X" someone shows me a service doing just that, so my question is, how will ServiceMix handle components that have security "built into the core"? -dain
Re: Tomcat version in G1.1 for clustering
On Apr 19, 2006, at 12:17 PM, Jeff Genender wrote: IIRC, the 5.5.16 issues had to do with cross context stuff that David Jencks and I worked pretty diligently on to fix. So I would probably be apt to push a -1 on 5.5.16 for 1.1. Jeff or David, can you be more specific on the issue with 5.5.16? Was is a problem in our integration code, the tomcat code, or tck failures related to either code base. BTW, I am fine with sticking to 5.5.9, just want some more info on the problems. -dain
Re: Tomcat version in G1.1 for clustering
Thanks Filip!! Filip Hanik - Dev Lists wrote: 5.5.15,16,17 has some new features, like the JvmRouteBinderValve, that will rewrite the session id for a new node when a node crashes. This is an important feature. The coordination error that you ran into I am not yet sure why it is happening, hence I can't comment on it, and I don't know if it is a result of a code change or just a one time fluke. I would make the same recommendation, to use 5.5.9 for 1.1 since 1.1 is right around the corner. And I will extend/commit my help to get 1.2/5.5.17 in a good shape, including documentation and testing for the clustering piece. Filip Dave Colasurdo wrote: Jeff Genender wrote: I would vote for not moving to 5.5.16 for 1.1. IMHO, its too close. We did some preliminary testing for 5.5.15 and it seems ok...and we will know in the next several days if its good to bake in to 1.1. Filip, How significant are the 5.5.15 bugs that you alluded to? Or is this just a general request to use the latest level... Are the problems unique to clustering? Do you suspect the coordination error to be a code bug in 5.5.15? AFAICT, my setup is identical to 5.5.9.. Would like your input on 5.5.9 -vs- 5.5.15.. Thanks -Dave- 5.5.9 is fine to stick with since its pretty stable and it just works, and in the event 5.5.15 causes any discomfort during testing, we are comfortable that we can fall back on it. IIRC, the 5.5.16 issues had to do with cross context stuff that David Jencks and I worked pretty diligently on to fix. So I would probably be apt to push a -1 on 5.5.16 for 1.1. Jeff Dave Colasurdo wrote: Hmmm.. What level of Tomcat does the community want to include in G1.1? Background... Tomcat 5.5.9 - current working level in G1.0 and G1.1.. Clustering works.. TCK is testing with this level.. Tomcat 5.5.10-5.5.14 - clustering is broken Tomcat 5.5.15 - Clustering seems to work somewhat. We've encountered at least one bug. Filip (tomcat clustering developer) mentioned there are still some significant bugs in this level and advises us to move to 5.5.16. Tomcat 5.5.16 - Jeff has mentioned that he and David J had previously discovered some issues that required significant rework that he didn't want to tackle until G1.2.. So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2? Thanks -Dave- Filip Hanik - Dev Lists wrote: looks like you are right, there where some other fixes in .16 that were important, so it may be better to use that one. seems like you got a coordination error, ie, node1 requested state from node2, but node2 didn't know about node1, and that caused the stack trace from below. Filip Dave Colasurdo wrote: Thanks Filip!! http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] seems to indicate that it is fixed in 5.5.15.. Is it fixed in 5.5.15 or 5.5.16? Thanks -Dave- Filip Hanik - Dev Lists wrote: Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change, this was corrected in 5.5.16. I would run the tests again that version, and then I can help you out with any problems you run into. Filip Dave Colasurdo wrote: Jeff, Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the clustering tests. The *good* news... Load balancing, sticky session, session replication and session failover seem to work using the same deployment plan that was created for G1.1 w/ TC 5.5.9.. The *bad* news... *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. Now, if I restart node1 and wait a minute or so and then hit my browser,I am directed to node1 and all my session data is gone. :( BTW, an earlier run using TC 5.5.9 also resulted in being directed back to node1 though the httpsession is retained. I think this may be related to problems replicating data whenever nodes are added.. Which leads me to ... *Problem2* Whenever a cluster member is added to the cluster, the other nodes receive the following exception. This occurs both during the initial addition of a node and after a stopped node is restarted... (Though later when I access an httpsession (via a servlet request)it does result in session replication between members.) 15:30:19,352 INFO [SimpleTcpCluster] Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 :4001,catalina,192.168.14.160,4001 , alive=0] 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at
Re: Tomcat version in G1.1 for clustering
5.5.15,16,17 has some new features, like the JvmRouteBinderValve, that will rewrite the session id for a new node when a node crashes. This is an important feature. The coordination error that you ran into I am not yet sure why it is happening, hence I can't comment on it, and I don't know if it is a result of a code change or just a one time fluke. I would make the same recommendation, to use 5.5.9 for 1.1 since 1.1 is right around the corner. And I will extend/commit my help to get 1.2/5.5.17 in a good shape, including documentation and testing for the clustering piece. Filip Dave Colasurdo wrote: Jeff Genender wrote: I would vote for not moving to 5.5.16 for 1.1. IMHO, its too close. We did some preliminary testing for 5.5.15 and it seems ok...and we will know in the next several days if its good to bake in to 1.1. Filip, How significant are the 5.5.15 bugs that you alluded to? Or is this just a general request to use the latest level... Are the problems unique to clustering? Do you suspect the coordination error to be a code bug in 5.5.15? AFAICT, my setup is identical to 5.5.9.. Would like your input on 5.5.9 -vs- 5.5.15.. Thanks -Dave- 5.5.9 is fine to stick with since its pretty stable and it just works, and in the event 5.5.15 causes any discomfort during testing, we are comfortable that we can fall back on it. IIRC, the 5.5.16 issues had to do with cross context stuff that David Jencks and I worked pretty diligently on to fix. So I would probably be apt to push a -1 on 5.5.16 for 1.1. Jeff Dave Colasurdo wrote: Hmmm.. What level of Tomcat does the community want to include in G1.1? Background... Tomcat 5.5.9 - current working level in G1.0 and G1.1.. Clustering works.. TCK is testing with this level.. Tomcat 5.5.10-5.5.14 - clustering is broken Tomcat 5.5.15 - Clustering seems to work somewhat. We've encountered at least one bug. Filip (tomcat clustering developer) mentioned there are still some significant bugs in this level and advises us to move to 5.5.16. Tomcat 5.5.16 - Jeff has mentioned that he and David J had previously discovered some issues that required significant rework that he didn't want to tackle until G1.2.. So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2? Thanks -Dave- Filip Hanik - Dev Lists wrote: looks like you are right, there where some other fixes in .16 that were important, so it may be better to use that one. seems like you got a coordination error, ie, node1 requested state from node2, but node2 didn't know about node1, and that caused the stack trace from below. Filip Dave Colasurdo wrote: Thanks Filip!! http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] seems to indicate that it is fixed in 5.5.15.. Is it fixed in 5.5.15 or 5.5.16? Thanks -Dave- Filip Hanik - Dev Lists wrote: Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change, this was corrected in 5.5.16. I would run the tests again that version, and then I can help you out with any problems you run into. Filip Dave Colasurdo wrote: Jeff, Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the clustering tests. The *good* news... Load balancing, sticky session, session replication and session failover seem to work using the same deployment plan that was created for G1.1 w/ TC 5.5.9.. The *bad* news... *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. Now, if I restart node1 and wait a minute or so and then hit my browser,I am directed to node1 and all my session data is gone. :( BTW, an earlier run using TC 5.5.9 also resulted in being directed back to node1 though the httpsession is retained. I think this may be related to problems replicating data whenever nodes are added.. Which leads me to ... *Problem2* Whenever a cluster member is added to the cluster, the other nodes receive the following exception. This occurs both during the initial addition of a node and after a stopped node is restarted... (Though later when I access an httpsession (via a servlet request)it does result in session replication between members.) 15:30:19,352 INFO [SimpleTcpCluster] Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 :4001,catalina,192.168.14.160,4001 , alive=0] 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.catalina.cluster.tcp.ReplicationTrans
Build eclipse plugin using M2
The eclipse plugin has been fully converted to M2 and no will no longer build with M1. There are still some todo's left but everything should compile and both the zip and update site assemblies should generate. Most likley you'll probably run into out of memory errors during the build and will want to set MAVEN_OPTS=-Xmx512m before building to avoid this issue. - sachin
Re: Tomcat version in G1.1 for clustering
Jeff Genender wrote: I would vote for not moving to 5.5.16 for 1.1. IMHO, its too close. We did some preliminary testing for 5.5.15 and it seems ok...and we will know in the next several days if its good to bake in to 1.1. Filip, How significant are the 5.5.15 bugs that you alluded to? Or is this just a general request to use the latest level... Are the problems unique to clustering? Do you suspect the coordination error to be a code bug in 5.5.15? AFAICT, my setup is identical to 5.5.9.. Would like your input on 5.5.9 -vs- 5.5.15.. Thanks -Dave- 5.5.9 is fine to stick with since its pretty stable and it just works, and in the event 5.5.15 causes any discomfort during testing, we are comfortable that we can fall back on it. IIRC, the 5.5.16 issues had to do with cross context stuff that David Jencks and I worked pretty diligently on to fix. So I would probably be apt to push a -1 on 5.5.16 for 1.1. Jeff Dave Colasurdo wrote: Hmmm.. What level of Tomcat does the community want to include in G1.1? Background... Tomcat 5.5.9 - current working level in G1.0 and G1.1.. Clustering works.. TCK is testing with this level.. Tomcat 5.5.10-5.5.14 - clustering is broken Tomcat 5.5.15 - Clustering seems to work somewhat. We've encountered at least one bug. Filip (tomcat clustering developer) mentioned there are still some significant bugs in this level and advises us to move to 5.5.16. Tomcat 5.5.16 - Jeff has mentioned that he and David J had previously discovered some issues that required significant rework that he didn't want to tackle until G1.2.. So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2? Thanks -Dave- Filip Hanik - Dev Lists wrote: looks like you are right, there where some other fixes in .16 that were important, so it may be better to use that one. seems like you got a coordination error, ie, node1 requested state from node2, but node2 didn't know about node1, and that caused the stack trace from below. Filip Dave Colasurdo wrote: Thanks Filip!! http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] seems to indicate that it is fixed in 5.5.15.. Is it fixed in 5.5.15 or 5.5.16? Thanks -Dave- Filip Hanik - Dev Lists wrote: Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change, this was corrected in 5.5.16. I would run the tests again that version, and then I can help you out with any problems you run into. Filip Dave Colasurdo wrote: Jeff, Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the clustering tests. The *good* news... Load balancing, sticky session, session replication and session failover seem to work using the same deployment plan that was created for G1.1 w/ TC 5.5.9.. The *bad* news... *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. Now, if I restart node1 and wait a minute or so and then hit my browser,I am directed to node1 and all my session data is gone. :( BTW, an earlier run using TC 5.5.9 also resulted in being directed back to node1 though the httpsession is retained. I think this may be related to problems replicating data whenever nodes are added.. Which leads me to ... *Problem2* Whenever a cluster member is added to the cluster, the other nodes receive the following exception. This occurs both during the initial addition of a node and after a stopped node is restarted... (Though later when I access an httpsession (via a servlet request)it does result in session replication between members.) 15:30:19,352 INFO [SimpleTcpCluster] Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 :4001,catalina,192.168.14.160,4001 , alive=0] 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Re plicationTransmitter.java:430) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluste r.java:1074) at org.apache.catalina.cluster.session.DeltaManager.sendSessions(DeltaMa nager.java:1690) at org.apache.catalina.cluster.session.DeltaManager.handleGET_ALL_SESSIO NS(DeltaManager.java:1629) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(Delt aManager.java:1443) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived( DeltaManager.java:1225) at org.apache.catalina.cluster.session.ClusterSessionListener.mes
Re: Tomcat version in G1.1 for clustering
On Apr 19, 2006, at 2:47 PM, Dave Colasurdo wrote: Hmmm.. What level of Tomcat does the community want to include in G1.1? Background... Tomcat 5.5.9 - current working level in G1.0 and G1.1.. Clustering works.. TCK is testing with this level.. Tomcat 5.5.10-5.5.14 - clustering is broken Tomcat 5.5.15 - Clustering seems to work somewhat. We've encountered at least one bug. Filip (tomcat clustering developer) mentioned there are still some significant bugs in this level and advises us to move to 5.5.16. Tomcat 5.5.16 - Jeff has mentioned that he and David J had previously discovered some issues that required significant rework that he didn't want to tackle until G1.2.. So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2? I think 5.5.9 is safest, and baseline 5.5.17 for 1.2.
Re: m2 conversion : configurations
Comments inline.. --- David Jencks <[EMAIL PROTECTED]> wrote: > > On Apr 19, 2006, at 9:00 AM, anita kulshreshtha wrote: > > > David, > > Thanks! More comments inline.. > > > > --- David Jencks <[EMAIL PROTECTED]> wrote: > > > >> > >> On Apr 19, 2006, at 6:51 AM, anita kulshreshtha wrote: > >> > >>> Thanks. What criteria has been used to set the > >> geronimo.dependency > >>> property in project.xml? The packaging of most configurations > >> assumes > >>> the packaged configuration will be loaded on top of j2ee-system > >>> configuration. But the 'applications' configurations implicitly > >> assume > >>> that a full server, i.e jetty/tomcat is running. Is this correct? > >> > >> yes. > >>> If > >>> yes, Should we add these configurations (specified by > >>> deploymnetConfig) > >>> to the plans for documentation? > >> no > >>> Is this information stored in > >>> config.ser and the deployer makes sure that these are already > >> loaded? > >> yes. The secret is in the defaultEnvironment attributes of the > >> various builders, which add the necessary parents for each type of > >> j2ee artifact. For instance the jetty builder adds jetty, > connector > >> > >> builder adds connector, etc etc. > > Ideally , if a user wanted to package a car for a simple > > application like jsp-examples, he/she should not be required to > know > > all about the internal configuraitons? The user should be able to > > include a single car as a dependency in pom.xml/project.xml for > > standard servers like j2ee-*-server, web-jms-tomcat-server(?) etc. > > For simple apps the user should not have to include any explicit > dependencies/imports at all: the deployers should figure out what is > > needed and add it for them. This is what the defaultEnvironment/ > defaultParentId is for, and as far as I know it works well. Ah... I remember defaultParentId from TomcatModuleBuilder, it works fine. Do you > know of any problems with this? You are correct. I just tested that all the dependencies on various cars are not needed in the project.xml. Should they be removed? I hope nobody uses it as a sample. They will not be needed in M2 anyway. One minor problem I haven't had time > > to fix is that the axis/ws dependencies are added to all web and ejb > > apps whether or not they are needed: they should be added by the web > > services builder, but there is currently no way to do this. yep, it would be nice to have this in future.. Thanks Anita > > thanks > david jencks > > > > > Thanks > > Anita > > > > You can suppress these defaults in > >> > >> case you have special requirements by using the > >> suppressDefaultEnvironment element in environment. > >> > >> In 1.0/1.2 this is not as well developed or consistent as in 1.1: > the > >> > >> builders have attributes defaultParentId. > >> > >> thanks > >> david jencks > >> > >>> > >>> Thanks > >>> Anita > >>> --- David Jencks <[EMAIL PROTECTED]> wrote: > >>> > > On Apr 17, 2006, at 6:45 AM, anita kulshreshtha wrote: > > > David, > > Thanks! How is j2ee-system configuration started now? > > j2ee-system is the "root" configuration of the main geronimo > >> server, > > and the config.ser file is actually in server.jar. The Daemon > locates it in the classpath and starts it, see line 251. > >>> > >>> The naming is slightly confusing. The server.jar contains > >>> j2ee-system configuraion and not j2ee-server. > >>> > > thanks > david jencks > > > > > Thanks > > Anita > > > > --- David Jencks <[EMAIL PROTECTED]> wrote: > > > >> > >> On Apr 16, 2006, at 9:20 AM, anita kulshreshtha wrote: > >> > >>>The j2ee-security configuration imports only rmi-naming > >>> configuration. What about j2ee-server configuration? > >> > >> I think calling the server side security config j2ee-security > might > >> be misleading; perhaps we should call it server-security. In > >> any > >> case, it doesn't need anything from j2ee-server, so it doesn't > import > >> > >> it. > >> > >> thanks > >> david jencks > >> > >>> > >>> Thanks > >>> Anita > >>> > >>> --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: > >>> > On Apr 11, 2006, at 11:41 AM, Jacek Laskowski wrote: > > > On 4/11/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > >> In 1.1, I moved the corba system properties into a new > >> SystemProperties GBean in the j2ee-corba plan. > > > > Hi Dain, > > > > Will it be merged with trunk?If *I* wanted to merge it with > >> trunk, > > should I try to figure out the revision by taking a look at > j2ee-corba > > plan and commit these changes to trunk? > > sure > > -dain > > >>> > >>> > >>> _
Re: 1.2 build failing
Hi Aaron, yes, it's an on-line build. Everything else builds fine, it's just the assemblies giving me grief. Building with -Drelease does not make any difference (not sure if that's even relevant to the build). The activeio appears is at http://dist.codehaus.org/activeio/jars/ but there's no sign of 3.0 version of the jars or poms. Is 1.2 built by Continuum or anything like that? thanks Conrad On 19 Apr 2006, at 15:43, Aaron Mulder wrote: I assume you've done an online build? Have you checked the repositories (e.g. dist.codehaus.org and www.ibiblio.org/maven) to see if the file in question is there? I havne't built 1.2 for a while. Thanks, Aaron On 4/19/06, Conrad O'Dea <[EMAIL PROTECTED]> wrote: Hi there, I know y'all are busy with 1.1 but does anyone have insight into this problem on trunk? The assemblies will not build with a failed dependency: BUILD FAILED File.. /Users/codea/.maven/cache/geronimo-assembly- plugin-1.2.0-8/ plugin.jelly Element... assemble:installConfig Line.. 190 Column 145 Dependency: incubator-activemq/activeio-core/3.0-SNAPSHOT/jar not found in local maven repo: for configuration: geronimo/activemq- broker/1.2-SNAPSHOT/car thanks Conrad
Re: Tomcat version in G1.1 for clustering
I would vote for not moving to 5.5.16 for 1.1. IMHO, its too close. We did some preliminary testing for 5.5.15 and it seems ok...and we will know in the next several days if its good to bake in to 1.1. 5.5.9 is fine to stick with since its pretty stable and it just works, and in the event 5.5.15 causes any discomfort during testing, we are comfortable that we can fall back on it. IIRC, the 5.5.16 issues had to do with cross context stuff that David Jencks and I worked pretty diligently on to fix. So I would probably be apt to push a -1 on 5.5.16 for 1.1. Jeff Dave Colasurdo wrote: > Hmmm.. What level of Tomcat does the community want to include in G1.1? > > Background... > > Tomcat 5.5.9 - current working level in G1.0 and G1.1.. Clustering > works.. TCK is testing with this level.. > > Tomcat 5.5.10-5.5.14 - clustering is broken > > Tomcat 5.5.15 - Clustering seems to work somewhat. We've encountered at > least one bug. Filip (tomcat clustering developer) mentioned there are > still some significant bugs in this level and advises us to move to 5.5.16. > > Tomcat 5.5.16 - Jeff has mentioned that he and David J had previously > discovered some issues that required significant rework that he didn't > want to tackle until G1.2.. > > So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2? > > Thanks > -Dave- > > > > Filip Hanik - Dev Lists wrote: >> looks like you are right, there where some other fixes in .16 that >> were important, so it may be better to use that one. >> seems like you got a coordination error, ie, node1 requested state >> from node2, but node2 didn't know about node1, and that caused the >> stack trace from below. >> >> Filip >> >> >> Dave Colasurdo wrote: >>> Thanks Filip!! >>> >>> http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL >>> PROTECTED] >>> >>> >>> seems to indicate that it is fixed in 5.5.15.. >>> >>> Is it fixed in 5.5.15 or 5.5.16? >>> >>> Thanks >>> -Dave- >>> >>> Filip Hanik - Dev Lists wrote: Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change, this was corrected in 5.5.16. I would run the tests again that version, and then I can help you out with any problems you run into. Filip Dave Colasurdo wrote: > Jeff, > > Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the > clustering tests. > > The *good* news... > Load balancing, sticky session, session replication and session > failover seem to work using the same deployment plan that was > created for G1.1 w/ TC 5.5.9.. > > The *bad* news... > > *Problem1* > When testing Sticky session, my browser locks unto a particular > cluster member (e.g. node1) due to the nodeid in the cookie. If I > kill node1, the session fails over into node2 and all my session > data is still present. This is good. > The nodeid in the cookie continues to say node1 (this is also true > w/ TC 5.5.9 w/ and mod-jk).. > > Now, if I restart node1 and wait a minute or so and then hit my > browser,I am directed to node1 and all my session data is gone. :( > BTW, an earlier run using TC 5.5.9 also resulted in being directed > back to node1 though the httpsession is retained. I think this may > be related to problems replicating data whenever nodes are > added.. Which leads me to ... > > > *Problem2* > Whenever a cluster member is added to the cluster, the other nodes > receive the following exception. This occurs both during the > initial addition of a node and after a stopped node is restarted... > > (Though later when I access an httpsession (via a servlet > request)it does result in session replication between members.) > > 15:30:19,352 INFO [SimpleTcpCluster] Replication member > added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 > :4001,catalina,192.168.14.160,4001 > , alive=0] > 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message > through cluster sender. > java.io.IOException: Sender not available. Make sure sender > information is available to the ReplicationTransmitter. > at > org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat > a(ReplicationTransmitter.java:857) > at > org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Re > plicationTransmitter.java:430) > at > org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluste > r.java:1074) > at > org.apache.catalina.cluster.session.DeltaManager.sendSessions(DeltaMa > nager.java:1690) > at > org.apache.catalina.cluster.session.DeltaManager.handleGET_ALL_SESSIO > NS(DeltaManager.java:1629) > at > org.apache.catalina.cluster.session.DeltaManager.messageReceived(Delt > aManager.java:1443) > at >
Re: Tomcat version in G1.1 for clustering
Hmmm.. What level of Tomcat does the community want to include in G1.1? Background... Tomcat 5.5.9 - current working level in G1.0 and G1.1.. Clustering works.. TCK is testing with this level.. Tomcat 5.5.10-5.5.14 - clustering is broken Tomcat 5.5.15 - Clustering seems to work somewhat. We've encountered at least one bug. Filip (tomcat clustering developer) mentioned there are still some significant bugs in this level and advises us to move to 5.5.16. Tomcat 5.5.16 - Jeff has mentioned that he and David J had previously discovered some issues that required significant rework that he didn't want to tackle until G1.2.. So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2? Thanks -Dave- Filip Hanik - Dev Lists wrote: looks like you are right, there where some other fixes in .16 that were important, so it may be better to use that one. seems like you got a coordination error, ie, node1 requested state from node2, but node2 didn't know about node1, and that caused the stack trace from below. Filip Dave Colasurdo wrote: Thanks Filip!! http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] seems to indicate that it is fixed in 5.5.15.. Is it fixed in 5.5.15 or 5.5.16? Thanks -Dave- Filip Hanik - Dev Lists wrote: Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change, this was corrected in 5.5.16. I would run the tests again that version, and then I can help you out with any problems you run into. Filip Dave Colasurdo wrote: Jeff, Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the clustering tests. The *good* news... Load balancing, sticky session, session replication and session failover seem to work using the same deployment plan that was created for G1.1 w/ TC 5.5.9.. The *bad* news... *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. Now, if I restart node1 and wait a minute or so and then hit my browser,I am directed to node1 and all my session data is gone. :( BTW, an earlier run using TC 5.5.9 also resulted in being directed back to node1 though the httpsession is retained. I think this may be related to problems replicating data whenever nodes are added.. Which leads me to ... *Problem2* Whenever a cluster member is added to the cluster, the other nodes receive the following exception. This occurs both during the initial addition of a node and after a stopped node is restarted... (Though later when I access an httpsession (via a servlet request)it does result in session replication between members.) 15:30:19,352 INFO [SimpleTcpCluster] Replication member added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.14.160 :4001,catalina,192.168.14.160,4001 , alive=0] 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sender. java.io.IOException: Sender not available. Make sure sender information is available to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessage(Re plicationTransmitter.java:430) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.send(SimpleTcpCluste r.java:1074) at org.apache.catalina.cluster.session.DeltaManager.sendSessions(DeltaMa nager.java:1690) at org.apache.catalina.cluster.session.DeltaManager.handleGET_ALL_SESSIO NS(DeltaManager.java:1629) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(Delt aManager.java:1443) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived( DeltaManager.java:1225) at org.apache.catalina.cluster.session.ClusterSessionListener.messageRec eived(ClusterSessionListener.java:85) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.receive(SimpleTcpClu ster.java:1160) at org.apache.catalina.cluster.tcp.ClusterReceiverBase.messageDataReceiv ed(ClusterReceiverBase.java:418) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java :107) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(Tcp ReplicationThread.java:131) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicati onThread.java:69) 15:30:19,692 ERROR [SimpleTcpCluster] Unable to send message through cluster sen der. java.io.IOException: Sender not available. Make sure sender information is avail able to the ReplicationTransmitter. at org.apache.catalina.cluster.tcp.ReplicationTransmitter.sendMessageDat a(ReplicationTransmitter.java:857) at org.apache.c
[jira] Assigned: (GERONIMO-1844) Precompile jsp pages in console
[ http://issues.apache.org/jira/browse/GERONIMO-1844?page=all ] Prasad Kashyap reassigned GERONIMO-1844: Assign To: Dain Sundstrom (was: Prasad Kashyap) Assigning back to you so that you can apply the patch. > Precompile jsp pages in console > --- > > Key: GERONIMO-1844 > URL: http://issues.apache.org/jira/browse/GERONIMO-1844 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: console > Reporter: Dain Sundstrom > Assignee: Dain Sundstrom > Fix For: 1.1 > Attachments: jsp-precompile.patch > > The maven script for precompiling jsp pages in console-framework and > console-standard is broken so I commented it out. The following article > explains how to use jsp precompliation: > http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html > In addition to this, we need to jar the compiled files to reduce the overall > path length. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: openwire-cpp question
Just do a svn co svn://svn.stomp.codehaus.org/stomp/scm stomp And you'll find all the clients under there. On 4/19/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: > Hi Hiram, > > Thanks for the heads up. Can you please tell me where I can find your updated > c client? > > David: are you planning to incorporate these changes in your code soon? > > Thanks! > > Vik > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino > Sent: Wednesday, April 19, 2006 1:51 PM > To: activemq-dev@geronimo.apache.org > Subject: Re: openwire-cpp question > > On 4/19/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: > > Hey David, > > > > I was able to build this code on Sun Workshop 8, I had to put some OS > > dependant condition checks, like you have for MACOS and have to modify code > > a little bit here and there nothing major. > > > > I am able to run it with AMQ-RC2 but when I tried to run it with latest > > SNAPSHOT (04/18) it was getting stuck after receiving BROKER_INFO command. > > > > Wireformat may have changed a little.. perhaps we need to regenerate > the openwire marshaller for c++ > > > I am not sure if latest SNAPSHOT is having issues because I had the same > > problem with the STOMP C client it was getting stuck after sending the SUB > > command. > > > > There's been a small change to the stomp marshal ling. Before we were > inconsistently adding \n after the \0 frame terminator. So I changed > the activemq side to all ways consistently add the \n after the frame. > It also expects frames that are sent to it to also have the \n. > > I could rollback the requirement for frames that it receive have a \n, > but I think it would be better if the stomp protocol was a bit more > consistent and just did things 1 way. So this could be what has > broken some of the stomp clients. I've updated the c and ruby ones so > that they work once again. > > > Thanks! > > > > Vik > > > > -Original Message- > > From: David Fahlander [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 19, 2006 5:03 AM > > To: activemq-dev@geronimo.apache.org > > Subject: RE: openwire-cpp question > > > > This code compiles and runs on GCC 3, GCC 4 and Visual Studio 2005. We have > > never tried to compile it with Sun compiler. The code is tested and can > > communicate with text messages with the broker (as our test code does). > > > > Hope to get the time to make the code compile with more C++ compilers as > > soon as we get to a point where the code becomes complete. > > > > David > > > > -Original Message- > > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > > Sent: den 18 april 2006 23:37 > > To: activemq-dev@geronimo.apache.org > > Subject: RE: openwire-cpp question > > > > Hi David, > > > > I tried that code earlier and ran in to build issues, there are lots of > > things in this code what Sun Compiler didn't liked. Is this code tested? > > > > Thanks! > > > > Vik > > > > -Original Message- > > From: David Fahlander [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, April 18, 2006 2:55 AM > > To: activemq-dev@geronimo.apache.org > > Cc: Mats Forslöf > > Subject: RE: openwire-cpp question > > > > The latest code is of the openwire cpp client was uploaded as a jira patch > > at http://issues.apache.org/activemq/browse/AMQ-656. The latest version is > > called "source 060406.zip". It contains the full source tree as well as > > make files and a test program. > > > > /David > > > > -Original Message- > > From: Mittler, Nathan [mailto:[EMAIL PROTECTED] > > Sent: den 17 april 2006 17:28 > > To: activemq-dev@geronimo.apache.org > > Cc: Mats Forslöf > > Subject: RE: openwire-cpp question > > > > Hi Mats, > > Is the code in svn your latest? I remember you including unit tests and > > makefiles at some point - did these get lost when the last patch was > > applied? > > > > > > -Original Message- > > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > > Sent: Monday, April 17, 2006 11:08 AM > > To: activemq-dev@geronimo.apache.org > > Subject: RE: openwire-cpp question > > > > There is no test stub either. I am wondering if someone ever tested it? > > > > Vik > > > > -Original Message- > > From: Mittler, Nathan [mailto:[EMAIL PROTECTED] > > Sent: Monday, April 17, 2006 11:01 AM > > To: activemq-dev@geronimo.apache.org > > Subject: RE: openwire-cpp question > > > > Hmm ... that surprises me - I know the openwire-cpp team had included > > makefiles in the past. I believe the code should support linux, > > windows, & OSX. > > > > Does anyone know where the makefiles are? > > > > -Original Message- > > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > > Sent: Monday, April 17, 2006 10:08 AM > > To: activemq-dev@geronimo.apache.org > > Subject: RE: openwire-cpp question > > > > Hey Nate, > > > > I don't see any make file or something in there? Do you have any idea > > what O/S version and C++ c
RE: openwire-cpp question
Hi Hiram, Thanks for the heads up. Can you please tell me where I can find your updated c client? David: are you planning to incorporate these changes in your code soon? Thanks! Vik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Wednesday, April 19, 2006 1:51 PM To: activemq-dev@geronimo.apache.org Subject: Re: openwire-cpp question On 4/19/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: > Hey David, > > I was able to build this code on Sun Workshop 8, I had to put some OS > dependant condition checks, like you have for MACOS and have to modify code a > little bit here and there nothing major. > > I am able to run it with AMQ-RC2 but when I tried to run it with latest > SNAPSHOT (04/18) it was getting stuck after receiving BROKER_INFO command. > Wireformat may have changed a little.. perhaps we need to regenerate the openwire marshaller for c++ > I am not sure if latest SNAPSHOT is having issues because I had the same > problem with the STOMP C client it was getting stuck after sending the SUB > command. > There's been a small change to the stomp marshal ling. Before we were inconsistently adding \n after the \0 frame terminator. So I changed the activemq side to all ways consistently add the \n after the frame. It also expects frames that are sent to it to also have the \n. I could rollback the requirement for frames that it receive have a \n, but I think it would be better if the stomp protocol was a bit more consistent and just did things 1 way. So this could be what has broken some of the stomp clients. I've updated the c and ruby ones so that they work once again. > Thanks! > > Vik > > -Original Message- > From: David Fahlander [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 19, 2006 5:03 AM > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > This code compiles and runs on GCC 3, GCC 4 and Visual Studio 2005. We have > never tried to compile it with Sun compiler. The code is tested and can > communicate with text messages with the broker (as our test code does). > > Hope to get the time to make the code compile with more C++ compilers as soon > as we get to a point where the code becomes complete. > > David > > -Original Message- > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > Sent: den 18 april 2006 23:37 > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > Hi David, > > I tried that code earlier and ran in to build issues, there are lots of > things in this code what Sun Compiler didn't liked. Is this code tested? > > Thanks! > > Vik > > -Original Message- > From: David Fahlander [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 18, 2006 2:55 AM > To: activemq-dev@geronimo.apache.org > Cc: Mats Forslöf > Subject: RE: openwire-cpp question > > The latest code is of the openwire cpp client was uploaded as a jira patch at > http://issues.apache.org/activemq/browse/AMQ-656. The latest version is > called "source 060406.zip". It contains the full source tree as well as make > files and a test program. > > /David > > -Original Message- > From: Mittler, Nathan [mailto:[EMAIL PROTECTED] > Sent: den 17 april 2006 17:28 > To: activemq-dev@geronimo.apache.org > Cc: Mats Forslöf > Subject: RE: openwire-cpp question > > Hi Mats, > Is the code in svn your latest? I remember you including unit tests and > makefiles at some point - did these get lost when the last patch was > applied? > > > -Original Message- > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > Sent: Monday, April 17, 2006 11:08 AM > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > There is no test stub either. I am wondering if someone ever tested it? > > Vik > > -Original Message- > From: Mittler, Nathan [mailto:[EMAIL PROTECTED] > Sent: Monday, April 17, 2006 11:01 AM > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > Hmm ... that surprises me - I know the openwire-cpp team had included > makefiles in the past. I believe the code should support linux, > windows, & OSX. > > Does anyone know where the makefiles are? > > -Original Message- > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > Sent: Monday, April 17, 2006 10:08 AM > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > Hey Nate, > > I don't see any make file or something in there? Do you have any idea > what O/S version and C++ complier this code recommends? > > Thanks! > > Vik > > -Original Message- > From: Nathan Mittler [mailto:[EMAIL PROTECTED] > Sent: Monday, April 17, 2006 6:16 AM > To: activemq-dev@geronimo.apache.org > Subject: Re: openwire-cpp question > > The latter - It's a client-side library. The same is true for the Stomp > CMS > lib and the openwire .NET lib. > > Regards, > Nate > > On 4/16/06, vik Dhawan <[EMAIL PROTECTED]> wrote: > > >
Re: openwire-cpp question
On 4/19/06, Dhawan, Vikram (LNG-DAY) <[EMAIL PROTECTED]> wrote: > Hey David, > > I was able to build this code on Sun Workshop 8, I had to put some OS > dependant condition checks, like you have for MACOS and have to modify code a > little bit here and there nothing major. > > I am able to run it with AMQ-RC2 but when I tried to run it with latest > SNAPSHOT (04/18) it was getting stuck after receiving BROKER_INFO command. > Wireformat may have changed a little.. perhaps we need to regenerate the openwire marshaller for c++ > I am not sure if latest SNAPSHOT is having issues because I had the same > problem with the STOMP C client it was getting stuck after sending the SUB > command. > There's been a small change to the stomp marshal ling. Before we were inconsistently adding \n after the \0 frame terminator. So I changed the activemq side to all ways consistently add the \n after the frame. It also expects frames that are sent to it to also have the \n. I could rollback the requirement for frames that it receive have a \n, but I think it would be better if the stomp protocol was a bit more consistent and just did things 1 way. So this could be what has broken some of the stomp clients. I've updated the c and ruby ones so that they work once again. > Thanks! > > Vik > > -Original Message- > From: David Fahlander [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 19, 2006 5:03 AM > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > This code compiles and runs on GCC 3, GCC 4 and Visual Studio 2005. We have > never tried to compile it with Sun compiler. The code is tested and can > communicate with text messages with the broker (as our test code does). > > Hope to get the time to make the code compile with more C++ compilers as soon > as we get to a point where the code becomes complete. > > David > > -Original Message- > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > Sent: den 18 april 2006 23:37 > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > Hi David, > > I tried that code earlier and ran in to build issues, there are lots of > things in this code what Sun Compiler didn't liked. Is this code tested? > > Thanks! > > Vik > > -Original Message- > From: David Fahlander [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 18, 2006 2:55 AM > To: activemq-dev@geronimo.apache.org > Cc: Mats Forslöf > Subject: RE: openwire-cpp question > > The latest code is of the openwire cpp client was uploaded as a jira patch at > http://issues.apache.org/activemq/browse/AMQ-656. The latest version is > called "source 060406.zip". It contains the full source tree as well as make > files and a test program. > > /David > > -Original Message- > From: Mittler, Nathan [mailto:[EMAIL PROTECTED] > Sent: den 17 april 2006 17:28 > To: activemq-dev@geronimo.apache.org > Cc: Mats Forslöf > Subject: RE: openwire-cpp question > > Hi Mats, > Is the code in svn your latest? I remember you including unit tests and > makefiles at some point - did these get lost when the last patch was > applied? > > > -Original Message- > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > Sent: Monday, April 17, 2006 11:08 AM > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > There is no test stub either. I am wondering if someone ever tested it? > > Vik > > -Original Message- > From: Mittler, Nathan [mailto:[EMAIL PROTECTED] > Sent: Monday, April 17, 2006 11:01 AM > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > Hmm ... that surprises me - I know the openwire-cpp team had included > makefiles in the past. I believe the code should support linux, > windows, & OSX. > > Does anyone know where the makefiles are? > > -Original Message- > From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] > Sent: Monday, April 17, 2006 10:08 AM > To: activemq-dev@geronimo.apache.org > Subject: RE: openwire-cpp question > > Hey Nate, > > I don't see any make file or something in there? Do you have any idea > what O/S version and C++ complier this code recommends? > > Thanks! > > Vik > > -Original Message- > From: Nathan Mittler [mailto:[EMAIL PROTECTED] > Sent: Monday, April 17, 2006 6:16 AM > To: activemq-dev@geronimo.apache.org > Subject: Re: openwire-cpp question > > The latter - It's a client-side library. The same is true for the Stomp > CMS > lib and the openwire .NET lib. > > Regards, > Nate > > On 4/16/06, vik Dhawan <[EMAIL PROTECTED]> wrote: > > > > > > I wanted to know the use of Development branch on SVN at > > http://svn.apache.org/repos/asf/incubator/activemq/trunk/openwire-cpp/ > > > > Is this a C++ implementation of ActiveMQ? is it complete? or is it can > be > > used as a C++ library so some application can use classes in this > library > > to > > connect to a remote AMQ server? > > > > Thanks! > > > > > > -- > > View this message in contex
Re: unit test failures
Hi Jacek & all, I've discovered that the most recent Jrockit VM + ApacheDS 1.0 RC1 will completely solve the problem with the org.apache.geronimo.directory.RunningTest hang on Jrockit (see the discussion at DIRECTORY-607 for details). Moreover, I've seen some other posts with signs of dissatisfaction with the outdated version of Apache DS currently being used. So it seems that we need to move Geronimo to ApacheDS 1.0 anyway. I can start working on the corresponding patch. Any comments & objections? 2006/4/14, Alexei Zakharov <[EMAIL PROTECTED]>: > Hi Jacek, > > > It seems not to be a problem any more since we can be ensured you'll > > back up our efforts, won't you? ;) > > Ok, I will try. :) > Currently, ApacheDS guys argue about this bug: does it really ApacheDS > bug? You may see the discussion at > http://issues.apache.org/jira/browse/DIRSERVER-607 > > > 2006/4/11, Jacek Laskowski <[EMAIL PROTECTED]>: > > On 4/11/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > > > However, they use different API since ApacheDS 1.0 > > > RC1, some packages are renamed. Some efforts will be required to > > > rewrite the Geronimo portion of the code. > > > > Hi Alexei, > > > > It seems not to be a problem any more since we can be ensured you'll > > back up our efforts, won't you? ;) > > > > Do you happen to know when they're going to release the fixed version? > > Any estimates? -- Alexei Zakharov, Intel Middleware Product Division
Re: ServiceMix and security
On 4/18/06, Hossam Karim <[EMAIL PROTECTED]> wrote:
> Just thinking:
> - Security is a service
> - A component installed inside SM can support a SM specific security
> contract, in which a security provider implementing this contract can be
> bound to one or more installed components. This provider can provide
> authentication, digital signature verification, XML encryption and
> decryption, integration with LDAP, etc.
> - A component that has a security provider installed should delegate all
> security operations to its provider.
> - A component that has a security provider should provide additional
> management operations through JMX to secure its lifecycle management.
Actually I agree with Hossam here. I've always considered that
security would be delegated to other components, not built into the
core of each component. This will allow a wider variation of security
models to be addressed and will also allow custom security components
to be created to address custom security models on a per enterprise
basis.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Browsing G 1.1 using jconsole
You can change attribute values, invoke operations, and register for notifications. It is fairly primitive, but it works. -dain On Apr 19, 2006, at 4:56 AM, anita kulshreshtha wrote: Great! I am assuming that jconsole does not allow modifying the attributes of a tomcat Mbean as allowed by the tomcat Manager application. http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html#Using% 20the%20JMX%20Proxy%20Servlet Thanks Anita --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: I fixed a number of bugs around our JMX integration in G 1.1 today, and you can now browse the Geronimo server using jconsole in Java 5. You will see all GBeans and the tomcat MBeans (assuming you are using tomcat). I use the following command to connect to the server: jconsole service:jmx:rmi:///jndi/rmi://localhost:1099/JMXConnector For all of you on macs out there the java 5 jconsole command is located at /System/Library/Frameworks/JavaVM.framework/Versions/1.5/ Home/bin/jconsole There are a few annoying error messages logged to the console, and if I have some time I'll try to eliminate them. -dain __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: m2 conversion : configurations
On Apr 19, 2006, at 9:00 AM, anita kulshreshtha wrote: David, Thanks! More comments inline.. --- David Jencks <[EMAIL PROTECTED]> wrote: On Apr 19, 2006, at 6:51 AM, anita kulshreshtha wrote: Thanks. What criteria has been used to set the geronimo.dependency property in project.xml? The packaging of most configurations assumes the packaged configuration will be loaded on top of j2ee-system configuration. But the 'applications' configurations implicitly assume that a full server, i.e jetty/tomcat is running. Is this correct? yes. If yes, Should we add these configurations (specified by deploymnetConfig) to the plans for documentation? no Is this information stored in config.ser and the deployer makes sure that these are already loaded? yes. The secret is in the defaultEnvironment attributes of the various builders, which add the necessary parents for each type of j2ee artifact. For instance the jetty builder adds jetty, connector builder adds connector, etc etc. Ideally , if a user wanted to package a car for a simple application like jsp-examples, he/she should not be required to know all about the internal configuraitons? The user should be able to include a single car as a dependency in pom.xml/project.xml for standard servers like j2ee-*-server, web-jms-tomcat-server(?) etc. For simple apps the user should not have to include any explicit dependencies/imports at all: the deployers should figure out what is needed and add it for them. This is what the defaultEnvironment/ defaultParentId is for, and as far as I know it works well. Do you know of any problems with this? One minor problem I haven't had time to fix is that the axis/ws dependencies are added to all web and ejb apps whether or not they are needed: they should be added by the web services builder, but there is currently no way to do this. thanks david jencks Thanks Anita You can suppress these defaults in case you have special requirements by using the suppressDefaultEnvironment element in environment. In 1.0/1.2 this is not as well developed or consistent as in 1.1: the builders have attributes defaultParentId. thanks david jencks Thanks Anita --- David Jencks <[EMAIL PROTECTED]> wrote: On Apr 17, 2006, at 6:45 AM, anita kulshreshtha wrote: David, Thanks! How is j2ee-system configuration started now? j2ee-system is the "root" configuration of the main geronimo server, and the config.ser file is actually in server.jar. The Daemon locates it in the classpath and starts it, see line 251. The naming is slightly confusing. The server.jar contains j2ee-system configuraion and not j2ee-server. thanks david jencks Thanks Anita --- David Jencks <[EMAIL PROTECTED]> wrote: On Apr 16, 2006, at 9:20 AM, anita kulshreshtha wrote: The j2ee-security configuration imports only rmi-naming configuration. What about j2ee-server configuration? I think calling the server side security config j2ee-security might be misleading; perhaps we should call it server-security. In any case, it doesn't need anything from j2ee-server, so it doesn't import it. thanks david jencks Thanks Anita --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Apr 11, 2006, at 11:41 AM, Jacek Laskowski wrote: On 4/11/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: In 1.1, I moved the corba system properties into a new SystemProperties GBean in the j2ee-corba plan. Hi Dain, Will it be merged with trunk?If *I* wanted to merge it with trunk, should I try to figure out the revision by taking a look at j2ee-corba plan and commit these changes to trunk? sure -dain __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: 1.1 build broken...Java 1.5 issue?
I noticed something similar last week too while trying to perform a clean build of 1.1. I eventually gave up after a few hours of frustration :-( I'd love to get this resolved so I can build 1.1 again. --jason On Apr 19, 2006, at 8:47 AM, Jeff Genender wrote: It seems that G1.1 build is broken as there is a dependency that was pushed that was built with Java 1.5...any ideas?: + | geronimo and geronimo-plugins Geronimo :: J2EE Schema | Memory: 15M/30M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: build:start: multiproject:install-callback: [echo] Running jar:install for Geronimo :: J2EE Schema java:prepare-filesystem: [mkdir] Created dir: /Users/powerbook/Projects/gv1.1/modules/j2ee-schema/target/classes java:compile: Cannot find CatalogManager.properties BUILD FAILED File.. /Users/powerbook/Projects/gv1.1/maven.xml Element... maven:reactor Line.. 43 Column -1 Unable to obtain goal [multiproject:install-callback] -- /Users/powerbook/.maven/cache/xmlbeans-maven-plugin-2.0.0-beta1/ plugin.jelly:83:-1: javax/xml/namespace/QName (Unsupported major.minor version 49.0) Total time : 1 minutes 55 seconds Finished at : Wednesday, April 19, 2006 9:45:56 AM MDT
[jira] Commented: (GERONIMO-1636) Support optional version number on dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-1636?page=comments#action_12375148 ] David Jencks commented on GERONIMO-1636: most of this is done in g rev 395290 and openejb rev 2613. One remaining part is to parameterize the versions in the etc/external_versions.properties file. > Support optional version number on dependencies > --- > > Key: GERONIMO-1636 > URL: http://issues.apache.org/jira/browse/GERONIMO-1636 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: kernel > Versions: 1.0 > Reporter: Dain Sundstrom > Assignee: David Jencks > Fix For: 1.1 > > Add support for making the version number of a dependency optional. In the > case of a missing version number a pluggable strategy should choose the > actual version to load. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: m2 conversion : configurations
David, Thanks! More comments inline.. --- David Jencks <[EMAIL PROTECTED]> wrote: > > On Apr 19, 2006, at 6:51 AM, anita kulshreshtha wrote: > > > Thanks. What criteria has been used to set the > geronimo.dependency > > property in project.xml? The packaging of most configurations > assumes > > the packaged configuration will be loaded on top of j2ee-system > > configuration. But the 'applications' configurations implicitly > assume > > that a full server, i.e jetty/tomcat is running. Is this correct? > > yes. > > If > > yes, Should we add these configurations (specified by > > deploymnetConfig) > > to the plans for documentation? > no > > Is this information stored in > > config.ser and the deployer makes sure that these are already > loaded? > yes. The secret is in the defaultEnvironment attributes of the > various builders, which add the necessary parents for each type of > j2ee artifact. For instance the jetty builder adds jetty, connector > > builder adds connector, etc etc. Ideally , if a user wanted to package a car for a simple application like jsp-examples, he/she should not be required to know all about the internal configuraitons? The user should be able to include a single car as a dependency in pom.xml/project.xml for standard servers like j2ee-*-server, web-jms-tomcat-server(?) etc. Thanks Anita You can suppress these defaults in > > case you have special requirements by using the > suppressDefaultEnvironment element in environment. > > In 1.0/1.2 this is not as well developed or consistent as in 1.1: the > > builders have attributes defaultParentId. > > thanks > david jencks > > > > > Thanks > > Anita > > --- David Jencks <[EMAIL PROTECTED]> wrote: > > > >> > >> On Apr 17, 2006, at 6:45 AM, anita kulshreshtha wrote: > >> > >>> David, > >>> Thanks! How is j2ee-system configuration started now? > >> > >> j2ee-system is the "root" configuration of the main geronimo > server, > >> > >> and the config.ser file is actually in server.jar. The Daemon > >> locates it in the classpath and starts it, see line 251. > > > > The naming is slightly confusing. The server.jar contains > > j2ee-system configuraion and not j2ee-server. > > > >> > >> thanks > >> david jencks > >> > >>> > >>> Thanks > >>> Anita > >>> > >>> --- David Jencks <[EMAIL PROTECTED]> wrote: > >>> > > On Apr 16, 2006, at 9:20 AM, anita kulshreshtha wrote: > > >The j2ee-security configuration imports only rmi-naming > > configuration. What about j2ee-server configuration? > > I think calling the server side security config j2ee-security > >> might > be misleading; perhaps we should call it server-security. In > any > case, it doesn't need anything from j2ee-server, so it doesn't > >> import > > it. > > thanks > david jencks > > > > > Thanks > > Anita > > > > --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: > > > >> On Apr 11, 2006, at 11:41 AM, Jacek Laskowski wrote: > >> > >>> On 4/11/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > In 1.1, I moved the corba system properties into a new > SystemProperties GBean in the j2ee-corba plan. > >>> > >>> Hi Dain, > >>> > >>> Will it be merged with trunk?If *I* wanted to merge it with > trunk, > >>> should I try to figure out the revision by taking a look at > >> j2ee-corba > >>> plan and commit these changes to trunk? > >> > >> sure > >> > >> -dain > >> > > > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > >>> > >>> > >>> __ > >>> Do You Yahoo!? > >>> Tired of spam? Yahoo! Mail has the best spam protection around > >>> http://mail.yahoo.com > >> > >> > > > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
1.1 build broken...Java 1.5 issue?
It seems that G1.1 build is broken as there is a dependency that was pushed that was built with Java 1.5...any ideas?: + | geronimo and geronimo-plugins Geronimo :: J2EE Schema | Memory: 15M/30M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: build:start: multiproject:install-callback: [echo] Running jar:install for Geronimo :: J2EE Schema java:prepare-filesystem: [mkdir] Created dir: /Users/powerbook/Projects/gv1.1/modules/j2ee-schema/target/classes java:compile: Cannot find CatalogManager.properties BUILD FAILED File.. /Users/powerbook/Projects/gv1.1/maven.xml Element... maven:reactor Line.. 43 Column -1 Unable to obtain goal [multiproject:install-callback] -- /Users/powerbook/.maven/cache/xmlbeans-maven-plugin-2.0.0-beta1/plugin.jelly:83:-1: javax/xml/namespace/QName (Unsupported major.minor version 49.0) Total time : 1 minutes 55 seconds Finished at : Wednesday, April 19, 2006 9:45:56 AM MDT
RE: openwire-cpp question
Nice you got it to compile and run! =) Maybe there have been modifications in the openwire protocol since AMQ-RC2. A snapshot can always be a little unstable. I think that James would know more about that. /David -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: den 19 april 2006 16:45 To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hey David, I was able to build this code on Sun Workshop 8, I had to put some OS dependant condition checks, like you have for MACOS and have to modify code a little bit here and there nothing major. I am able to run it with AMQ-RC2 but when I tried to run it with latest SNAPSHOT (04/18) it was getting stuck after receiving BROKER_INFO command. I am not sure if latest SNAPSHOT is having issues because I had the same problem with the STOMP C client it was getting stuck after sending the SUB command. Thanks! Vik -Original Message- From: David Fahlander [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 5:03 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question This code compiles and runs on GCC 3, GCC 4 and Visual Studio 2005. We have never tried to compile it with Sun compiler. The code is tested and can communicate with text messages with the broker (as our test code does). Hope to get the time to make the code compile with more C++ compilers as soon as we get to a point where the code becomes complete. David -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: den 18 april 2006 23:37 To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hi David, I tried that code earlier and ran in to build issues, there are lots of things in this code what Sun Compiler didn't liked. Is this code tested? Thanks! Vik -Original Message- From: David Fahlander [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 18, 2006 2:55 AM To: activemq-dev@geronimo.apache.org Cc: Mats Forslöf Subject: RE: openwire-cpp question The latest code is of the openwire cpp client was uploaded as a jira patch at http://issues.apache.org/activemq/browse/AMQ-656. The latest version is called "source 060406.zip". It contains the full source tree as well as make files and a test program. /David -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 17 april 2006 17:28 To: activemq-dev@geronimo.apache.org Cc: Mats Forslöf Subject: RE: openwire-cpp question Hi Mats, Is the code in svn your latest? I remember you including unit tests and makefiles at some point - did these get lost when the last patch was applied? -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 11:08 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question There is no test stub either. I am wondering if someone ever tested it? Vik -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 11:01 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hmm ... that surprises me - I know the openwire-cpp team had included makefiles in the past. I believe the code should support linux, windows, & OSX. Does anyone know where the makefiles are? -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 10:08 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hey Nate, I don't see any make file or something in there? Do you have any idea what O/S version and C++ complier this code recommends? Thanks! Vik -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 6:16 AM To: activemq-dev@geronimo.apache.org Subject: Re: openwire-cpp question The latter - It's a client-side library. The same is true for the Stomp CMS lib and the openwire .NET lib. Regards, Nate On 4/16/06, vik Dhawan <[EMAIL PROTECTED]> wrote: > > > I wanted to know the use of Development branch on SVN at > http://svn.apache.org/repos/asf/incubator/activemq/trunk/openwire-cpp/ > > Is this a C++ implementation of ActiveMQ? is it complete? or is it can be > used as a C++ library so some application can use classes in this library > to > connect to a remote AMQ server? > > Thanks! > > > -- > View this message in context: > http://www.nabble.com/openwire-cpp-question-t1459989.html#a3945792 > Sent from the ActiveMQ - Dev forum at Nabble.com. > >
Apache Geronimo quarterly report for 2006-04
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [resend; the first one didn't show up after 4 hours, assuming lost] This report covers the period from 2006-01-18 through 2006-04-18. Activity: - - Presentations about Apache Geronimo were given variously by Dain Sundstrom, Aaron Mulder, Matt Hogstrom, and Jeff at JAOO and The Server Side Symposium. A lot of work went into giving the Geronimo Web a major facelift. The issue of having a Confluence wiki hosted on Apache hardware was raised again, since the vast majority of opinions polled on the dev list favoured keeping the Geronimo documentation in that format. Some progress has been made, but at the moment the documentation is still hosted at a third-party Confluence installation offsite. In this period, 422 JIRA issues were created, 205 were closed, and 14 closed ones were reopened. (The reopened ones were not necessarily closed during this interval.) PMC: - Jason Dillon and Kevan Lee Miller were invited to join the PMC, and both accepted. A number of individuals who have been given commit karma in the past have subsequently largely disappeared from the project. Although the PMC hasn't yet decided what to do about that sort of situation, it has been a major factor in several PMC members' opinions that an invitation to join the PMC should not be considered for some indefinite interval after karma has been granted. Since I personally disagree strongly with that position and am not satisfied that anyone has identified any harmful effects, I do not consider the issue yet closed. Although the subject of project bylaws/guidelines has come up several times, and various people are ruminating on the issue, no concrete progress has been made on that front. Committers: - --- The PMC voted to offer commit karma to Hernan Cunico, and he accepted. There are other karma votes currently in progress. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBREZPOJrNPMCpn3XdAQImCAP/QATcasv3BqRyZa/PT3JAtzXSv/ZP+LMA 2fVkSyvTdiESh0jCNHntAw0P+eVkrMM236t9EPkZllBYD3HyF0UUevttJMyLfz+A QTB/5gW/31IIvnb4OXeJbf5NIQX9tNKnnWFFNa7/Woe3hmKc/CryuOOM1GzsCal2 +KdDiLbhNPk= =oKo+ -END PGP SIGNATURE-
RE: openwire-cpp question
Hey David, I was able to build this code on Sun Workshop 8, I had to put some OS dependant condition checks, like you have for MACOS and have to modify code a little bit here and there nothing major. I am able to run it with AMQ-RC2 but when I tried to run it with latest SNAPSHOT (04/18) it was getting stuck after receiving BROKER_INFO command. I am not sure if latest SNAPSHOT is having issues because I had the same problem with the STOMP C client it was getting stuck after sending the SUB command. Thanks! Vik -Original Message- From: David Fahlander [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 5:03 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question This code compiles and runs on GCC 3, GCC 4 and Visual Studio 2005. We have never tried to compile it with Sun compiler. The code is tested and can communicate with text messages with the broker (as our test code does). Hope to get the time to make the code compile with more C++ compilers as soon as we get to a point where the code becomes complete. David -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: den 18 april 2006 23:37 To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hi David, I tried that code earlier and ran in to build issues, there are lots of things in this code what Sun Compiler didn't liked. Is this code tested? Thanks! Vik -Original Message- From: David Fahlander [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 18, 2006 2:55 AM To: activemq-dev@geronimo.apache.org Cc: Mats Forslöf Subject: RE: openwire-cpp question The latest code is of the openwire cpp client was uploaded as a jira patch at http://issues.apache.org/activemq/browse/AMQ-656. The latest version is called "source 060406.zip". It contains the full source tree as well as make files and a test program. /David -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 17 april 2006 17:28 To: activemq-dev@geronimo.apache.org Cc: Mats Forslöf Subject: RE: openwire-cpp question Hi Mats, Is the code in svn your latest? I remember you including unit tests and makefiles at some point - did these get lost when the last patch was applied? -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 11:08 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question There is no test stub either. I am wondering if someone ever tested it? Vik -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 11:01 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hmm ... that surprises me - I know the openwire-cpp team had included makefiles in the past. I believe the code should support linux, windows, & OSX. Does anyone know where the makefiles are? -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 10:08 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hey Nate, I don't see any make file or something in there? Do you have any idea what O/S version and C++ complier this code recommends? Thanks! Vik -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 6:16 AM To: activemq-dev@geronimo.apache.org Subject: Re: openwire-cpp question The latter - It's a client-side library. The same is true for the Stomp CMS lib and the openwire .NET lib. Regards, Nate On 4/16/06, vik Dhawan <[EMAIL PROTECTED]> wrote: > > > I wanted to know the use of Development branch on SVN at > http://svn.apache.org/repos/asf/incubator/activemq/trunk/openwire-cpp/ > > Is this a C++ implementation of ActiveMQ? is it complete? or is it can be > used as a C++ library so some application can use classes in this library > to > connect to a remote AMQ server? > > Thanks! > > > -- > View this message in context: > http://www.nabble.com/openwire-cpp-question-t1459989.html#a3945792 > Sent from the ActiveMQ - Dev forum at Nabble.com. > >
Re: 1.2 build failing
I assume you've done an online build? Have you checked the repositories (e.g. dist.codehaus.org and www.ibiblio.org/maven) to see if the file in question is there? I havne't built 1.2 for a while. Thanks, Aaron On 4/19/06, Conrad O'Dea <[EMAIL PROTECTED]> wrote: > Hi there, > > I know y'all are busy with 1.1 but does anyone have insight into > this problem on trunk? The assemblies will not build with a failed > dependency: > > BUILD FAILED > File.. /Users/codea/.maven/cache/geronimo-assembly-plugin-1.2.0-8/ > plugin.jelly > Element... assemble:installConfig > Line.. 190 > Column 145 > Dependency: incubator-activemq/activeio-core/3.0-SNAPSHOT/jar not > found in local maven repo: for configuration: geronimo/activemq- > broker/1.2-SNAPSHOT/car > > > thanks > Conrad > >
[jira] Updated: (GERONIMO-1790) Long Geronimo path and file names cause problems on Windows
[ http://issues.apache.org/jira/browse/GERONIMO-1790?page=all ] John Sisson updated GERONIMO-1790: -- Attachment: GERONIMO-1790.patch Patch to shorten names of nested files in ears. > Long Geronimo path and file names cause problems on Windows > --- > > Key: GERONIMO-1790 > URL: http://issues.apache.org/jira/browse/GERONIMO-1790 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: general > Versions: 1.1 > Environment: Windows of various flavors > Reporter: Joe Bohn > Assignee: Dain Sundstrom > Fix For: 1.1 > Attachments: GERONIMO-1790.patch > > The long path and file names causes a problem for windows users because by > default windows typically only allows paths of 256 bytes. JDK 1.4 itself has > a problem with the long path and file names (aided by embedded classes). > When using a root directory of greater than 12 characters we exceed the > windows default limit which results in fileIO exceptions. It's a fragile > situation since the addition of a new artifact could break us on windows at > any time by resulting in a path greater than 256 chars even with the normal > root directory of "geronimo".John Sisson has learned that this JDK > problem is fixed in JDK 1.5_06. That should alleviate the build problem (if > we get there before we had a hard break on JDK 1.4). > However, even when we get the build problem behind us with JDK 1.5_06 there > are still other utilities commonly used on Windows that will break with > longer path names. For example, Windows Explorer, the CMD shell, WinZip, > xcopy, etc... all seem to have problems with when we exceed 256 bytes for a > name. > Should we consider attempting to shorten our path names to avoid grief for > our windows users? While it is in fact an arbitrary limit, I think that most > people find particularly long path/file names distracting at the very least > and not very helpful. Is it worth enforcing some limits for ease of use as > well as to prevent problems on Windows? > For additional info see: > http://mail-archives.apache.org/mod_mbox/geronimo-dev/200601.mbox/[EMAIL > PROTECTED] > http://www.mail-archive.com/dev%40geronimo.apache.org/msg19834.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
1.2 build failing
Hi there, I know y'all are busy with 1.1 but does anyone have insight into this problem on trunk? The assemblies will not build with a failed dependency: BUILD FAILED File.. /Users/codea/.maven/cache/geronimo-assembly-plugin-1.2.0-8/ plugin.jelly Element... assemble:installConfig Line.. 190 Column 145 Dependency: incubator-activemq/activeio-core/3.0-SNAPSHOT/jar not found in local maven repo: for configuration: geronimo/activemq- broker/1.2-SNAPSHOT/car thanks Conrad
Re: m2 conversion : configurations
On Apr 19, 2006, at 6:51 AM, anita kulshreshtha wrote: Thanks. What criteria has been used to set the geronimo.dependency property in project.xml? The packaging of most configurations assumes the packaged configuration will be loaded on top of j2ee-system configuration. But the 'applications' configurations implicitly assume that a full server, i.e jetty/tomcat is running. Is this correct? yes. If yes, Should we add these configurations (specified by deploymnetConfig) to the plans for documentation? no Is this information stored in config.ser and the deployer makes sure that these are already loaded? yes. The secret is in the defaultEnvironment attributes of the various builders, which add the necessary parents for each type of j2ee artifact. For instance the jetty builder adds jetty, connector builder adds connector, etc etc. You can suppress these defaults in case you have special requirements by using the suppressDefaultEnvironment element in environment. In 1.0/1.2 this is not as well developed or consistent as in 1.1: the builders have attributes defaultParentId. thanks david jencks Thanks Anita --- David Jencks <[EMAIL PROTECTED]> wrote: On Apr 17, 2006, at 6:45 AM, anita kulshreshtha wrote: David, Thanks! How is j2ee-system configuration started now? j2ee-system is the "root" configuration of the main geronimo server, and the config.ser file is actually in server.jar. The Daemon locates it in the classpath and starts it, see line 251. The naming is slightly confusing. The server.jar contains j2ee-system configuraion and not j2ee-server. thanks david jencks Thanks Anita --- David Jencks <[EMAIL PROTECTED]> wrote: On Apr 16, 2006, at 9:20 AM, anita kulshreshtha wrote: The j2ee-security configuration imports only rmi-naming configuration. What about j2ee-server configuration? I think calling the server side security config j2ee-security might be misleading; perhaps we should call it server-security. In any case, it doesn't need anything from j2ee-server, so it doesn't import it. thanks david jencks Thanks Anita --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Apr 11, 2006, at 11:41 AM, Jacek Laskowski wrote: On 4/11/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: In 1.1, I moved the corba system properties into a new SystemProperties GBean in the j2ee-corba plan. Hi Dain, Will it be merged with trunk?If *I* wanted to merge it with trunk, should I try to figure out the revision by taking a look at j2ee-corba plan and commit these changes to trunk? sure -dain __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-1869) Percent complete goes over 100% when installing configurations
Percent complete goes over 100% when installing configurations -- Key: GERONIMO-1869 URL: http://issues.apache.org/jira/browse/GERONIMO-1869 Project: Geronimo Type: Bug Security: public (Regular issues) Components: core Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1 Looks like the UnpackArtifactTypeHandler counts the "uncompressed" bytes, whereas the % is based on the content size returned by the server for the download (the "compressed" byte count). Probably should use an InputStream between the download stream and the ZIP stream that performs the count on read(byte[],int,int) and them use that count instead of the uncompressed count. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: m2 conversion : configurations
Thanks. What criteria has been used to set the geronimo.dependency property in project.xml? The packaging of most configurations assumes the packaged configuration will be loaded on top of j2ee-system configuration. But the 'applications' configurations implicitly assume that a full server, i.e jetty/tomcat is running. Is this correct? If yes, Should we add these configurations (specified by deploymnetConfig) to the plans for documentation? Is this information stored in config.ser and the deployer makes sure that these are already loaded? Thanks Anita --- David Jencks <[EMAIL PROTECTED]> wrote: > > On Apr 17, 2006, at 6:45 AM, anita kulshreshtha wrote: > > > David, > > Thanks! How is j2ee-system configuration started now? > > j2ee-system is the "root" configuration of the main geronimo server, > > and the config.ser file is actually in server.jar. The Daemon > locates it in the classpath and starts it, see line 251. The naming is slightly confusing. The server.jar contains j2ee-system configuraion and not j2ee-server. > > thanks > david jencks > > > > > Thanks > > Anita > > > > --- David Jencks <[EMAIL PROTECTED]> wrote: > > > >> > >> On Apr 16, 2006, at 9:20 AM, anita kulshreshtha wrote: > >> > >>>The j2ee-security configuration imports only rmi-naming > >>> configuration. What about j2ee-server configuration? > >> > >> I think calling the server side security config j2ee-security > might > >> be misleading; perhaps we should call it server-security. In any > >> case, it doesn't need anything from j2ee-server, so it doesn't > import > >> > >> it. > >> > >> thanks > >> david jencks > >> > >>> > >>> Thanks > >>> Anita > >>> > >>> --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: > >>> > On Apr 11, 2006, at 11:41 AM, Jacek Laskowski wrote: > > > On 4/11/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > >> In 1.1, I moved the corba system properties into a new > >> SystemProperties GBean in the j2ee-corba plan. > > > > Hi Dain, > > > > Will it be merged with trunk?If *I* wanted to merge it with > >> trunk, > > should I try to figure out the revision by taking a look at > j2ee-corba > > plan and commit these changes to trunk? > > sure > > -dain > > >>> > >>> > >>> __ > >>> Do You Yahoo!? > >>> Tired of spam? Yahoo! Mail has the best spam protection around > >>> http://mail.yahoo.com > >> > >> > > > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Resolved: (GERONIMO-973) Add security to /console-standard
[ http://issues.apache.org/jira/browse/GERONIMO-973?page=all ] Aaron Mulder resolved GERONIMO-973: --- Fix Version: 1.1 Resolution: Fixed Applied to 1.1 > Add security to /console-standard > - > > Key: GERONIMO-973 > URL: http://issues.apache.org/jira/browse/GERONIMO-973 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.0-M5 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.2, 1.1 > Attachments: GERONIMO-973.patch > > Currently there are no web app security settings on /console-standard. > Either security needs to be added to it, or if that proves to be impossible, > it needs to be rolled into a single web app with /console -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMODEVTOOLS-78) Confusing Messages in Eclipse Plugin
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-78?page=all ] Sachin Patel resolved GERONIMODEVTOOLS-78: -- Resolution: Fixed Assign To: Sachin Patel This has been fixed in trunk. Additional validation and messages have been added. The VM validation method was incorrect and has been fixed as well. Thanks Arthur for helping test this! > Confusing Messages in Eclipse Plugin > > > Key: GERONIMODEVTOOLS-78 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-78 > Project: Geronimo-Devtools > Type: Bug > Components: eclipse-plugin > Environment: Eclipse WTP 1.0.2 RC2, Windows XP > Reporter: Arthur Ryman > Assignee: Sachin Patel > Attachments: new-server-runtime-jvm-warning.png, > new-server-runtime-missing-classpath-entry.png > > I was testing the Geronimo server adapter. The good news is that it works. > The bad news is that I had to struggle. There are two confusing messages on > the New Server Runtime wizard page. > 1. The "Application Server Installation Directory" field is a problem. It is > initially empty and the wizard displays the message "Missing classpath entry > \bin\server.jar". I though maybe I had to install the server so I tried to > click the "Download and Install" button, but it didn't click. I assume you > disabled it, but it wasn't grayed out so I thought there was a bug. Same for > the radio buttons to select Tomcat or Jetty. I was getting frustrated at this > point, so I thought maybe the missing jar was already downloaded with the > server adapter. I clicked the "Browse" button and went to the server adapter > plugin directory and select the lib directory. This didn't remove the > "missing classpath" message, but at least not that the directory field wasn't > empty, I could finally click the "Download and Install" button. > Please use a better message. If the directory field is empty, say "Please > enter the directory where Geronimo is currently installed or where you would > like it to be installed." > 2. After I downloaded Geronimo, the wizard displayed a warning message that > said only 1.4 JVMs were supported. However, I selected a 1.4 JVM, the IBM JDK > 1.4.2. I still got the warning. Please defect the JVM level and display the > correct message. > I attached screenshots. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1868) Calculate /console prefix dynamically for SVG, etc.
Calculate /console prefix dynamically for SVG, etc. --- Key: GERONIMO-1868 URL: http://issues.apache.org/jira/browse/GERONIMO-1868 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.2 The path to the console is hardcoded in svrInfoNormal.jsp and car/index.jsp right now. There's a method somewhere to calculate this (PortletManager?) and we should use it or something equivalent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
DayTrader Update
All, I have a working copy of the new DayTrader 1.1-SNAPSHOT. I placed it and the new plan at http://people.apache.org/~hogstrom/daytrader. Bill, I know you were having a problem and I didn't get back to you yesterday. I have to step out this morning but will be on this afternoon. Thanks, Matt
Re: G1.1 - Compilation errors in Connector module
Once again, I'm not having the problem. All I can recommend is "svn up && cd openejb && svn up && cd .. && maven -o clean new". If you do it right now you'll get a test failure in the kernel module -- just build that module without tests enabled until the problem is fixed (it's a little test-first development :) Thanks, Aaron On 4/19/06, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: > Aaron, > > Connector module builds fine this time. I am still not able to build > successfully :o(. Build error is given below. > > + > | configurations System Configuration for the J2EE Server > | Memory: 32M/45M > + > DEPRECATED: the default goal should be specified in the section of > proje > ct.xml instead of maven.xml > DEPRECATED: the default goal should be specified in the section of > proje > ct.xml instead of maven.xml > > build:end: > > You are working offline so the build will continue, but > geronimo-gbean-deployer- > 1.1-SNAPSHOT.car may be out of date! > build:start: > > multiproject:install-callback: > [echo] Running car:install for System Configuration for the J2EE Server > > Packaging configuration > C:\g11\configs\j2ee-system\target\plan\plan.xml > > 0 [main] DEBUG > org.apache.geronimo.kernel.basic.BasicKernel - Starting > boot > 731 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanInstanceState - > GBeanIn > stanceState for: geronimo/boot/none/car?role=kernel State > changed from stopped t > o starting > 741 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanInstanceState - > GBeanIn > stanceState for: geronimo/boot/none/car?role=kernel State > changed from starting > to running > 741 [main] DEBUG > org.apache.geronimo.kernel.basic.BasicKernel - Booted > 851 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanInstanceState - > GBeanIn > stanceState for: > geronimo/packaging/fixed/car?configurationName=geronimo/packagi > ng/fixed/car State changed from stopped to starting > 851 [main] DEBUG > org.apache.geronimo.kernel.config.Configuration - > ClassPath fo > r geronimo/packaging/fixed/car resolved to [] > 861 [main] DEBUG > org.apache.geronimo.kernel.config.Configuration - Started > conf > iguration geronimo/packaging/fixed/car > 861 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanInstanceState - > GBeanIn > stanceState for: > geronimo/packaging/fixed/car?configurationName=geronimo/packagi > ng/fixed/car State changed from starting to running > 961 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanInstanceState - > GBeanIn > stanceState for: > geronimo/packaging/fixed/car?j2eeType=ConfigurationStore,name=C > onfigStore State changed from stopped to starting > 961 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanSingleReference - > Waiti > ng to start > geronimo/packaging/fixed/car?j2eeType=ConfigurationStore,name=Config > Store because no targets are running for reference Repository matching the > patte > rns > geronimo/packaging/fixed/car?j2eeType=Repository,name=Repository > 961 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanInstanceState - > GBeanIn > stanceState for: > geronimo/packaging/fixed/car?j2eeType=ArtifactResolver,name=Art > ifactResolver State changed from stopped to starting > 1021 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanSingleReference - > Wait > ing to start > geronimo/packaging/fixed/car?j2eeType=ArtifactResolver,name=Artifac > tResolver because no targets are running for reference ArtifactManager > matching > the patterns > geronimo/packaging/fixed/car?j2eeType=ArtifactManager,name=Artifact > Manager > 1021 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanInstanceState - > GBeanI > nstanceState for: > geronimo/packaging/fixed/car?j2eeType=ArtifactManager,name=Art > ifactManager State changed from stopped to starting > 1021 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanInstanceState - > GBeanI > nstanceState for: > geronimo/packaging/fixed/car?j2eeType=ArtifactManager,name=Art > ifactManager State changed from starting to running > 1021 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanInstanceState - > GBeanI > nstanceState for: > geronimo/packaging/fixed/car?j2eeType=ConfigurationManager,nam > e=ConfigManager State changed from stopped to starting > 1092 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanSingleReference - > Wait > ing to start > geronimo/packaging/fixed/car?j2eeType=ConfigurationManager,name=Con > figManager because no targets are running for reference ArtifactResolver > matchin > g the patterns > geronimo/packaging/fixed/car?j2eeType=ArtifactResolver,name=Artif > actResolver > 1092 [main] DEBUG > org.apache.geronimo.gbean.runtime.GBeanSingleReference - > Wait > ing to start > geronimo/packaging/fixed/car?j2eeType=ConfigurationManager,name=Con > figManager because no targets are running for reference AttributeStore > matching
Re: G1.1 - Compilation errors in Connector module
Aaron, Connector module builds fine this time. I am still not able to build successfully :o(. Build error is given below. + | configurations System Configuration for the J2EE Server | Memory: 32M/45M + DEPRECATED: the default goal should be specified in the section of proje ct.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of proje ct.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-gbean-deployer- 1.1-SNAPSHOT.car may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for System Configuration for the J2EE Server Packaging configuration C:\g11\configs\j2ee-system\target\plan\plan.xml 0 [main] DEBUG org.apache.geronimo.kernel.basic.BasicKernel - Starting boot 731 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanIn stanceState for: geronimo/boot/none/car?role=kernel State changed from stopped t o starting 741 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanIn stanceState for: geronimo/boot/none/car?role=kernel State changed from starting to running 741 [main] DEBUG org.apache.geronimo.kernel.basic.BasicKernel - Booted 851 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanIn stanceState for: geronimo/packaging/fixed/car?configurationName=geronimo/packagi ng/fixed/car State changed from stopped to starting 851 [main] DEBUG org.apache.geronimo.kernel.config.Configuration - ClassPath fo r geronimo/packaging/fixed/car resolved to [] 861 [main] DEBUG org.apache.geronimo.kernel.config.Configuration - Started conf iguration geronimo/packaging/fixed/car 861 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanIn stanceState for: geronimo/packaging/fixed/car?configurationName=geronimo/packagi ng/fixed/car State changed from starting to running 961 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanIn stanceState for: geronimo/packaging/fixed/car?j2eeType=ConfigurationStore,name=C onfigStore State changed from stopped to starting 961 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanSingleReference - Waiti ng to start geronimo/packaging/fixed/car?j2eeType=ConfigurationStore,name=Config Store because no targets are running for reference Repository matching the patte rns geronimo/packaging/fixed/car?j2eeType=Repository,name=Repository 961 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanIn stanceState for: geronimo/packaging/fixed/car?j2eeType=ArtifactResolver,name=Art ifactResolver State changed from stopped to starting 1021 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanSingleReference - Wait ing to start geronimo/packaging/fixed/car?j2eeType=ArtifactResolver,name=Artifac tResolver because no targets are running for reference ArtifactManager matching the patterns geronimo/packaging/fixed/car?j2eeType=ArtifactManager,name=Artifact Manager 1021 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanI nstanceState for: geronimo/packaging/fixed/car?j2eeType=ArtifactManager,name=Art ifactManager State changed from stopped to starting 1021 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanI nstanceState for: geronimo/packaging/fixed/car?j2eeType=ArtifactManager,name=Art ifactManager State changed from starting to running 1021 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanI nstanceState for: geronimo/packaging/fixed/car?j2eeType=ConfigurationManager,nam e=ConfigManager State changed from stopped to starting 1092 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanSingleReference - Wait ing to start geronimo/packaging/fixed/car?j2eeType=ConfigurationManager,name=Con figManager because no targets are running for reference ArtifactResolver matchin g the patterns geronimo/packaging/fixed/car?j2eeType=ArtifactResolver,name=Artif actResolver 1092 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanSingleReference - Wait ing to start geronimo/packaging/fixed/car?j2eeType=ConfigurationManager,name=Con figManager because no targets are running for reference AttributeStore matching the patterns geronimo/packaging/fixed/car?j2eeType=GBean,name=AttributeStore 1092 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - Checki ng if parent is running: parent=geronimo/packaging/fixed/car?configurationName=g eronimo/packaging/fixed/car 1092 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - Parent is running: parent=geronimo/packaging/fixed/car?configurationName=geronimo/pack aging/fixed/car 1092 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanI nstanceState for: geronimo/packaging/fixed/car?j2eeType=ArtifactResolver,name=Ar tifactResolver State changed from starting to running 1092 [main] DEBUG org.apache.geronimo.gbean.runtime.GBea
Re: Browsing G 1.1 using jconsole
Great! I am assuming that jconsole does not allow modifying the attributes of a tomcat Mbean as allowed by the tomcat Manager application. http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html#Using%20the%20JMX%20Proxy%20Servlet Thanks Anita --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: > I fixed a number of bugs around our JMX integration in G 1.1 today, > and you can now browse the Geronimo server using jconsole in Java 5. > > You will see all GBeans and the tomcat MBeans (assuming you are using > > tomcat). I use the following command to connect to the server: > >jconsole service:jmx:rmi:///jndi/rmi://localhost:1099/JMXConnector > > For all of you on macs out there the java 5 jconsole command is > located at /System/Library/Frameworks/JavaVM.framework/Versions/1.5/ > Home/bin/jconsole > > There are a few annoying error messages logged to the console, and if > > I have some time I'll try to eliminate them. > > -dain > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Apache Geronimo quarterly report for 2006-04
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This report covers the period from 2006-01-18 through 2006-04-18. Activity: - - Presentations about Apache Geronimo were given variously by Dain Sundstrom, Aaron Mulder, Matt Hogstrom, and Jeff at JAOO and The Server Side Symposium. A lot of work went into giving the Geronimo Web a major facelift. The issue of having a Confluence wiki hosted on Apache hardware was raised again, since the vast majority of opinions polled on the dev list favoured keeping the Geronimo documentation in that format. Some progress has been made, but at the moment the documentation is still hosted at a third-party Confluence installation offsite. In this period, 422 JIRA issues were created, 205 were closed, and 14 closed ones were reopened. (The reopened ones were not necessarily closed during this interval.) PMC: - Jason Dillon and Kevan Lee Miller were invited to join the PMC, and both accepted. A number of individuals who have been given commit karma in the past have subsequently largely disappeared from the project. Although the PMC hasn't yet decided what to do about that sort of situation, it has been a major factor in several PMC members' opinions that an invitation to join the PMC should not be considered for some indefinite interval after karma has been granted. Since I personally disagree strongly with that position and am not satisfied that anyone has identified any harmful effects, I do not consider the issue yet closed. Although the subject of project bylaws/guidelines has come up several times, and various people are ruminating on the issue, no concrete progress has been made on that front. Committers: - --- The PMC voted to offer commit karma to Hernan Cunico, and he accepted. There are other karma votes currently in progress. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBREYaTJrNPMCpn3XdAQKIDQP9FYwj9sDA4qzdVZWKRZjamREYUmPS0wAY G7Yr4itlYQnVyeslvHo3voxCvYaOtwjIBO6r5WppnLkyL08B/E0F2wyE28Ep/r+p rPlyP8Sa1nXj7pTj23unkYG3VTCa5Lg2XO+TU0bmldXpA7tm/UJTn5MkkhysB0IF kyj6DEVMrB8= =42OB -END PGP SIGNATURE-
RE: openwire-cpp question
This code compiles and runs on GCC 3, GCC 4 and Visual Studio 2005. We have never tried to compile it with Sun compiler. The code is tested and can communicate with text messages with the broker (as our test code does). Hope to get the time to make the code compile with more C++ compilers as soon as we get to a point where the code becomes complete. David -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: den 18 april 2006 23:37 To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hi David, I tried that code earlier and ran in to build issues, there are lots of things in this code what Sun Compiler didn't liked. Is this code tested? Thanks! Vik -Original Message- From: David Fahlander [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 18, 2006 2:55 AM To: activemq-dev@geronimo.apache.org Cc: Mats Forslöf Subject: RE: openwire-cpp question The latest code is of the openwire cpp client was uploaded as a jira patch at http://issues.apache.org/activemq/browse/AMQ-656. The latest version is called "source 060406.zip". It contains the full source tree as well as make files and a test program. /David -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 17 april 2006 17:28 To: activemq-dev@geronimo.apache.org Cc: Mats Forslöf Subject: RE: openwire-cpp question Hi Mats, Is the code in svn your latest? I remember you including unit tests and makefiles at some point - did these get lost when the last patch was applied? -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 11:08 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question There is no test stub either. I am wondering if someone ever tested it? Vik -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 11:01 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hmm ... that surprises me - I know the openwire-cpp team had included makefiles in the past. I believe the code should support linux, windows, & OSX. Does anyone know where the makefiles are? -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 10:08 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hey Nate, I don't see any make file or something in there? Do you have any idea what O/S version and C++ complier this code recommends? Thanks! Vik -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 6:16 AM To: activemq-dev@geronimo.apache.org Subject: Re: openwire-cpp question The latter - It's a client-side library. The same is true for the Stomp CMS lib and the openwire .NET lib. Regards, Nate On 4/16/06, vik Dhawan <[EMAIL PROTECTED]> wrote: > > > I wanted to know the use of Development branch on SVN at > http://svn.apache.org/repos/asf/incubator/activemq/trunk/openwire-cpp/ > > Is this a C++ implementation of ActiveMQ? is it complete? or is it can be > used as a C++ library so some application can use classes in this library > to > connect to a remote AMQ server? > > Thanks! > > > -- > View this message in context: > http://www.nabble.com/openwire-cpp-question-t1459989.html#a3945792 > Sent from the ActiveMQ - Dev forum at Nabble.com. > >
[jira] Updated: (GERONIMO-1425) access to unprotected web resource after login does not use correct Subject
[ http://issues.apache.org/jira/browse/GERONIMO-1425?page=all ] David Jencks updated GERONIMO-1425: --- Fix Version: 1.1 patch ported to 1.1 in rev 395178 > access to unprotected web resource after login does not use correct Subject > --- > > Key: GERONIMO-1425 > URL: http://issues.apache.org/jira/browse/GERONIMO-1425 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: Tomcat, web > Versions: 1.2 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.2, 1.1 > > This applies to both jetty and tomcat. > Currently we are installing the correct authenticated Subject in > ContextManager only when you access a protected resource. For any access to > unprotected resources, even after logon, we are installing the default > Subject in the ContextManager. This appears to violate this from servlet > spec 2.4 12.7: > A security identity, or principal, must always be provided for use in a call > to an enterprise bean. The default mode in calls to enterprise beans from web > applications is for the security identity of a web user to be propagated to > the EJBTM container. > After logon, the security identity of the user is known, whether or not they > are visiting a protected resource. Therefore the default is to use this > identity in ejb calls, which for us requires putting the authenticated > subject in the ContextManager. > Alan Cabrera has some doubts that this spec language actually requires us to > implement the default behavior stated here, and I agree that a strict reading > does not seem to require this, but IIUC we agree that we should implement > this behavior anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
