[jira] Resolved: (SM-731) Unable to run ServiceMix server from Eclipse IDE
[ https://issues.apache.org/activemq/browse/SM-731?page=all ]
Eduardo de Vera resolved SM-731.
Resolution: Fixed
As mentioned on the issue, this is solved by changing the mentioned windows
style directory separator from backslashes to normal slashes On the
eclipse/plugins/com.logicblaze.jst.server.servicemix.core_0.1.0/servers/servicemix30.serverdef.xml
configuration file, right at the vmParameters tag.
Unable to run ServiceMix server from Eclipse IDE
Key: SM-731
URL: https://issues.apache.org/activemq/browse/SM-731
Project: ServiceMix
Issue Type: Bug
Components: tooling
Environment: MAC OS X
Eclipse 3.2
WTP 1.5.1
Reporter: Eduardo de Vera
I was unable to run the ServiceMix server by default since the virtual
machine parameters were using the windows notation of directories. According
to the servicemix30.serverdef.xml file found under the
com.logicblaze.jst.server.servicemix.core_0.1.0/servers plugin directory the
Virtual Machine Parameters are:
vmParameters
-Xms128m
-Dclassworlds.conf=${serverRootDirectory}\conf\servicemix.conf
-Xmx512m
-Djava.endorsed.dirs=${serverRootDirectory}\lib\endorsed
-Dservicemix.home=${serverRootDirectory}
/vmParameters
changing the windows style backslash to a normal slash (\ to /) on the
configuration makes the service mix server work on Unix type Operating
Systems (I have tried it on both, my Mac OS X and my SuSe Linux).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
ServiceMix 3.1
Hi, I'm trying to find a snapshot for servicemix 3.1, I went to the downloads section of servicmix.org and clicked the snapshot link (http://people.apache.org/repo/m2-snapshot-repository/org/apache/servicemix/apache-servicemix/3.1-incubating-SNAPSHOT/) and the link was broken. Can you let me know where I can go to download ServiceMix 3.1 -- View this message in context: http://www.nabble.com/ServiceMix-3.1-tf2553558.html#a7115202 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Why is the activemq.car using the tcp transport?
On Oct 31, 2006, at 10:06 PM, Jason Dillon wrote:
Do client-side consumers use the activemq.car? I really don't know
where this is used... if it is for clients, then I can
understand... but if this is only used in the server, then it
should use the vm:// transport for efficiency.
This is a rar configuration bit, so it is local to the vm it is
installed in. since this is a server side car, it's going to be
running in the server, and connecting to the broker running in the
same vm. Therefore I think that vm transport is appropriate. I have
a vague recollection that when we first got the tck jms tests to pass
the vm transport didn't really work so we used tcp even locally.
Hopefully this is now fixed.
To use jms in a j2ee app client you need to install the rar in the
app client: we don't ship a car for this (although there's one in the
tck setup), and this would have to use tcp unless you wanted to
run a broker in the app client.
thanks
david jencks
--jason
On Oct 31, 2006, at 9:55 PM, Bruce Snyder wrote:
On 10/31/06, Jason Dillon [EMAIL PROTECTED] wrote:
Its currently configured with:
config-property-setting name=ServerUrltcp://$
{PlanServerHostname}:
${PlanActiveMQPort}/config-property-setting
If this resourceadapter is used with in the server, then it should
use the vm:// transport.
Anyone know?
I'm not sure, but I hazard a guess that this was so that client-side
consumers can connect to ActiveMQ. If a vm:// transport is used, then
ActiveMQ is not exposed outside the JVM.
Bruce
--
perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED
\!G;6%I;\YC;VT*
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Why is the activemq.car using the tcp transport?
So, the activemq.car is used to make jms connections for mdbs and
other jms resources?
--jason
On Nov 1, 2006, at 12:13 AM, David Jencks wrote:
On Oct 31, 2006, at 10:06 PM, Jason Dillon wrote:
Do client-side consumers use the activemq.car? I really don't
know where this is used... if it is for clients, then I can
understand... but if this is only used in the server, then it
should use the vm:// transport for efficiency.
This is a rar configuration bit, so it is local to the vm it is
installed in. since this is a server side car, it's going to be
running in the server, and connecting to the broker running in the
same vm. Therefore I think that vm transport is appropriate. I
have a vague recollection that when we first got the tck jms tests
to pass the vm transport didn't really work so we used tcp even
locally. Hopefully this is now fixed.
To use jms in a j2ee app client you need to install the rar in the
app client: we don't ship a car for this (although there's one in
the tck setup), and this would have to use tcp unless you
wanted to run a broker in the app client.
thanks
david jencks
--jason
On Oct 31, 2006, at 9:55 PM, Bruce Snyder wrote:
On 10/31/06, Jason Dillon [EMAIL PROTECTED] wrote:
Its currently configured with:
config-property-setting name=ServerUrltcp://$
{PlanServerHostname}:
${PlanActiveMQPort}/config-property-setting
If this resourceadapter is used with in the server, then it should
use the vm:// transport.
Anyone know?
I'm not sure, but I hazard a guess that this was so that client-side
consumers can connect to ActiveMQ. If a vm:// transport is used,
then
ActiveMQ is not exposed outside the JVM.
Bruce
--
perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED
\!G;6%I;\YC;VT*
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Why is the activemq.car using the tcp transport?
On Nov 1, 2006, at 12:19 AM, Jason Dillon wrote:
So, the activemq.car is used to make jms connections for mdbs and
other jms resources?
yes. It's kind of near-useless except as an example since it doesn't
include any admin objects (queues or topics) any real app is going to
use. As an example of how do use j2ee-jms it's fine.
thanks
david jencks
--jason
On Nov 1, 2006, at 12:13 AM, David Jencks wrote:
On Oct 31, 2006, at 10:06 PM, Jason Dillon wrote:
Do client-side consumers use the activemq.car? I really don't
know where this is used... if it is for clients, then I can
understand... but if this is only used in the server, then it
should use the vm:// transport for efficiency.
This is a rar configuration bit, so it is local to the vm it is
installed in. since this is a server side car, it's going to
be running in the server, and connecting to the broker running in
the same vm. Therefore I think that vm transport is appropriate.
I have a vague recollection that when we first got the tck jms
tests to pass the vm transport didn't really work so we used tcp
even locally. Hopefully this is now fixed.
To use jms in a j2ee app client you need to install the rar in the
app client: we don't ship a car for this (although there's one in
the tck setup), and this would have to use tcp unless you
wanted to run a broker in the app client.
thanks
david jencks
--jason
On Oct 31, 2006, at 9:55 PM, Bruce Snyder wrote:
On 10/31/06, Jason Dillon [EMAIL PROTECTED] wrote:
Its currently configured with:
config-property-setting name=ServerUrltcp://$
{PlanServerHostname}:
${PlanActiveMQPort}/config-property-setting
If this resourceadapter is used with in the server, then it should
use the vm:// transport.
Anyone know?
I'm not sure, but I hazard a guess that this was so that client-
side
consumers can connect to ActiveMQ. If a vm:// transport is used,
then
ActiveMQ is not exposed outside the JVM.
Bruce
--
perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-
N61ED\!G;6%I;\YC;VT*
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Deployment Plan -geronimo-web.xml
Hi All Now the geronimo deployment plan for web application is ready for users.Please find the location here with, http://cwiki.apache.org/GMOxDOC11/geronimo-webxml.html Through this documents I tried to achieve to provide an better understanding to the user in different areas of deploying web application in geronimo.But this is a very dynamic topic and there are tons of work can be done to improve this.We have used open office draw for certain images to represent xml graphical representation.Because I don't have proper licencing to used any other proprietary tool for this.So I added just a one image under common references.If xml graphical representation adds more meaningful to the doc we can follow the same in the rest of the document. Your comments ,thoughts and contributions are always welcome to make this better. Simultaneously I'm working in the other deployment plans as well.Those will be separated documents per each and will follow the similar approach for the content . I would like to have your feed back as input to make the other deployment plans better.Therefore following documentations are presently underconstruction and will be available soon for users. openejb-jar.xml geronimo-ra.xml geronimo-application.xml geronimo-application-client.xml Untill I have added the http://cwiki.apache.org/GMOxDOC11/deployment-plans-level-1.html page under deployment plans which discusses very primary level of deployment plans for geronimo.May be we can discuss to remove this later when all the deployment plans are ready. Thanks and Regards Kanchana
[jira] Created: (SM-730) Unable to run Maven from Fuse Tooling with Unix based systems (MAC OS X and SuSe Linux 10)
Unable to run Maven from Fuse Tooling with Unix based systems (MAC OS X and SuSe Linux 10) -- Key: SM-730 URL: https://issues.apache.org/activemq/browse/SM-730 Project: ServiceMix Issue Type: Bug Components: tooling Environment: MAC OS X JDK 1.5 Eclipse 3.2 WTP 1.5.1 Reporter: Eduardo de Vera I am unable to run any of the maven goals by hand using the menu option Build phase not Apache Maven. I get the following error: Exception in thread main java.lang.NoClassDefFoundError: org/maven/ide/eclipse/Maven2Executor I have search for that class on the plugins directory of eclipse and it exists, and the funny thing is that when I start the eclipse IDE, it seems to be executing maven since it tries to download and refresh artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-731) Unable to run ServiceMix server from Eclipse IDE
Unable to run ServiceMix server from Eclipse IDE
Key: SM-731
URL: https://issues.apache.org/activemq/browse/SM-731
Project: ServiceMix
Issue Type: Bug
Components: tooling
Environment: MAC OS X
Eclipse 3.2
WTP 1.5.1
Reporter: Eduardo de Vera
I was unable to run the ServiceMix server by default since the virtual machine
parameters were using the windows notation of directories. According to the
servicemix30.serverdef.xml file found under the
com.logicblaze.jst.server.servicemix.core_0.1.0/servers plugin directory the
Virtual Machine Parameters are:
vmParameters
-Xms128m
-Dclassworlds.conf=${serverRootDirectory}\conf\servicemix.conf
-Xmx512m
-Djava.endorsed.dirs=${serverRootDirectory}\lib\endorsed
-Dservicemix.home=${serverRootDirectory}
/vmParameters
changing the windows style backslash to a normal slash (\ to /) on the
configuration makes the service mix server work on Unix type Operating Systems
(I have tried it on both, my Mac OS X and my SuSe Linux).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2515) load of geronimo/rmi-naming/1.1.1/car failed on Solaris 10
[ http://issues.apache.org/jira/browse/GERONIMO-2515?page=comments#action_12446235 ] K Wesley commented on GERONIMO-2515: I will install 1.4.2 today. The default on solaris 10 is 1.5 load of geronimo/rmi-naming/1.1.1/car failed on Solaris 10 -- Key: GERONIMO-2515 URL: http://issues.apache.org/jira/browse/GERONIMO-2515 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 1.1.1 Environment: Solaris 10 , JDK 1.5.0_01 Reporter: K Wesley Priority: Blocker $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.5.0_01)... Starting Geronimo Application Server v1.1.1 [*-] 0% 2s Startup failed org.apache.geronimo.kernel.config.LifecycleException: load of geronimo/rmi-naming/1.1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:294) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:275) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:250) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$7c7a552c.loadConfiguration(generated) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:294) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377) Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency org.apache.geronimo.specs/geronimo-activation_1.0.2_spec//jar at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:119) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:98) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver$$FastClassByCGLIB$$e847b746.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.repository.ArtifactResolver$$EnhancerByCGLIB$$c9e2351.resolveInClassLoader(generated) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.resolveParentIds(SimpleConfigurationManager.java:466) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadDepthFirst(SimpleConfigurationManager.java:425) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:291) ... 15 more Server shutdown begun Server shutdown completed -- 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-2526) Set J2EEApplication and J2EEServer for tomcat MBeans
[ http://issues.apache.org/jira/browse/GERONIMO-2526?page=all ] Anita Kulshreshtha updated GERONIMO-2526: - Attachment: tomcat.patch This patch sets the value of J2EEApplication and J2EEServer for tomcat WebModule MBeans. The servlet MBeans now have their J2EEApplication set correctly. The WebModule setting in :.,J2EEType=WebModule,name=/host/context and :.WebModule=/host/context,J2EEType=Servlet,name=. can not be changed, because it is constructed by StandardContext. AFAICT this is not something tomcat folks would want to change for us. Currently JSR77 query will find only one MBean/GBean because the Domain for Mbeans is set to Geronimo. I am tempted to set the domain to 'geronimo'. This will merge tomcat MBeans and GBeans and make them indistinguishable. The disadvantage is that the two WebModules will get listed next to each other. I have run into problems in changing the domain to 'geronimo' http://www.nabble.com/Re%3A-Geronimo-jmx-question-p7074904.html. I am leaving it until I find a way to do this right. The advantage of setting this is that the servlets can be accessed by geronimo:...J2EEType=Servlet, I am also looking at wrapping StandardWrapper .. Suggestions? If there are no comments, I will comit this after 24 hours. Set J2EEApplication and J2EEServer for tomcat MBeans Key: GERONIMO-2526 URL: http://issues.apache.org/jira/browse/GERONIMO-2526 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Priority: Minor Attachments: tomcat.patch From a discussion on the list http://www.nabble.com/Fairly-big-problem-with-tomcat-integration-tf1574249.html#a4274316: Set J2EEApplication and J2EEServer for WebModule and hence the servlets. The servlet Mbeans have names like: Geronimo:j2eeType=Servlet,name=ServerManager,WebModule=//0.0.0.0/console-standard, J2EEApplication=org.apache.geronimo.configs/webconsole-tomcat/1.2-SNAPSHOT/car,J2EEServer=geronimo TODO - Find a way to set WebModule -- 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: Problem with latest 4.1 SNAPSHOT when broker name is set
Yep.. looks like problem with the CommandAgent. The
vm://${brokerName} connector will start up a broker named
${brokerName} if it is not already running. I just need to adjust the
start up code so that the command agent is set with the right
connection URI.
On 11/1/06, Jason Dillon [EMAIL PROTECTED] wrote:
Folks, there is a problem with the latest 4.1 SNAPSHOT when a broker
name is set. It causes 2 brokers to be created... and I think it is
because of the newly added CommandAgent service which is added to the
brokers default services when started. It is using vm://localhost,
which appears to be creating a new Broker using the name localhost
when the broker it is attached to has a different name.
For example:
snip
BrokerService broker = new BrokerService();
broker.setBrokerName(foo);
broker.start();
/snip
Will end up creating a broker name foo and then another named
localhost.
Where, this will create one broker, named localhost:
snip
BrokerService broker = new BrokerService();
broker.start();
/snip
I'm not really sure how vm://* works with respect to broker names...
so I can not say for sure what the fix is, or why this is happening.
But I can say for sure that the above snips create 2 and 1 brokers
respectively.
We noticed this while trying to track down a rouge activemq-data
directory which kept popping up in Geronimo, which for some reason
had its broker gbean set to create a broker with the name possibly-
unique-broker. I've fixed this by only setting the broker name if
it is non-null, and then commenting out the brokerName attributed in
the plan, but something is definitely broke on your side of the fence
wrt broker names and vm:// transports.
--jason
--
Regards,
Hiram
Blog: http://hiramchirino.com
[jira] Commented: (GERONIMO-2526) Set J2EEApplication and J2EEServer for tomcat MBeans
[ http://issues.apache.org/jira/browse/GERONIMO-2526?page=comments#action_12446243 ] Jeff Genender commented on GERONIMO-2526: - This patch looks ok to me. Set J2EEApplication and J2EEServer for tomcat MBeans Key: GERONIMO-2526 URL: http://issues.apache.org/jira/browse/GERONIMO-2526 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Priority: Minor Attachments: tomcat.patch From a discussion on the list http://www.nabble.com/Fairly-big-problem-with-tomcat-integration-tf1574249.html#a4274316: Set J2EEApplication and J2EEServer for WebModule and hence the servlets. The servlet Mbeans have names like: Geronimo:j2eeType=Servlet,name=ServerManager,WebModule=//0.0.0.0/console-standard, J2EEApplication=org.apache.geronimo.configs/webconsole-tomcat/1.2-SNAPSHOT/car,J2EEServer=geronimo TODO - Find a way to set WebModule -- 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-2526) Set J2EEApplication and J2EEServer for tomcat MBeans
[ http://issues.apache.org/jira/browse/GERONIMO-2526?page=comments#action_12446247 ] Anita Kulshreshtha commented on GERONIMO-2526: -- Thanks Jeff! Anita Jeff Genender (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2526?page=comments#action_12446243 ] Jeff Genender commented on GERONIMO-2526: - This patch looks ok to me. -- 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 - Access over 1 million songs - Yahoo! Music Unlimited Try it today. Set J2EEApplication and J2EEServer for tomcat MBeans Key: GERONIMO-2526 URL: http://issues.apache.org/jira/browse/GERONIMO-2526 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Priority: Minor Attachments: tomcat.patch From a discussion on the list http://www.nabble.com/Fairly-big-problem-with-tomcat-integration-tf1574249.html#a4274316: Set J2EEApplication and J2EEServer for WebModule and hence the servlets. The servlet Mbeans have names like: Geronimo:j2eeType=Servlet,name=ServerManager,WebModule=//0.0.0.0/console-standard, J2EEApplication=org.apache.geronimo.configs/webconsole-tomcat/1.2-SNAPSHOT/car,J2EEServer=geronimo TODO - Find a way to set WebModule -- 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: [jira] Commented: (GERONIMO-2526) Set J2EEApplication and J2EEServer for tomcat MBeans
>From where did Access over 1 million songs - Yahoo! Music Unlimited Try it today. creep into the JIRA comment??? --vamsiOn 11/1/06, Anita Kulshreshtha (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2526?page=comments#action_12446247 ]Anita Kulshreshtha commented on GERONIMO-2526: --Thanks Jeff!AnitaJeff Genender (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2526?page=comments#action_12446243 ]Jeff Genender commented on GERONIMO-2526:-This patch looks ok to me. --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-Access over 1 million songs - Yahoo! Music Unlimited Try it today. Set J2EEApplication and J2EEServer for tomcat MBeans Key: GERONIMO-2526 URL: http://issues.apache.org/jira/browse/GERONIMO-2526 Project: GeronimoIssue Type: BugSecurity Level: public(Regular issues) Components: TomcatAffects Versions: 1.2 Environment: AllReporter: Anita Kulshreshtha Assigned To: Anita KulshreshthaPriority: Minor Attachments: tomcat.patch From a discussion on the list http://www.nabble.com/Fairly-big-problem-with-tomcat-integration-tf1574249.html#a4274316 : SetJ2EEApplication and J2EEServer for WebModule and hence the servlets. The servlet Mbeans have names like: Geronimo:j2eeType=Servlet,name=ServerManager,WebModule=//0.0.0.0/console-standard, J2EEApplication=org.apache.geronimo.configs/webconsole-tomcat/1.2-SNAPSHOT/car,J2EEServer=geronimo TODO - Find a way to set WebModule--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: 1.2 Fit and Finish
One of the activities to coordinate when finalizing the release is updating the 1.2 plugin repository catalog at: http://geronimo.apache.org/plugins/geronimo-1.2/geronimo-plugins.xml to point at a repo where the 1.2 artifacts are published instead of the snapshot repo it currently points at. For testing purposes it would be ideal to build Geronimo as version 1.2 (not 1.2rc1 or 1.2.timestamp or something like that) and publish the 1.2 artifacts to a maven2 repo during the release candidate cycle. That would allow us to test the plugin system in pretty much the exact state it will be when 1.2 is released. Is that feasible? If not then we may need to work out an alternate approach where the repository catalog gets updated after the release goes out and the artifacts get published. That makes me a little nervous though since it will be too late to make changes to the server if something doesn't work right. Best wishes, Paul On 10/30/06, Dain Sundstrom [EMAIL PROTECTED] wrote: In a typical Geronimo release we tend to spend a significant amount of time in what I'll call the Fit and Finish phase. This involves tying up loose ends such as log levels, tools LF, startup times, licenses and so on. Basically, the phase includes fixing all the nits that cause people to vote -1 for a release (BTW no vetos in a release vote). Please, take a moment and respond to this email with any items you feel should be cleaned up before we release the software. That way we can hopefully get these items out in the open and addressed while we are finishing the TCK testing. Please note that just because an item is mentioned doesn't mean it must be completed before a release. The only thing required for a release it to successfully pass a vote of the PMC, so if the item is critical to you, spend a few minutes fixing it. With any luck we should be able to have the server ready to ship about the same time we finish the TCK testing. -dain
[jira] Closed: (GERONIMO-2486) All plans should use 1.2 namespace
[ http://issues.apache.org/jira/browse/GERONIMO-2486?page=all ] Anita Kulshreshtha closed GERONIMO-2486. Fix Version/s: 1.2 Resolution: Fixed All plans should use 1.2 namespace -- Key: GERONIMO-2486 URL: http://issues.apache.org/jira/browse/GERONIMO-2486 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Priority: Minor Fix For: 1.2 Attachments: configs.patch, pom.patch The plans are still using 1.1 namespace. Here is an example: module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; gbean name=WebServiceBuilder class=org.apache.geronimo.axis.builder.AxisBuilder/ gbean name=AxisServiceRefBuilder class=org.apache.geronimo.axis.builder.AxisServiceRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ns/j2ee/attribute xml-attribute name=defaultEnvironment environment xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; All plans must be updated to use 1.2 namespace. -- 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-2507) Starting the webconsole config is taking *way* too much time
[ http://issues.apache.org/jira/browse/GERONIMO-2507?page=comments#action_12446261 ] Anita Kulshreshtha commented on GERONIMO-2507: -- The geronimo-jetty-j2ee server is taking 88s vs 33s for geronimo-tomcat-j2ee. Starting the webconsole config is taking *way* too much time Key: GERONIMO-2507 URL: http://issues.apache.org/jira/browse/GERONIMO-2507 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Kevan Miller Priority: Critical Fix For: 1.2 Server startup time of 1.2 has more than doubled. The vast majority of time is being spent starting the webconsole config. -- 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-2515) load of geronimo/rmi-naming/1.1.1/car failed on Solaris 10
[ http://issues.apache.org/jira/browse/GERONIMO-2515?page=all ] K Wesley updated GERONIMO-2515: --- Description: $ java -jar server.jar Booting Geronimo Kernel (in Java 1.4.2_12)... Starting Geronimo Application Server v1.1.1 [*-] 0% 2s Startup failed org.apache.geronimo.kernel.config.LifecycleException: load of geronimo/rmi-naming/1.1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:294) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:275) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:250) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$fe617d34.loadConfiguration(generated) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:294) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377) Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency org.apache.geronimo.specs/geronimo-activation_1.0.2_spec//jar at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:119) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:98) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver$$FastClassByCGLIB$$e847b746.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.repository.ArtifactResolver$$EnhancerByCGLIB$$8e854b59.resolveInClassLoader(generated) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.resolveParentIds(SimpleConfigurationManager.java:466) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadDepthFirst(SimpleConfigurationManager.java:425) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:291) ... 15 more Server shutdown begun Server shutdown completed was: $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.5.0_01)... Starting Geronimo Application Server v1.1.1 [*-] 0% 2s Startup failed org.apache.geronimo.kernel.config.LifecycleException: load of geronimo/rmi-naming/1.1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:294) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:275) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:250) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at
Re: ServiceMix 3.1
I will upload a new version in a few hours. On 11/1/06, cgallemore [EMAIL PROTECTED] wrote: Hi, I'm trying to find a snapshot for servicemix 3.1, I went to the downloads section of servicmix.org and clicked the snapshot link (http://people.apache.org/repo/m2-snapshot-repository/org/apache/servicemix/apache-servicemix/3.1-incubating-SNAPSHOT/) and the link was broken. Can you let me know where I can go to download ServiceMix 3.1 -- View this message in context: http://www.nabble.com/ServiceMix-3.1-tf2553558.html#a7115202 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Re: [jira] Commented: (GERONIMO-2526) Set J2EEApplication and J2EEServer for tomcat MBeans
That's my bad. I replied to the message sent by jira..Vamsavardhana Reddy [EMAIL PROTECTED] wrote: From where did " Access over 1 million songs - Yahoo! Music Unlimited Try it today." creep into the JIRA comment??? --vamsiOn 11/1/06, Anita Kulshreshtha (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2526?page=comments#action_12446247 ]Anita Kulshreshtha commented on GERONIMO-2526: --Thanks Jeff!Anita"Jeff Genender (JIRA)" [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2526?page=comments#action_12446243 ]Jeff Genender commented on GERONIMO-2526:-This patch looks ok to me. --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-Access over 1 million songs - Yahoo! Music Unlimited Try it today. Set J2EEApplication and J2EEServer for tomcat MBeans Key: GERONIMO-2526 URL: http://issues.apache.org/jira/browse/GERONIMO-2526 Project: GeronimoIssue Type: BugSecurity Level: public(Regular issues) Components: TomcatAffects Versions: 1.2 Environment: AllReporter: Anita Kulshreshtha Assigned To: Anita KulshreshthaPriority: Minor Attachments: tomcat.patch From a discussion on the list http://www.nabble.com/Fairly-big-problem-with-tomcat-integration-tf1574249.html#a4274316 : SetJ2EEApplication and J2EEServer for WebModule and hence the servlets. The servlet Mbeans have names like: Geronimo:j2eeType=Servlet,name=ServerManager,WebModule=//0.0.0.0/console-standard, J2EEApplication=org.apache.geronimo.configs/webconsole-tomcat/1.2-SNAPSHOT/car,J2EEServer=geronimo TODO - Find a way to set WebModule--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 Get your email and see which of your friends are online - Right on the new Yahoo.com
Re: 1.2 Fit and Finish
On Oct 31, 2006, at 10:47 PM, Dain Sundstrom wrote: On Oct 31, 2006, at 6:13 AM, Kevan Miller wrote: IMO, fixing the startup time of the web console config under jetty (see GERONIMO-2507) is a must fix... Does that mean you are going to fix it? Happy to, when I have enough time. Does that mean you are happy to ship with the current behavior? --kevan
Closing issues with an RTC process.
I'm going through and doing some JIRA cleanup, and I've found a problem with a JIRA that doesn't seem to allow closing. This JIRA http://issues.apache.org/jira/browse/GERONIMO-1341 Has already been integrated, but was left open for any potential additional work. I think this should be closed out and new JIRAs opened for additional POP3 features (which has already happened). Unfortunately, this appears to have been switched over to an RTC-process, and the Close or Resolve operations no longer appear available. What's the appropriate way to close this one out? Rick
Re: Closing issues with an RTC process.
I see the close issue link. Should I close it for you? --vamsiOn 11/1/06, Rick McGuire [EMAIL PROTECTED] wrote: I'm going through and doing some JIRA cleanup, and I've found a problemwith a JIRA that doesn't seem to allow closing.This JIRAhttp://issues.apache.org/jira/browse/GERONIMO-1341 Has already been integrated, but was left open for any potentialadditional work.I think this should be closed out and new JIRAs openedfor additional POP3 features (which has already happened).Unfortunately, this appears to have been switched over to an RTC-process, and the Close or Resolve operations no longer appearavailable.What's the appropriate way to close this one out?Rick
[jira] Resolved: (GERONIMO-1697) Can't set listen host/IP for Sun CORBA Name Service GBean
[ http://issues.apache.org/jira/browse/GERONIMO-1697?page=all ] Rick McGuire resolved GERONIMO-1697. Fix Version/s: 1.2 Resolution: Fixed This support was added as part of the yoko changes associated with http://issues.apache.org/jira/browse/OPENEJB-266 Can't set listen host/IP for Sun CORBA Name Service GBean - Key: GERONIMO-1697 URL: http://issues.apache.org/jira/browse/GERONIMO-1697 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Reporter: Aaron Mulder Assigned To: Rick McGuire Fix For: 1.2 The Sun CORBA Name Service wrapper GBean lets you specify the port, but not the listen hostname/IP. It should let you specify both. The class in question is: geronimo/openejb/modules/core/src/java/org/openejb/corba/SunNameService.java When this is done, the getAddress() method should be updated to return the proper listen address instead of 0.0.0.0. -- 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: Closing issues with an RTC process.
Closed. --vamsiOn 11/1/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I see the close issue link. Should I close it for you? --vamsiOn 11/1/06, Rick McGuire [EMAIL PROTECTED] wrote: I'm going through and doing some JIRA cleanup, and I've found a problemwith a JIRA that doesn't seem to allow closing.This JIRA http://issues.apache.org/jira/browse/GERONIMO-1341 Has already been integrated, but was left open for any potentialadditional work.I think this should be closed out and new JIRAs openedfor additional POP3 features (which has already happened).Unfortunately, this appears to have been switched over to an RTC-process, and the Close or Resolve operations no longer appearavailable.What's the appropriate way to close this one out?Rick
[jira] Closed: (GERONIMO-1341) POP3 Implementation
[ http://issues.apache.org/jira/browse/GERONIMO-1341?page=all ] Vamsavardhana Reddy closed GERONIMO-1341. - Resolution: Fixed POP3 Implementation --- Key: GERONIMO-1341 URL: http://issues.apache.org/jira/browse/GERONIMO-1341 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: mail Affects Versions: 1.0-M5 Reporter: Rajith Attapattu Assigned To: Rick McGuire Priority: Minor Fix For: 1.2 Attachments: javamail.patch I have completed the POP3 implementation and the patch is attached. Comments and code reviews are greatly appreciated. I have done it in a Geronimo independent way so that the code can be moved out to a sub project in the future by just changing the package name. What is done = 1. POP3Store, POP3Folder and partial implementation of POP3Message for JavaMail API 2. All support classes including factories for POP3Command and POP3Response and a POP3Connection abstraction. 3. Can connect, authenticate with user/pass and retrieve mail. -- 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: New Dojo version available - 0.4
I upgraded to dojo-0.4 in my local geronimo and the JMX portlet still seems to work ok. Jay unless you're already working on a patch for upgrading dojo I'll create a JIRA and check in the upgraded library. With so many bug fixes and improvements I think we definitely want to get this into geronimo 1.2. Best wishes, Paul On 10/27/06, Paul McMahan [EMAIL PROTECTED] wrote: The upgrade procedure should go something like: - mkdir applications/geronimo-dojo/repository/org/dojotoolkit/dojo/0.4 - place new dojo zip into that directory, renaming it using maven's artifact-version.zip naming convention - update the dojo versions in applications/geronimo-dojo/pom.xml - if the zip's organization has changed much since 0.3.1 then the include elements in the pom might need updating - rebuild applications/geronimo-dojo, configs/dojo-tomcat, configs/dojo-jetty, and then your server assembly of choice Paul On 10/27/06, Jay D. McHugh [EMAIL PROTECTED] wrote: Hello all, I was wondering if anyone had noticed that a new version of Dojo has been released? I would like to help in changing over the 'built-in' dojo library from 0.3.1 to 0.4. What are the steps that need to be done to accomplish this (Paul?)? Thanks, Jay
Re: New Dojo version available - 0.4
Paul McMahan wrote: I upgraded to dojo-0.4 in my local geronimo and the JMX portlet still seems to work ok. Jay unless you're already working on a patch for upgrading dojo I'll create a JIRA and check in the upgraded library. With so many bug fixes and improvements I think we definitely want to get this into geronimo 1.2. Paul, I have also been using dojo-0.4 on my local server. Everything appears to be working ok (I just checked the JMX portlet viewer after I read your email). I could make the patch for changing over the pom, but I can't check in the new library - so maybe you should just go ahead and push it in. Jay
Re: New Dojo version available - 0.4
Hi Paul, I was playing with dojo-0.4 and it looks good. We might have some use for some of the new widgets plus like what you said there are tons of bug fixes in this release. +1 on upgrading to dojo-0.4 Best wishes, chris Paul McMahan wrote: I upgraded to dojo-0.4 in my local geronimo and the JMX portlet still seems to work ok. Jay unless you're already working on a patch for upgrading dojo I'll create a JIRA and check in the upgraded library. With so many bug fixes and improvements I think we definitely want to get this into geronimo 1.2. Best wishes, Paul On 10/27/06, Paul McMahan [EMAIL PROTECTED] wrote: The upgrade procedure should go something like: - mkdir applications/geronimo-dojo/repository/org/dojotoolkit/dojo/0.4 - place new dojo zip into that directory, renaming it using maven's artifact-version.zip naming convention - update the dojo versions in applications/geronimo-dojo/pom.xml - if the zip's organization has changed much since 0.3.1 then the include elements in the pom might need updating - rebuild applications/geronimo-dojo, configs/dojo-tomcat, configs/dojo-jetty, and then your server assembly of choice Paul On 10/27/06, Jay D. McHugh [EMAIL PROTECTED] wrote: Hello all, I was wondering if anyone had noticed that a new version of Dojo has been released? I would like to help in changing over the 'built-in' dojo library from 0.3.1 to 0.4. What are the steps that need to be done to accomplish this (Paul?)? Thanks, Jay
[jira] Closed: (GERONIMO-2333) Add JMX Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2333?page=all ] Christopher M. Cardona closed GERONIMO-2333. Resolution: Fixed Add JMX Portlet --- Key: GERONIMO-2333 URL: http://issues.apache.org/jira/browse/GERONIMO-2333 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Reporter: Christopher M. Cardona Assigned To: Paul McMahan Fix For: 1.2 Attachments: dojo-0.3.1-bin.zip, GERONIMO-2333-trunk.patch, GERONIMO-2333-trunk2.patch, GERONIMO-2333-trunk3.patch, jmxMgrPortlet-G1.1.1-1.jpg, jmxMgrPortlet-G1.1.1-2.jpg, jmxMgrPortlet-G1.1.1-3.jpg, jmxMgrPortlet-G1.1.1-New.patch, jmxMgrPortlet-G1.1.1.patch Add a JMX portlet with the following minimum capabilities: 1. Be able to list all the MBeans 2. Predefined searches for the different J2EE types: J2EEApplication, EJBModule, WebModule, Sertlet, JCAConnectionFactory, etc. 3. Be able to query MBeans (if possible with autocomplete feature) 4. View the attributes and operations of MBeans The plan is to use Ajax (Dojo and DWR) to make this portlet a little bit responsive. Any thoughts and suggestions are welcome. cheers, chris -- 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: (AMQ-1019) Duplicate bean names (i.e. transportConnector/networkConnector names) in xml config causes exception in xbean.
Duplicate bean names (i.e. transportConnector/networkConnector names) in xml config causes exception in xbean. -- Key: AMQ-1019 URL: https://issues.apache.org/activemq/browse/AMQ-1019 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.1 Reporter: Adrian Co Assigned To: Adrian Co Fix For: 4.1 Due to upgrade to xbean-2.7 and spring-2.0, beans with the same name/id will cause an exception in xbean/spring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1833) Non-public Sun classes dependencies in tests
[ http://issues.apache.org/jira/browse/GERONIMO-1833?page=all ] Rick McGuire resolved GERONIMO-1833. Fix Version/s: 1.2 Resolution: Fixed Committed revision 47. Non-public Sun classes dependencies in tests Key: GERONIMO-1833 URL: http://issues.apache.org/jira/browse/GERONIMO-1833 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0 Reporter: Nellya Udovichenko Assigned To: Rick McGuire Fix For: 1.2 Attachments: ContainerTest.patch Class sun.misc.Base64Encoder is used in org.apache.geronimo.tomcat.ContainerTest. Attached patch replaces class sun.misc.Base64Encoder with class org.apache.geronimo.encoders.util.Base64. -- 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-2538) Upgrade Dojo to 0.4.0
Upgrade Dojo to 0.4.0 - Key: GERONIMO-2538 URL: http://issues.apache.org/jira/browse/GERONIMO-2538 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 1.x Reporter: Jay D. McHugh Priority: Minor The Dojo foundation has release a new stable version - 0.4.0. -- 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: (AMQ-1020) Slow consumer terminally blocks both client and broker
Slow consumer terminally blocks both client and broker -- Key: AMQ-1020 URL: https://issues.apache.org/activemq/browse/AMQ-1020 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Environment: Broker: Windows XP, Sun JDK1.5 Client: activemq-dotnet (Trunk) Reporter: Rob Lugt I have a multi-threaded client (client1) which is acting as both a publisher (Topic1) and subscriber (Topic2) using a single session. There is another client process (client2) which publishes on Topic2. I have witnessed the following repeatable scenario where both clients get stuck, which can only be rectified by restarting the broker! :- Client1 publishes messages to Topic1 (rate = about 30 msgs/sec). Client2 publishes bursts of messages to Topic2 (rate = 500 msgs/sec) Client1 is a slow subscriber on Topic2 After running in this scenario for a couple of seconds, Client1 and Client2 become stuck. Looking at a stack trace for Client1 I can see that it's read_loop is stuck waiting for input, and it's publisher thread is stuck waiting for an acknowledgement to the synchronous message send (the acknowledgement never arrives because the broker won't sent any more messages). Client2 is also stuck waiting for an acknowledgement to a synchronous send. My perception is that it appears the broker is throttling the connection because the consumer is running slowly, but for some reason it gets into a state where all message flow stops (even though the consumer is automatically acknowledging messages, albeit slowly). Furthermore, if I kill Client1 the broker doesn't recover (using a JMX console the connection remains visible). The broker uses a vanilla configuration (i.e. no policies are set for the topics in quedtion). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-732) Fault-messages cause JbiChannel to throw NullPointerException
Fault-messages cause JbiChannel to throw NullPointerException - Key: SM-732 URL: https://issues.apache.org/activemq/browse/SM-732 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Affects Versions: 3.0 Environment: not relevant Reporter: Horst Studer From a service (jsr181 pojo), I am calling another service (also implemented as a jsr181 pojo), using a jsr181 proxy. This works fine if the called service returns an out message. If, however, the called service throws an exception (i.e. returns a fault), there is a NullPointerException in ...jsr181.xfire.JbiChannel. There are two problems: After the sendSync, there is a check to see if the exchange status is ERROR, and if not, getOutMessage().getContent() is called. The code assumes that after a fault, the exchange status is ERROR, but in fact, it is ACTIVE and the fault-Message is set, while the out-Message is null. So this causes the NullPointerException. The other problem is that the code for handling the fault-Message is missing (marked as // TODO, but as stated above, with the wrong assumption that the exchange status is ERROR). It would be nice, if the fault message would be processed an cause xfire to throw a corresponding exception on the proxy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1840) NamingPropertiesTest is not compatible with non-Sun VMs.
[ http://issues.apache.org/jira/browse/GERONIMO-1840?page=all ] Rick McGuire resolved GERONIMO-1840. Fix Version/s: 1.2 Resolution: Fixed Committed revision 470013. A slightly different approach was used to fix this. The sun class name is still used because the critical test here is the setting of the system properties. The final new InitialContext() test is only run if it is possible to load the initial factory class (i.e,, it is present in the current JVM). NamingPropertiesTest is not compatible with non-Sun VMs. Key: GERONIMO-1840 URL: http://issues.apache.org/jira/browse/GERONIMO-1840 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: JVM-compatibility Affects Versions: 1.0 Reporter: Andrey Pavlenko Assigned To: Rick McGuire Priority: Minor Fix For: 1.2 Attachments: NamingPropertiesTest.patch NamingPropertiesTest is not compatible with non-Sun VMs because of hardcoded name of JNDI service provider. The attached patch fixes the issue. -- 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: (GERONIMO-1826) Naming tests might not work on non-Sun VMs.
[ http://issues.apache.org/jira/browse/GERONIMO-1826?page=all ] Rick McGuire resolved GERONIMO-1826. Fix Version/s: 1.2 Resolution: Duplicate This is a duplicate of GERONIMO-1840. Naming tests might not work on non-Sun VMs. --- Key: GERONIMO-1826 URL: http://issues.apache.org/jira/browse/GERONIMO-1826 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: JVM-compatibility, naming Affects Versions: 1.0 Reporter: Andrey Pavlenko Assigned To: Rick McGuire Fix For: 1.2 Attachments: naming.patch Several naming tests might not work on non-Sun VMs because of hardcoded name of InitialContextFactory. The attached patch removes all occurences of System.setProperty(java.naming... and passes all required naming properties to the tests via maven.junit.jvmargs=-Djava.naming.factory.initial=... -- 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-2538) Upgrade Dojo to 0.4.0
[ http://issues.apache.org/jira/browse/GERONIMO-2538?page=comments#action_12446320 ] Jay D. McHugh commented on GERONIMO-2538: - Here is the upgrade procedure (there is a patch attached to handle changing over the pom.xml file) 1) Download the dojo-0.4.0-ajax.zip file from: http://download.dojotoolkit.org/release-0.4.0/dojo-0.4.0-ajax.zip 2) Rename the file to: dojo-0.4.0.zip 3) Create the subdirectory: geronimo base/applications/geronimo-dojo/repository/org/dojotoolkit/dojo/0.4.0 4) Move or copy the zip file into this directory 5) Apply attached patch to update the geronimo base/applications/geronimo-dojo/pom.xml file and create the md5 checksum file for the zip And that should do it. Upgrade Dojo to 0.4.0 - Key: GERONIMO-2538 URL: http://issues.apache.org/jira/browse/GERONIMO-2538 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.x Reporter: Jay D. McHugh Priority: Minor Attachments: geronimo-2538.patch The Dojo foundation has release a new stable version - 0.4.0. -- 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-2538) Upgrade Dojo to 0.4.0
[ http://issues.apache.org/jira/browse/GERONIMO-2538?page=all ] Jay D. McHugh updated GERONIMO-2538: Attachment: geronimo-2538.patch Upgrade Dojo to 0.4.0 - Key: GERONIMO-2538 URL: http://issues.apache.org/jira/browse/GERONIMO-2538 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.x Reporter: Jay D. McHugh Priority: Minor Attachments: geronimo-2538.patch The Dojo foundation has release a new stable version - 0.4.0. -- 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: Board Report Comments Consolidated - 15:00 On Monday
Is it too late to mention the addition of Dojo and the new JMX console? Or the beginning of the use of AJAX techniques to make the console more responsive/friendly? Jay
[jira] Resolved: (GERONIMO-2217) Missing versions for dependencies in modules/mail/pom.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2217?page=all ] Rick McGuire resolved GERONIMO-2217. Resolution: Cannot Reproduce This is working properly now. I suspect the problem was the need to get the root pom.xml into the repository using mvn -N first so that the module build could locate the version information. Missing versions for dependencies in modules/mail/pom.xml - Key: GERONIMO-2217 URL: http://issues.apache.org/jira/browse/GERONIMO-2217 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Environment: Maven 2.0.4, JDK 1.4.2_08, Geronimo trunk Reporter: Fredrik Westermarck Assigned To: Rick McGuire The versions for geronimo-javamail_1.3.1_spec and org.apache.geronimo.javamail is missing in modules/mail/pom.xml. This makes the validation of the poms made by maven when building modules to fail. The following is the output from maven: D:\apache\geronimo\modulesmvn [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.geronimo.modules:geronimo-mail POM Location: D:\apache\geronimo\modules\mail\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.apache.geronimo.j vamail:geronimo-javamail_1.3.1_provider Reason: Failed to validate POM [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430 at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to val date POM at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLo ic(DefaultMavenProjectBuilder.java:926) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(De aultMavenProjectBuilder.java:737) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceF leInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMav nProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Sat Jul 22 12:45:34 CEST 2006 [INFO] Final Memory: 3M/6M [INFO] -- 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] Assigned: (GERONIMO-2538) Upgrade Dojo to 0.4.0
[ http://issues.apache.org/jira/browse/GERONIMO-2538?page=all ] Paul McMahan reassigned GERONIMO-2538: -- Assignee: Paul McMahan Upgrade Dojo to 0.4.0 - Key: GERONIMO-2538 URL: http://issues.apache.org/jira/browse/GERONIMO-2538 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.x Reporter: Jay D. McHugh Assigned To: Paul McMahan Priority: Minor Attachments: geronimo-2538.patch The Dojo foundation has release a new stable version - 0.4.0. -- 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-2002) OpenEJB CORBA SSL should use Keystore GBean
[ http://issues.apache.org/jira/browse/GERONIMO-2002?page=all ] Vamsavardhana Reddy closed GERONIMO-2002. - Resolution: Fixed OpenEJB CORBA SSL should use Keystore GBean --- Key: GERONIMO-2002 URL: http://issues.apache.org/jira/browse/GERONIMO-2002 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security, CORBA Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Rick McGuire Fix For: 1.2 OpenEJB initializes CORBA using a plain SSL socket factory and therefore only sees SSL keystore/trust store settings configured as system properties. We should change this to use the KeystoreManager API instead. -- 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: (SM-733) Using 0.0.0.0 in http endpoint clashes with other http endpoints using the hostname or ip address of the machine, unless port is different
Using 0.0.0.0 in http endpoint clashes with other http endpoints using the hostname or ip address of the machine, unless port is different Key: SM-733 URL: https://issues.apache.org/activemq/browse/SM-733 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0, 3.1 Reporter: Chad Sturtz Priority: Minor Three tested scenarios: 1) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with 10.9.5.29:8192 -- deploy fails (address already in use) 2) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with 0.0.0.0:8192 --- deploy success 3) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with 10.9.5.29:8193 --- deploy success Basically, ALL SUs must use 0.0.0.0 in their SUs or make sure they're using different ports. For someone developing SUs/SAs that will be deployed in an environment with SUs/SAs developed by others, this creates an item that must be coordinated between everyone creating SUs/SAs to be deployed in the common environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2421) Noone seems to have a clue about which corba spec jar works and the build uses several
[ http://issues.apache.org/jira/browse/GERONIMO-2421?page=all ] Rick McGuire closed GERONIMO-2421. -- Resolution: Fixed Finally resolved by http://issues.apache.org/jira/browse/OPENEJB-301. The correct answer turned out to be none of the above. Openejb is now using the yoko-corba-spec jar. Noone seems to have a clue about which corba spec jar works and the build uses several -- Key: GERONIMO-2421 URL: http://issues.apache.org/jira/browse/GERONIMO-2421 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA, OpenEJB Affects Versions: 1.2 Reporter: David Jencks Assigned To: Rick McGuire Fix For: 1.2 There are zillions of corba spec jars most of which I think don't work (although I'm not sure how to find out). The openejb-core build uses groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-corba_2.3_spec/artifactId at version 1.0-SNAPSHOT but its geronimo-dependency.xml lists dep:groupIdgeronimo-spec/dep:groupId dep:artifactIdgeronimo-spec-corba/dep:artifactId although it is not actually a dependency. Until recently it was also listed as a dependency in configs/client. This jar actually does seem to work. In the interests of consistency I'm going to change geronimo-dependency.xml to match the openejb-core pom.xml. If this turns out to break corba I suggest we fix at least one of the m2-built corba spec jars and use it rather than relying on the m1 built jar with somewhat unclear provenance. -- 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-2466) Add a new Java Activation Framework 1.1 implementation.
[ http://issues.apache.org/jira/browse/GERONIMO-2466?page=all ] Rick McGuire closed GERONIMO-2466. -- Resolution: Fixed New version completed and integrated into the specs tree. Add a new Java Activation Framework 1.1 implementation. --- Key: GERONIMO-2466 URL: http://issues.apache.org/jira/browse/GERONIMO-2466 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.2 There's an updated 1.1 version of the Java Activation Framework which will be needed for j2ee 5 certification. -- 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
Documentation footprint
Hi all, I'm trying to reduce the documentation footprint and I was thinking in moving the translated docs to a separate space. Visually it wont be any changes, mainly administrative/organizational aspects will be affected. What do you guys think, specially you folks doing the translations? Cheers! Hernan
[jira] Closed: (GERONIMO-2538) Upgrade Dojo to 0.4.0
[ http://issues.apache.org/jira/browse/GERONIMO-2538?page=all ] Paul McMahan closed GERONIMO-2538. -- Fix Version/s: 1.2 Resolution: Fixed thanks for the patch Jay! Upgrade Dojo to 0.4.0 - Key: GERONIMO-2538 URL: http://issues.apache.org/jira/browse/GERONIMO-2538 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.x Reporter: Jay D. McHugh Assigned To: Paul McMahan Priority: Minor Fix For: 1.2 Attachments: geronimo-2538.patch The Dojo foundation has release a new stable version - 0.4.0. -- 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-2245) Why corbaNameGroup:css-name?
[ http://issues.apache.org/jira/browse/GERONIMO-2245?page=all ] Rick McGuire closed GERONIMO-2245. -- Fix Version/s: 1.2 (was: 1.1.x) Resolution: Fixed I've not found any strong support for keeping this (or even any use of it). Removed in 1.2 Committed revision 470046. Why corbaNameGroup:css-name? Key: GERONIMO-2245 URL: http://issues.apache.org/jira/browse/GERONIMO-2245 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, OpenEJB Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Rick McGuire Fix For: 1.2 Between Geronimo 1.0 and Geronimo 1.1, we removed most of the elements that allow you to list a full ObjectName/AbstractName in a reference. There is no more target-name for resource references, EJB references, etc. However, the corbaNameGroup still includes css-name, which appears to take the text of an AbstractName or AbstractNameQuery to identify a CSS. That seems weird, since there's already the css element (type patternType) which lets you explicitly identify a CSS by its name components. I think we should remove css-name to be consistent (and avoid people trying to use the AbstractName or AbstractNameQuery String syntax), unless there's a strong reason to keep it. -- 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: manually downloading jars?
On Tue, Oct 31, 2006 at 10:50:59PM +0100, Jacek Laskowski wrote: On 10/31/06, toby cabot [EMAIL PROTECTED] wrote: Glad you've done it. After the successful build, it's time to get your hands wet and start testing! ;-) See how the doco improved lately. You won't likely find so much time as it's required to get thru all the docs. Thanks Jacek, will do. The docs for 1.0 and 1.1 look nice, what's the plan for 1.2 docs? Will someone clone the 1.1 wiki tree into a GMOxDOC12 and then people will edit the files for changes? I ask only because my next step is to get my application to run in 1.2 so I could update the docs as I go. Toby
[jira] Commented: (SM-733) Using 0.0.0.0 in http endpoint clashes with other http endpoints using the hostname or ip address of the machine, unless port is different
[ https://issues.apache.org/activemq/browse/SM-733?page=comments#action_37337 ] Chad Sturtz commented on SM-733: I dug a little deeper and came up with more information. In addition to the scenarios stated above, i've tested the following: 4) SA1 deployed with http endpoint using 10.9.5.29:8192, SA2 deployed using http endpoint with B-1234:8192 where B-1234 and 10.9.5.29 are the same machine -- deploy failed 5) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with B-1234:8192 --- deploy success I've looked at the code (JettyContextManager.java). What's happening is the created Servers are stored in a Map. Upon looking at a new endpoint, it creates a key based on the location URL. If there's no Server in the Map with that key, it creates a new one. If you look at the method that creates the key based on the location URL (method is: getKey(URL url)), it either uses the host as is from the URL, or it uses the hostname if a wild-card host was used in the URL (0.0.0.0). I would say that the same key should be created for any host resolving to the local machine. However, I don't know how that would affect scenarios where one machine has multiple ip addresses. I've not worked in such an environment and don't know if that's an acceptable solution. Using 0.0.0.0 in http endpoint clashes with other http endpoints using the hostname or ip address of the machine, unless port is different Key: SM-733 URL: https://issues.apache.org/activemq/browse/SM-733 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0, 3.1 Reporter: Chad Sturtz Priority: Minor Three tested scenarios: 1) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with 10.9.5.29:8192 -- deploy fails (address already in use) 2) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with 0.0.0.0:8192 --- deploy success 3) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with 10.9.5.29:8193 --- deploy success Basically, ALL SUs must use 0.0.0.0 in their SUs or make sure they're using different ports. For someone developing SUs/SAs that will be deployed in an environment with SUs/SAs developed by others, this creates an item that must be coordinated between everyone creating SUs/SAs to be deployed in the common environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2507) Starting the webconsole config is taking *way* too much time
[ http://issues.apache.org/jira/browse/GERONIMO-2507?page=comments#action_12446371 ] Paul McMahan commented on GERONIMO-2507: Disabling JSP precompilation in the geronimo-console-standard module reduced startup time for my admin console in jetty from 86s to 25s. Precompiling JSPs adds 164 servlets to the web.xml for the admin console, which I suppose must be causing the kernel to process lots more gbeans when it starts the module, at least in the jetty assembly. JSP precompilation is nice to have because it makes first time access to the admin console more snappy. However, I believe the real reason JSP precompilation was introduced was to deal with the windows path length restrictions encountered in 1.1 where the long package/class names generated by the jsp compiler, combined with the path length of the console module already in the repo, exceeded what windows could handle. Precompiling the JSPs worked around this problem by putting the compiled JSP classes in a jar instead of writing them in the repo at runtime. See GERONIMO-1844. Some of the options I can think of for dealing with this are 1.) disable JSP precompilation and deal with the windows path length problem in some other way 2.) look into what causes the delay in the jetty assembly when lots of servlets are defined in an application. i.e. what changed from geronmio 1.1.1 to 1.2? 3.) reduce the number of JSPs in the console 4.) investigate some way to make the jspc maven plugin generate fewer servlet definitions Starting the webconsole config is taking *way* too much time Key: GERONIMO-2507 URL: http://issues.apache.org/jira/browse/GERONIMO-2507 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Kevan Miller Priority: Critical Fix For: 1.2 Server startup time of 1.2 has more than doubled. The vast majority of time is being spent starting the webconsole config. -- 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: (SM-733) Using 0.0.0.0 in http endpoint clashes with other http endpoints using the hostname or ip address of the machine, unless port is different
[ https://issues.apache.org/activemq/browse/SM-733?page=comments#action_37338 ] Guillaume Nodet commented on SM-733: Yeah, you have understood the mechanism. It needs to be enhanced but I'm not sure there is a real solution. If one deploys a service on 0.0.0.0:8192, the server socket will be bound to all IPs of the host. If you deploy it on 10.9.5.29:8192, it will be bound only to the specified IP. The problem is that there is no way to fulfill these requirements at the same time. One option would be to enhance the component to support additional configuration mechanism: * bind all services to a single jetty server (disregarding the host:port informations, as when installed in a managed mode inside a web server) * just use the port and disregard the host We also need to take into account the http / https protocol. Thoughts ? Using 0.0.0.0 in http endpoint clashes with other http endpoints using the hostname or ip address of the machine, unless port is different Key: SM-733 URL: https://issues.apache.org/activemq/browse/SM-733 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0, 3.1 Reporter: Chad Sturtz Priority: Minor Three tested scenarios: 1) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with 10.9.5.29:8192 -- deploy fails (address already in use) 2) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with 0.0.0.0:8192 --- deploy success 3) SA1 deployed with http endpoint using 0.0.0.0:8192, SA2 deployed using http endpoint with 10.9.5.29:8193 --- deploy success Basically, ALL SUs must use 0.0.0.0 in their SUs or make sure they're using different ports. For someone developing SUs/SAs that will be deployed in an environment with SUs/SAs developed by others, this creates an item that must be coordinated between everyone creating SUs/SAs to be deployed in the common environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2507) Starting the webconsole config is taking *way* too much time
[ http://issues.apache.org/jira/browse/GERONIMO-2507?page=comments#action_12446379 ] Jeff Genender commented on GERONIMO-2507: - The fact that this is hitting Jetty very likely due to the fact that each servlet is a GBean. Removing jsp precompilation is a treatment to a problem and not the panacea. Notice this is not an issue with Tomcat with the difference being it does not create a separate GBean for each servlet. Ths jsp-maven-plugin simply creates a servlet for each JSP which is the standard for precompiling JSPs (see the jasper/jspc doc on the Tomcat website http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html)...I cannot see this playing a significant component in this. This becomes an issue for folks that have fairly large JSP applications. I would not recommend removing JSP precompilation nor reduce JSPs and deal with the problem head on. I think #2 in the listed options by Paul is the appropriate action to take. I think #1, #3, and #4 are red herrings. Starting the webconsole config is taking *way* too much time Key: GERONIMO-2507 URL: http://issues.apache.org/jira/browse/GERONIMO-2507 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Kevan Miller Priority: Critical Fix For: 1.2 Server startup time of 1.2 has more than doubled. The vast majority of time is being spent starting the webconsole config. -- 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
Time to remove bootstrap
Yesterday, I tried to build G with mvn alone after removing my local repository and it works fine... now that the specs and openejb2 snaps are deployed. I have not really even used bootstrap in a many weeks... and I think its time for it to go away. So... unless someone objects strongly (and soonish) I am gonna nuke it. --jason
[jira] Closed: (GERONIMO-2064) Mail archive links in the Welcome portlet should use the redirects at geronimo.apache.org
[ http://issues.apache.org/jira/browse/GERONIMO-2064?page=all ] Paul McMahan closed GERONIMO-2064. -- Fix Version/s: 1.2 Resolution: Fixed Assignee: Paul McMahan Mail archive links in the Welcome portlet should use the redirects at geronimo.apache.org - Key: GERONIMO-2064 URL: http://issues.apache.org/jira/browse/GERONIMO-2064 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2 Attachments: GERONIMO-2064.diff The welcome portlet contains several links to external resources such as the FAQ, Wiki, and mailing lists. Any external resources that are not hosted at geronimo.apache.org are referred to indirectly via a redirect page that is hosted at geronimo.apache.org. For example, the location of the confluence Wiki may change so instead of hardcoding its current location which is at opensource.atlassian.com the link in welcome portlet points at a page on geronimo.apache.org that automatically redirects the browser to opensource.atlassian.com. This allows Geronimo to change where the welcome portlet points its links at without patching the console. The links to the user and dev mailing lists on the right hand column of the welcome portlet use these redirects and they work fine. However, there are two additoinal links to the user and dev mailing lists in the main text of the portlet that do not use the redirects and point directly at pages hosted at marc.theaimsgroup.com. Those links should use the redirect pages at geronimo.apache.org instead. Otherwise the links may fail or lead to inappropriate content outside the control of apache.org. -- 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: manually downloading jars?
On 11/1/06, toby cabot [EMAIL PROTECTED] wrote: Thanks Jacek, will do. The docs for 1.0 and 1.1 look nice, what's the plan for 1.2 docs? Will someone clone the 1.1 wiki tree into a GMOxDOC12 and then people will edit the files for changes? I ask only because my next step is to get my application to run in 1.2 so I could update the docs as I go. I don't really know. I used to wait for Hernan or others when I get a question about the documentation. If you get bored awaiting any responses, please speak up in a separate thread with a more appropriate subject. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Time to remove bootstrap
On 11/1/06, Jason Dillon [EMAIL PROTECTED] wrote: So... unless someone objects strongly (and soonish) I am gonna nuke it. +10 Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: [discussion] openejb-itests in testsuite
On Oct 31, 2006, at 10:07 AM, Prasad Kashyap wrote:
On 10/30/06, David Blevins [EMAIL PROTECTED] wrote:
On Oct 30, 2006, at 7:51 AM, Prasad Kashyap wrote:
Thanx. Please see comments inline -
Couple thoughts on the poms:
- the parent would lineage would be
org.apache.openejb:itests -
org.apache.openejb:openejb
- the groupId would be org.apache.openejb
The groupId and the parent lineage looks good. As stated above,
there
would be many child modules for the beans under the itests parent
module
groupId: o.a.openejb
openejb - itests - itests-security-xxx
openejb - itests - itests-cmp2-xxx
Exactly.
After having built the itest beans as per our discussion above, the
contents of the openejb directory in m2 local repo are -
${settings.localRepository}/org/apache/openejb/
itests-cmp2-cmrmapping
itests-cmp2-petstore
itests-cmp2-prefetch
itests-cmp2-storage
itests-itests-core
itests-security-001
itests-security-002
itests-security-003
openejb
openejb-builder
openejb-corba
openejb-corba-builder
openejb-core
openejb-itests
openejb-pkgen-builder
openejb-sunorb
openejb-yoko
Does this look good ? Or should we move the itests artifacts one
level down to groupId o.a.openejb.itests ?
Let's keep it in o.a.openejb for now as that's the way it is in 3.x.
For now, I shall put all the tests into 1 artifact module. We should
look at breaking them and putting them with their respective bean
modules later on.
What's the issue with doing that now?
-David
Re: Deployment Plan -geronimo-web.xml
On 11/1/06, Kanchana Welagedara [EMAIL PROTECTED] wrote: Now the geronimo deployment plan for web application is ready for users.Please find the location here with, http://cwiki.apache.org/GMOxDOC11/geronimo-webxml.html It must've taken lots of time and effort! I hoped to read it all, but after a couple of paragraphs my brain simply melt down. So much technical information at once for such a faint-hearted person like me is not a good idea, isn't it? ;-) I would like to have your feed back as input to make the other deployment plans better.Therefore following documentations are presently underconstruction and will be available soon for users. openejb-jar.xml geronimo-ra.xml geronimo-application.xml geronimo-application-client.xml It's much to do and am not sure whether it's in sync after a few commits. I think we'd be better off if we put the tag documentation into XSDs themselves so XML editors will provide concise information right when necessary. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Commented: (GERONIMO-2507) Starting the webconsole config is taking *way* too much time
[ http://issues.apache.org/jira/browse/GERONIMO-2507?page=comments#action_12446398 ] David Jencks commented on GERONIMO-2507: I would check whether the delay is caused by logging. There are often a really lot of debug messages after startup. Starting the webconsole config is taking *way* too much time Key: GERONIMO-2507 URL: http://issues.apache.org/jira/browse/GERONIMO-2507 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Kevan Miller Priority: Critical Fix For: 1.2 Server startup time of 1.2 has more than doubled. The vast majority of time is being spent starting the webconsole config. -- 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: Source re-structuring
I'd like to come back to this thread an handle it. The number of modules is growing and it would be cleaner to reorg all these modules. So, unless someone objects, I will reorg the svn source tree on friday. On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: I put together a basic plan (with some help from Guillaume), here http://goopen.org/confluence/display/SM/Source+Structure The purpose of the new structure it two allow cleaner separation between: 1/ The JBI Container 2/ Deployables such as shared libraries/BC's/SE's 3/ Platform specific packaging projects 4/ Archetypes 5/ Tooling 6/ Sampels By categorizing the source it should become easier to read and therefore identifying what SE/BC's/SL's are available should become more obvious, as well as cleanly showing what is required for core Container functionality. There are a couple of ommissions - first rather than one assembly (currently apache-servicemix project) I would like to add a root directories called assemblies and then create a few packaging (as previously mentioned) ie. assemblies \ core-only \ core-and-components etc. The other is the servicemix-components package, there are two ways to go here: 1/ Break up the components into different service engines 2/ Turn the servicemix-components jar into an SE, add a dependencies on the servicemix-lwcontainer and then change all the libs to optional false I'm not keen on the first way because I think the conversion to real SE's will take some time and should be given space to make sure we are able to address things like WSDL for services etc. In the second option we end up with a large SE though I believe it will provide all the functionality, I was thinknig that this would be a special packaging - ie. your can download just that big SE separate from the other assemblies. I would like to try and get a discussion going on this since once this is out of the way we could then look to the work invovled in converting some of the lw-container service engines into more complete JBI Service Engines (using the service-engine architype as a basis) and also work on puting more WSDL in place for those services :) P -- Cheers, Guillaume Nodet
Re: Source re-structuring
On 11/1/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I'd like to come back to this thread an handle it. The number of modules is growing and it would be cleaner to reorg all these modules. +1 Please let me know if you need any help, Guillaume. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: svn commit: r470013 - /geronimo/server/trunk/modules/geronimo-system/src/test/java/org/apache/geronimo/system/properties/NamingPropertiesTest.java
On 11/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: rickmcguire
Date: Wed Nov 1 09:48:44 2006
New Revision: 470013
URL: http://svn.apache.org/viewvc?view=revrev=470013
Log:
GERONIMO-1840 NamingPropertiesTest is not compatible with non-Sun VMs.
...
+try {
+// the above assumes we're running on a Sun JVM. If we can't load
the class first,
+// we'll skip the attempt at creating the InitialContext. We've
already verified that the
+// system properties have been set to the correct values, so this
last bit is largely a formality.
+Class.forName(NAME_FACTORY_INITIAL);
+new InitialContext();
+} catch (ClassNotFoundException e) {
+}
It's not the first time I ask for some help understanding a change and
this one is not an exception.
Why do we look up the NAME_FACTORY_INITIAL class since it's deemed
to fail every time?
Jacek
--
Jacek Laskowski
http://www.jaceklaskowski.pl
[jira] Created: (GERONIMO-2539) car-maven-plugin should allow more stuff into manifest classpath
car-maven-plugin should allow more stuff into manifest classpath Key: GERONIMO-2539 URL: http://issues.apache.org/jira/browse/GERONIMO-2539 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: David Jencks Fix For: 1.2 Attachments: GERONIMO-2539.patch In the m1 build online-deployer config which turns into deployer.jar has a manifest cp entry for server.jar which let the offline deployer work. This is missing from the m2 build. I think I'm going to need something similar for runtime class enhancement for jpa. I've come up with a patch to car-maven-plugin that lets you add arbitrary aliases for dependencies. I'd prefer some review before committing. -- 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-2539) car-maven-plugin should allow more stuff into manifest classpath
[ http://issues.apache.org/jira/browse/GERONIMO-2539?page=all ] David Jencks updated GERONIMO-2539: --- Attachment: GERONIMO-2539.patch Proposed solution to allow adding arbitrary aliased jars to manifest cp. car-maven-plugin should allow more stuff into manifest classpath Key: GERONIMO-2539 URL: http://issues.apache.org/jira/browse/GERONIMO-2539 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: David Jencks Fix For: 1.2 Attachments: GERONIMO-2539.patch In the m1 build online-deployer config which turns into deployer.jar has a manifest cp entry for server.jar which let the offline deployer work. This is missing from the m2 build. I think I'm going to need something similar for runtime class enhancement for jpa. I've come up with a patch to car-maven-plugin that lets you add arbitrary aliases for dependencies. I'd prefer some review before committing. -- 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: geronimo-online-deploy configuration classpath missing server.jar... offline deployer broken
I came up with a proposed solution and put it in GERONIMO-2539. I think I'm about to need this facility also :-)Take a look, see if it can be improved, see if it works :-)jdillon, does this look OK to you?thanksdavid jencksOn Nov 1, 2006, at 11:15 AM, Sachin Patel wrote:I'm trying to get the offline deployer back working in trunk, the problem is when starting the kernel with the using j2ee-system as the bootstrap configuration, when locating "META-INF"/config.ser" resources only deployer.jar is located having this resource and thus the j2ee-system config cannot be found and the bootstrap fails. When debugging through 1.1.1, both server.jar and deployer.jar were found. So comparing the online-deployer configuration in trunk against 1.1.1, the culprit seems to be that server.jar is missing in the configuration's manifest as a classpath entry. This was specified in the project.properties in 1.1.1. Since it looks as if in trunk we are relying purely on the car-maven-plugin to build the manifest's classpath, since server.jar is not technically an artifact, if failed to add as an entry.Is there a way I don't know about to add this? Or do we need to update the car-maven-plugin to allow it?thx-sachin
[jira] Commented: (AMQ-1012) Receiving a BytesMessage sent from Java using CMS listener causes exception thrown in class BufferedInputStream
[
https://issues.apache.org/activemq/browse/AMQ-1012?page=comments#action_37339 ]
Nathan Mittler commented on AMQ-1012:
-
This appears to be a broker issue. When the c++ client gets the exception,
it's detecting there is data on the socket and goes to read it but nothing's
there - a typical sign of a broken socket. So the question now is: what's
going on at the broker side of things when it tries to bridge the bytes message
from JMS to stomp that it breaks the socket? Is it hitting an exception,
perhaps? I'm going to dig around in the broker code and see if I can find
anything.
Receiving a BytesMessage sent from Java using CMS listener causes exception
thrown in class BufferedInputStream
Key: AMQ-1012
URL: https://issues.apache.org/activemq/browse/AMQ-1012
Project: ActiveMQ
Issue Type: Bug
Components: CMS (C++ client)
Affects Versions: 4.0.2
Environment: Ubuntu Linux 6.06 LTS, ActiveMQ 4.0.2, CMS version 0.0.2
with STOMP
Reporter: Mark Silberbauer
Fix For: 4.0.3
Original Estimate: 1 day
Remaining Estimate: 1 day
1) Setup a MessageListener to listen for messages on Topic X using CMS.
2) Send a BytesMessage from ActiveMQ java JMS interface to Topic X
3) An exception is thrown from BufferedInputStream::bufferData() with
description failed reading bytes from stream
int bytesRead = stream-read( buffer+tail, bufferSize-tail );
if( bytesRead == 0 ){
throw IOException( __FILE__, __LINE__,
BufferedInputStream::read() - failed reading bytes from stream);
}
4) The operation of the CMS interface is broken thereafter.
Note:
This only occurs when sending a BytesMessage from Java to C++
Sending a BytesMessage from C++ to Java or C++ to C++ works perfectly.
Sending messages of Type TextMessage also works perfectly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.2 Fit and Finish
On Nov 1, 2006, at 7:14 AM, Kevan Miller wrote: On Oct 31, 2006, at 10:47 PM, Dain Sundstrom wrote: On Oct 31, 2006, at 6:13 AM, Kevan Miller wrote: IMO, fixing the startup time of the web console config under jetty (see GERONIMO-2507) is a must fix... Does that mean you are going to fix it? Happy to, when I have enough time. Does that mean you are happy to ship with the current behavior? I find the current behavior acceptable and I would not vote against the release. -dain
Re: 1.2 Fit and Finish
It isn't really possible to publish a 1.2 release like that. It would break lots of stuff (like maven) that assumes that there will only ever be a single 1.2 release. Why can't you test against a 1.2- timestamp release? -dain On Nov 1, 2006, at 5:55 AM, Paul McMahan wrote: One of the activities to coordinate when finalizing the release is updating the 1.2 plugin repository catalog at: http://geronimo.apache.org/plugins/geronimo-1.2/geronimo-plugins.xml to point at a repo where the 1.2 artifacts are published instead of the snapshot repo it currently points at. For testing purposes it would be ideal to build Geronimo as version 1.2 (not 1.2rc1 or 1.2.timestamp or something like that) and publish the 1.2 artifacts to a maven2 repo during the release candidate cycle. That would allow us to test the plugin system in pretty much the exact state it will be when 1.2 is released. Is that feasible? If not then we may need to work out an alternate approach where the repository catalog gets updated after the release goes out and the artifacts get published. That makes me a little nervous though since it will be too late to make changes to the server if something doesn't work right. Best wishes, Paul On 10/30/06, Dain Sundstrom [EMAIL PROTECTED] wrote: In a typical Geronimo release we tend to spend a significant amount of time in what I'll call the Fit and Finish phase. This involves tying up loose ends such as log levels, tools LF, startup times, licenses and so on. Basically, the phase includes fixing all the nits that cause people to vote -1 for a release (BTW no vetos in a release vote). Please, take a moment and respond to this email with any items you feel should be cleaned up before we release the software. That way we can hopefully get these items out in the open and addressed while we are finishing the TCK testing. Please note that just because an item is mentioned doesn't mean it must be completed before a release. The only thing required for a release it to successfully pass a vote of the PMC, so if the item is critical to you, spend a few minutes fixing it. With any luck we should be able to have the server ready to ship about the same time we finish the TCK testing. -dain
[jira] Commented: (GERONIMO-2539) car-maven-plugin should allow more stuff into manifest classpath
[ http://issues.apache.org/jira/browse/GERONIMO-2539?page=comments#action_12446420 ] Anita Kulshreshtha commented on GERONIMO-2539: -- Could you please add a comment to the online-deployer configs's pom.xml explaining why the server.jar is needed so it is not removed accidentally again (http://issues.apache.org/jira/browse/GERONIMO-2281#action_12426766 )? car-maven-plugin should allow more stuff into manifest classpath Key: GERONIMO-2539 URL: http://issues.apache.org/jira/browse/GERONIMO-2539 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: David Jencks Fix For: 1.2 Attachments: GERONIMO-2539.patch In the m1 build online-deployer config which turns into deployer.jar has a manifest cp entry for server.jar which let the offline deployer work. This is missing from the m2 build. I think I'm going to need something similar for runtime class enhancement for jpa. I've come up with a patch to car-maven-plugin that lets you add arbitrary aliases for dependencies. I'd prefer some review before committing. -- 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: svn commit: r470169 - in /geronimo/server/trunk: configs/online-deployer/ maven-plugins/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/
On Nov 1, 2006, at 5:29 PM, [EMAIL PROTECTED] wrote: + +/** + * @parameter + * + * Entry name used in replacement for ArtifactItem that is not resolved + */ +private String entry; FYI, this is not a valid JavaDoc for a field. The description of the field must come before tags. --jason
[jira] Commented: (GERONIMO-2539) car-maven-plugin should allow more stuff into manifest classpath
[ http://issues.apache.org/jira/browse/GERONIMO-2539?page=comments#action_12446427 ] Jason Dillon commented on GERONIMO-2539: I believe that Sachin's commit in 470169 gets the same basic functionality... with slightly less cosmetic changes. car-maven-plugin should allow more stuff into manifest classpath Key: GERONIMO-2539 URL: http://issues.apache.org/jira/browse/GERONIMO-2539 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: David Jencks Fix For: 1.2 Attachments: GERONIMO-2539.patch In the m1 build online-deployer config which turns into deployer.jar has a manifest cp entry for server.jar which let the offline deployer work. This is missing from the m2 build. I think I'm going to need something similar for runtime class enhancement for jpa. I've come up with a patch to car-maven-plugin that lets you add arbitrary aliases for dependencies. I'd prefer some review before committing. -- 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
[STATUS] (geronimo) Wed Nov 1 23:51:11 2006
APACHE GERONIMO STATUS: -*-text-*- Last modified at [$Date: 2006-10-30 23:33:33 -0500 (Mon, 30 Oct 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/geronimo/server/trunk/STATUS Upcoming Releases: Geronimo 1.2 -- geronimo/server/trunk/ Release Manager: Dain Sundstrom and Alan Cabrera Estimated Date: Q4 2006 RELEASE SHOWSTOPPERS: Certification - Historically certification has been the most time consuming portion of a release, and there is no reason to expect it to be any different for this release. To make matters worse, the certification test suite was not run for several months while major changes were made to the build, EJB, Transaction, Connector and Servlet Session. In the last two weeks we have gotten the TCK running and using Maven 2, and have made good progress on the test suite. Additionally, the GBuild servers are back online and processing some tests. There are stability issues with GBuild but we are hopeful it will be fully running soon. Currently, the biggest concerns for the TCK are ActiveMQ 4 and Yoko. Both of these are new libraries and may take a considerable amount of effort to certify. Also, there are few people that understand these new libraries, the geronimo integrations, and the TCK. In the case of ActiveMQ, the one person that understands that can certify the code, is unavailable for the next two weeks. Fit and Finish - This is another item that has historically taken a significant amount of time to complete. A process has been started to tie up the loose ends in the software so it can be released. Dead 1.2 - There are still 30 unmerged commits the dead 1.2 branch. These commits must be merged before the 1.2 release. The current status of the dead-1.2 changes can be found at http://svn.apache.org/repos/asf/geronimo/server/trunk/all_changes.log PENDING PATCHES: GERONIMO-2485 PersistenceUnitGBean needs a NamespaceDrivenDeployer GERONIMO-1277 Change group-id to org.apache.geronimo Status: New proposal by Jason Dillon to change base the groupId to org.apache.geronimo.server GERONIMO-2015 Let's replace JKS to PKCS12 key store type - Opened Status: No active discussion GERONIMO-2409 Provide config/module aliasing ability Status: 3 +1 votes GERONIMO-2413 Add a Certification Authority (CA) portlet to Geronimo console Status: Not reviewed RELEASE HISTORY: 2006-09-18 Geronimo 1.1.1 2006-06-26 Geronimo 1.1 2006-01-05 Geronimo 1.0 2005-10-04 Geronimo 1.0 milestone 5 2005-08-10 Geronimo 1.0 milestone 4 2004-11-11 Geronimo 1.0 milestone 3 2004-09-09 Geronimo 1.0 milestone 2 2004-04-29 Geronimo 1.0 milestone 1 If you're a contributor looking for something to do: * Review the documentation and suggest improvements * Review the bug list and suggest fixes or report reproducibility * Report bugs yourself
Re: svn commit: r470013 - /geronimo/server/trunk/modules/geronimo-system/src/test/java/org/apache/geronimo/system/properties/NamingPropertiesTest.java
Ya, this looks bogus...
--jason
On Nov 1, 2006, at 3:17 PM, Jacek Laskowski wrote:
On 11/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: rickmcguire
Date: Wed Nov 1 09:48:44 2006
New Revision: 470013
URL: http://svn.apache.org/viewvc?view=revrev=470013
Log:
GERONIMO-1840 NamingPropertiesTest is not compatible with non-Sun
VMs.
...
+try {
+// the above assumes we're running on a Sun JVM. If
we can't load the class first,
+// we'll skip the attempt at creating the
InitialContext. We've already verified that the
+// system properties have been set to the correct
values, so this last bit is largely a formality.
+Class.forName(NAME_FACTORY_INITIAL);
+new InitialContext();
+} catch (ClassNotFoundException e) {
+}
It's not the first time I ask for some help understanding a change and
this one is not an exception.
Why do we look up the NAME_FACTORY_INITIAL class since it's deemed
to fail every time?
Jacek
--
Jacek Laskowski
http://www.jaceklaskowski.pl
Re: svn commit: r470013 - /geronimo/server/trunk/modules/geronimo-system/src/test/java/org/apache/geronimo/system/properties/NamingPropertiesTest.java
There is a private static final String NAMING_FACTORY_INITIAL =
com.sun.jndi.rmi.registry.RegistryContextFactory in the class.
should it be
Should it be Class.forName(NAMING_FACTORY_INITIAL) ?
--vamsiOn 11/2/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
On 11/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: rickmcguire Date: Wed Nov1 09:48:44 2006
New Revision: 470013 URL: http://svn.apache.org/viewvc?view=revrev=470013 Log: GERONIMO-1840 NamingPropertiesTest is not compatible with non-Sun VMs.
... +try {
+//
the above assumes we're running on a Sun JVM.If we can't
load the class first,
+//
we'll skip the attempt at creating the InitialContext.We've
already verified that the
+//
system properties have been set to the correct values, so this last bit
is largely a formality. +Class.forName(NAME_FACTORY_INITIAL); +new InitialContext(); +} catch (ClassNotFoundException e) { +}It's not the first time I ask for some help understanding a change and
this one is not an exception.Why do we look up the NAME_FACTORY_INITIAL class since it's deemedto fail every time?Jacek--Jacek Laskowski
http://www.jaceklaskowski.pl
Re: xbean-finder: ClassFinder
More updates to the ClassFinder You can now construct the finder with exactly the list of classes you want to search for annotations. It uses var args too, so you can easily specify one class if you like. Convenient for when you have some of the code that picks which class or classes should be scraped for annotated methods, fields, constructors, etc. I also added a 'findClassesInPackage' method that allows you to suck in all the classes under a certain package name. This can be done recursively or not. -David On Oct 30, 2006, at 8:47 PM, David Blevins wrote: On Oct 27, 2006, at 12:13 PM, David Blevins wrote: So added a finder for searching for classes that have a specific annotation, etc. It's there it works and is better than some of the code i've seen that does the same, but... I still hate it as like all the approaches I've seen it loads the classes and uses reflection to determine if the annotation is present. This is the most insecure code I can think of, so I'm yanking it in leu of an asm-based approach. So take this as your warning not to start consuming the ClassFinder just yet. Done. It's now ASM-based and you can lookup any of the following annotated things: - Packages - Classes - Constructors - Methods - Fields Reflection does not occur till you ask for a set of classes that have the annotation you require. The loaded classes are then kept for future use. -David
