Re: svn commit: r485477 - /geronimo/server/trunk/pom.xml
Why are we giving the assembly id's the version suffix here? I don't
think we want to do this. I think the ids, which are simply to
select which assembly to use should be tomcat or jetty. IMO, this is
just that much more to type... for no real gain.
These are assembly ids, not artifact ids... they are supposed to be
short and simple. IMO this change only complicates them slightly by
forcing people to remember which jetty version they are using. And I
hope that we are not going to start supporting a bunch of different
jetty or tomcat versions per codeline... that would be a huge,
massive, ugly mess.
I recommend reverting this change, and changing the id's of the
tomcat6* bits to tomcat*.
--jason
On Dec 10, 2006, at 7:22 PM, [EMAIL PROTECTED] wrote:
Author: prasad
Date: Sun Dec 10 19:22:47 2006
New Revision: 485477
URL: http://svn.apache.org/viewvc?view=revrev=485477
Log:
* changing assemblyId to jetty6 to make it consistent with tomcat6
Modified:
geronimo/server/trunk/pom.xml
Modified: geronimo/server/trunk/pom.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?
view=diffrev=485477r1=485476r2=485477
==
--- geronimo/server/trunk/pom.xml (original)
+++ geronimo/server/trunk/pom.xml Sun Dec 10 19:22:47 2006
@@ -1256,7 +1256,7 @@
configuration
assemblies
assembly
-idjetty/id
+idjetty6/id
groupIdorg.apache.geronimo.assemblies/groupId
artifactIdgeronimo-jetty6-jee5/
artifactId
version${version}/version
@@ -1265,7 +1265,7 @@
/assembly
assembly
-idjetty-minimal/id
+idjetty6-minimal/id
groupIdorg.apache.geronimo.assemblies/groupId
artifactIdgeronimo-jetty-
minimal/artifactId
version${version}/version
@@ -1292,7 +1292,7 @@
/assembly
/assemblies
-defaultAssemblyIdjetty/defaultAssemblyId
+defaultAssemblyIdjetty6/defaultAssemblyId
optionSets
optionSet
Re: svn commit: r485548 - /geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml
Why are these not in the top-level javamail pom? This was building fine for me as it was... or did someone recently change it to break things? Anyways, version details should probably be in the top-level pom, not in child poms, especially for a small project like this. --jason On Dec 11, 2006, at 12:15 AM, [EMAIL PROTECTED] wrote: Author: ccardona Date: Mon Dec 11 00:15:43 2006 New Revision: 485548 URL: http://svn.apache.org/viewvc?view=revrev=485548 Log: Added version to Activation and JavaMail specs to fix the 'Failed to validate POM' warning when building G. Modified: geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml Modified: geronimo/javamail/trunk/geronimo-javamail_1.4_provider/ pom.xml URL: http://svn.apache.org/viewvc/geronimo/javamail/trunk/geronimo- javamail_1.4_provider/pom.xml?view=diffrev=485548r1=485547r2=485548 == --- geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml (original) +++ geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml Mon Dec 11 00:15:43 2006 @@ -39,11 +39,13 @@ dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-activation_1.1_spec/artifactId +version1.0-SNAPSHOT/version /dependency dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-javamail_1.4_spec/artifactId +version1.0-SNAPSHOT/version /dependency /dependencies
Re: svn commit: r485548 - /geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml
When we updated to JavaMail 1.4 and Activation 1.1 we got this warning message when building trunk: [WARNING] POM for 'org.apache.geronimo.javamail:geronimo-javamail_1.4_provider:pom:1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM The reason for this warning was it couldn't resolve the version for the said specs so I added it. I already published a new snapshot with these changes that's why we don't get this problem anymore but I forgot to update the source. Thanks for the pointers. Not sure if we have conventions on creating properties but if I create 'javamail14Version' and 'activation11Version' in the parent pom will that work for you? Thanks, chris Jason Dillon wrote: Why are these not in the top-level javamail pom? This was building fine for me as it was... or did someone recently change it to break things? Anyways, version details should probably be in the top-level pom, not in child poms, especially for a small project like this. --jason On Dec 11, 2006, at 12:15 AM, [EMAIL PROTECTED] wrote: Author: ccardona Date: Mon Dec 11 00:15:43 2006 New Revision: 485548 URL: http://svn.apache.org/viewvc?view=revrev=485548 Log: Added version to Activation and JavaMail specs to fix the 'Failed to validate POM' warning when building G. Modified: geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml Modified: geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml URL: http://svn.apache.org/viewvc/geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml?view=diffrev=485548r1=485547r2=485548 == --- geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml (original) +++ geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml Mon Dec 11 00:15:43 2006 @@ -39,11 +39,13 @@ dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-activation_1.1_spec/artifactId +version1.0-SNAPSHOT/version /dependency dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-javamail_1.4_spec/artifactId +version1.0-SNAPSHOT/version /dependency /dependencies
Re: Fixing javamail (again)
I would like to do the same change for trunk. Anybody got issues/concerns/objections to this? Best wishes, chris Rick McGuire wrote: There have been 3 javamail questions on the user list in recent weeks about how to resolve a NoSuchProviderException trying to use SMTP. These problems all had the same root cause, having the javax.mail and the provider implementations in separate jar files. It's not obvious to most people that the dependency requirement exists and occasionally, even adding the dependency doesn't fix the problem. There was a recent problem of trying to use javamail from a Quartz job class where it was necessary to explicitly set the context classloader before requesting a transport instance to ensure the correct class loader was getting used. This was a situation that could not occur with the Sun javamail implementation because the api code and the providers are contained in the same jar file. This problem can be easily corrected if we just switched the references to the javamail spec file to the geronimo-javamail_1.3_mail uber jar that contains the merged spec and provider classes. More and more users are tripping over this problem, which can be very easily corrected. Are there any objections to making this change in 1.2? Rick
Re: svn commit: r485321 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/gbean/ geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/ geronimo-kernel/s
Hi,
I am quickly scanning this commit and I would like to know if it was
not a little bit less intrusive to keep the existing addOperation and
search for the return type of the added operations against the target
gbeanType. This way, developers do not need to specify the return
type of the operations (also, the migration of the existing GBeanInfo
could have been avoided).
After reading GERONIMO-2607, it seems that the goal of the change was
to have a return type defined within JConsole for the GBean
operations. It seems that patching JMXUtil.toMBeanInfo would have
been another implementation approach: while getting the exposed
operations, the GBean class could be searched for returned types. One
of the advantages would have been to keep backward compatibility.
Thanks,
Gianny
On 11/12/2006, at 11:14 AM, [EMAIL PROTECTED] wrote:
Author: akulshreshtha
Date: Sun Dec 10 16:14:46 2006
New Revision: 485321
URL: http://svn.apache.org/viewvc?view=revrev=485321
Log:
GERONIMO-2607 Added returnType to GOperationInfo, This modifies
GBeanInfoBuilder and breaks backward compatibility
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/runtime/GBeanOperation.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/gbean/GBeanInfoTest.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/MockGBean.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/config/MyGBean.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/jmx/JMXUtil.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/logging/log4j/Log4jService.java
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/DynamicGOperationInfo.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
DynamicGOperationInfo.java?view=diffrev=485321r1=485320r2=485321
==
--- geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java (original)
+++ geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java Sun Dec 10
16:14:46 2006
@@ -24,14 +24,14 @@
*/
public class DynamicGOperationInfo extends GOperationInfo {
public DynamicGOperationInfo(String name) {
-super(name);
+super(name, java.lang.Object);
}
public DynamicGOperationInfo(String name, String[] paramTypes) {
-super(name, paramTypes);
+super(name, paramTypes, java.lang.Object);
}
public DynamicGOperationInfo(String name, List parameters) {
-super(name, parameters);
+super(name, parameters, java.lang.Object);
}
}
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/GBeanInfoBuilder.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
GBeanInfoBuilder.java?view=diffrev=485321r1=485320r2=485321
==
--- geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java (original)
+++ geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java Sun Dec 10 16:14:46 2006
@@ -187,8 +187,7 @@
for (Iterator i = source.getOperations().iterator();
i.hasNext();) {
GOperationInfo operationInfo = (GOperationInfo)
i.next();
-operations.put(new GOperationSignature
(operationInfo.getName(),
-operationInfo.getParameterList()),
operationInfo);
+operations.put(new GOperationSignature
(operationInfo.getName(), operationInfo.getParameterList()),
operationInfo);
}
for (Iterator iterator = source.getReferences
().iterator(); iterator.hasNext();) {
@@ -346,7 +345,7 @@
method.getName()));
}
} else {
-addOperation(new GOperationInfo(method.getName(),
method.getParameterTypes()));
+addOperation(new GOperationInfo(method.getName(),
method.getParameterTypes(), method.getReturnType().getName()));
}
}
Re: Fixing javamail (again)
Christopher M. Cardona wrote: I would like to do the same change for trunk. Anybody got issues/concerns/objections to this? There's an open JIRA for doing this that's marked as a wish item. http://issues.apache.org/jira/browse/GERONIMO-2498 I'd say go for it. Rick Best wishes, chris Rick McGuire wrote: There have been 3 javamail questions on the user list in recent weeks about how to resolve a NoSuchProviderException trying to use SMTP. These problems all had the same root cause, having the javax.mail and the provider implementations in separate jar files. It's not obvious to most people that the dependency requirement exists and occasionally, even adding the dependency doesn't fix the problem. There was a recent problem of trying to use javamail from a Quartz job class where it was necessary to explicitly set the context classloader before requesting a transport instance to ensure the correct class loader was getting used. This was a situation that could not occur with the Sun javamail implementation because the api code and the providers are contained in the same jar file. This problem can be easily corrected if we just switched the references to the javamail spec file to the geronimo-javamail_1.3_mail uber jar that contains the merged spec and provider classes. More and more users are tripping over this problem, which can be very easily corrected. Are there any objections to making this change in 1.2? Rick
Re: Strange build problem
I removed the legacy java.net repo from the root pom Friday PM. Are there others? Joe Jason Dillon wrote: Strange dependency muck like this often happens when a legacy repo is in the mix. --jason On Dec 10, 2006, at 8:55 PM, anita kulshreshtha wrote: When I build cxf-builder from modules directory, I get this error: Missing: -- 1) wsdl4j:wsdl4j:jar:1.6.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=wsdl4j -DartifactId=wsdl4j \ -Dversion=1.6.1 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-cxf-builder:jar:2.0-SNAPSHOT 2) org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.0-incubator-M1-SNAPSHOT 3) org.apache.cxf:cxf-tools-common:jar:2.0-incubator-M1-SNAPSHOT 4) wsdl4j:wsdl4j:jar:1.6.1 -- This jar is not in my .m2 repo, only a pom is present. When I build from geronimo-cxf-builder directory, the module builds fine. it appears to be using wsdl4j-1.5.2 jar. Is anyone else having this problem? Thanks Anita __ __ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
[jira] Commented: (AMQ-591) add a per message authorization hook so that content-based authorization can be performed using a special plugin
[ https://issues.apache.org/activemq/browse/AMQ-591?page=comments#action_37642 ] james strachan commented on AMQ-591: Here's the latest links... http://incubator.apache.org/activemq/security.html add a per message authorization hook so that content-based authorization can be performed using a special plugin Key: AMQ-591 URL: https://issues.apache.org/activemq/browse/AMQ-591 Project: ActiveMQ Issue Type: New Feature Reporter: james strachan Assigned To: james strachan Fix For: 4.0 RC2 Users may want to look in the message at headers to decide if a user can or cannot consume a message -- 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
test-ejbcontainer working?
Hi, I am trying to debug a couple of test-ejbcontainer itests and the test-ejbcontainer itests seem to be broken (I was able to run them on Friday last week) as the org.apache.geronimo.configs/j2ee-corba-yoko/ 2.0-SNAPSHOT/car configuration cannot be started due to the following reason: java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_cha nged(Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange (PIManager.java:531) It seems that I am running against a wrong version of the CORBA spec. After some investigations, I have discovered that the method being looked up is only defined by yoko-spec-corba-1.0-incubating-M2- SNAPSHOT.jar and not by the corba specs of the JVM I am using: yoko: void adapter_manager_state_changed (String id, short state); my JVM: void adapter_manager_state_changed (int id, short state); Any idea? Thanks, Gianny
[jira] Created: (SM-770) HttpBridgeServlet is not initialize when using jetty 6.1pre3
HttpBridgeServlet is not initialize when using jetty 6.1pre3 Key: SM-770 URL: https://issues.apache.org/activemq/browse/SM-770 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.1 Reporter: Jonas Lim Assigned To: Jonas Lim Fix For: 3.1 The current jetty version is 6.0.1. When updagrading to 6.1pre3, HttpBridgeServlet does not seem to get initialized. -- 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: (GERONIMODEVTOOLS-122) When creating geronimo-web.xml from scratch using Plug-in Form Editor, the Dependencies view doesn't show the just added dependency
When creating geronimo-web.xml from scratch using Plug-in Form Editor, the Dependencies view doesn't show the just added dependency - Key: GERONIMODEVTOOLS-122 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-122 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Sachin Patel Priority: Critical Fix For: 1.2.0 Follow these steps to re-create the problem: 1) Create a new dynamic web project (don't use import of an existing project, this scenario requires that no sys:dependencies element is present in geronimo-web.xml) 2) Open geronimo-web.xml in Geronimo Deployment Plan Editor 3) Switch to Deployment tab 4) Under Dependecies section click on Add 5) Enter values and click Finish 6) You will see that Dependencies view doesn't show the just added dependency Only upon Save, Close and Re-open of geronimo-web.xml you will be able to see the added dependencies. The patch included solves this problem by updating the performFinish() function of class org.apache.geronimo.st.v11.ui.wizards.DependencyWizard. Functionality of performFinish() function of class org.apache.geronimo.st.v11.ui.wizards.SecurityRoleWizard is used as the hint for coming up with this patch. -- 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: (GERONIMODEVTOOLS-122) When creating geronimo-web.xml from scratch using Plug-in Form Editor, the Dependencies view doesn't show the just added dependency
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-122?page=all ] Shiva Kumar H R updated GERONIMODEVTOOLS-122: - Attachment: GERONIMODEVTOOLS-122.patch When creating geronimo-web.xml from scratch using Plug-in Form Editor, the Dependencies view doesn't show the just added dependency - Key: GERONIMODEVTOOLS-122 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-122 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Sachin Patel Priority: Critical Fix For: 1.2.0 Attachments: GERONIMODEVTOOLS-122.patch Follow these steps to re-create the problem: 1) Create a new dynamic web project (don't use import of an existing project, this scenario requires that no sys:dependencies element is present in geronimo-web.xml) 2) Open geronimo-web.xml in Geronimo Deployment Plan Editor 3) Switch to Deployment tab 4) Under Dependecies section click on Add 5) Enter values and click Finish 6) You will see that Dependencies view doesn't show the just added dependency Only upon Save, Close and Re-open of geronimo-web.xml you will be able to see the added dependencies. The patch included solves this problem by updating the performFinish() function of class org.apache.geronimo.st.v11.ui.wizards.DependencyWizard. Functionality of performFinish() function of class org.apache.geronimo.st.v11.ui.wizards.SecurityRoleWizard is used as the hint for coming up with this patch. -- 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: (GERONIMODEVTOOLS-117) Geronimo deployement plan editor crashes with ArrayStoreException when adding dependencies
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-117?page=comments#action_12457322 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-117: -- I wasn't talking about the ArrayStoreException which definitely is fixed in trunk, but rather was mentioning about the problem of Dependencies view (in Geronimo Deployment Plan Editor) not showing the just added dependency. Anyways I have opened a new JIRA GERONIMODEVTOOLS-122 for the same. It has the steps to reproduce the problem I am talking about, as well the fix. Geronimo deployement plan editor crashes with ArrayStoreException when adding dependencies -- Key: GERONIMODEVTOOLS-117 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-117 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.2.0 Environment: http://people.apache.org:80/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.2.0-v200611280908-deployable.zip Reporter: Michael Moser Assigned To: Sachin Patel Fix For: 1.x Trying to add the axis library as dependency to my application. After clicking the Add-button on the deployment configuration tab I get a dialog. When - after entering the data - I click Finish nothing happens. The dialog remains and the .xml file remains as it was. When I hit finish again, the dialog disappears but the XML file still remains unchanged. And the reason is: Unhandled event loop exception java.lang.ArrayStoreException at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:188) at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:619) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:323) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:280) at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:600) at org.apache.geronimo.st.v11.ui.wizards.DependencyWizard.performFinish(DependencyWizard.java:241) at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:680) at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:355) at org.eclipse.jface.dialogs.Dialog$3.widgetSelected(Dialog.java:660) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.apache.geronimo.st.ui.sections.AbstractTableSection$3.widgetSelected(AbstractTableSection.java:217) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) According to NG (news:[EMAIL PROTECTED]) this should have been fixed, but I just downloaded the latest available build (see environment) and the same bug still exists. Michael -- This message is
[jira] Commented: (GERONIMODEVTOOLS-118) Complete Editor Support for specifying Dependencies, Hidden Classes, Non Overridable Classes GBean References in geronimo-web.xml
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-118?page=comments#action_12457325 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-118: -- Apply the patch available in GERONIMODEVTOOLS-122 (https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-122) before testing this new functionality of Dependencies section. Complete Editor Support for specifying Dependencies, Hidden Classes, Non Overridable Classes GBean References in geronimo-web.xml --- Key: GERONIMODEVTOOLS-118 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-118 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Sachin Patel Attachments: GERONIMODEVTOOLS-118.patch, Snapshot-1a.gif, Snapshot-1b.gif, Snapshot-2a.gif, Snapshot-2b.gif, Snapshot-2c.gif, Snapshot-3a.gif, Snapshot-3b.gif, Snapshot-3c.gif Please see the discussion going on about this at dev@geronimo.apache.org mailing list: http://www.mail-archive.com/dev@geronimo.apache.org/msg35865.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-770) HttpBridgeServlet is not initialize when using jetty 6.1pre3
[ https://issues.apache.org/activemq/browse/SM-770?page=all ] Jonas Lim resolved SM-770. -- Resolution: Fixed resolved in trunk : r485654 added call to handler.initialize() before calling context.start() . This should still work using the current jetty version 6.0.1 HttpBridgeServlet is not initialize when using jetty 6.1pre3 Key: SM-770 URL: https://issues.apache.org/activemq/browse/SM-770 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.1 Reporter: Jonas Lim Assigned To: Jonas Lim Fix For: 3.1 The current jetty version is 6.0.1. When updagrading to 6.1pre3, HttpBridgeServlet does not seem to get initialized. -- 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: svn commit: r485321 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/gbean/ geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/ geronimo-kernel/s
Gianny,
Thanks for looking into this. I did consider the easy way out. But
the retrun type is part of the method signature. What happens if we
have
public class Myclass {
public Object getObjectName()
public String getObjectName()
..
}
If JMXUtil was patched which one should it return?
Thanks
Anita
--- Gianny Damour [EMAIL PROTECTED] wrote:
Hi,
I am quickly scanning this commit and I would like to know if it was
not a little bit less intrusive to keep the existing addOperation and
search for the return type of the added operations against the target
gbeanType. This way, developers do not need to specify the return
type of the operations (also, the migration of the existing GBeanInfo
could have been avoided).
After reading GERONIMO-2607, it seems that the goal of the change was
to have a return type defined within JConsole for the GBean
operations. It seems that patching JMXUtil.toMBeanInfo would have
been another implementation approach: while getting the exposed
operations, the GBean class could be searched for returned types. One
of the advantages would have been to keep backward compatibility.
Thanks,
Gianny
On 11/12/2006, at 11:14 AM, [EMAIL PROTECTED] wrote:
Author: akulshreshtha
Date: Sun Dec 10 16:14:46 2006
New Revision: 485321
URL: http://svn.apache.org/viewvc?view=revrev=485321
Log:
GERONIMO-2607 Added returnType to GOperationInfo, This modifies
GBeanInfoBuilder and breaks backward compatibility
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/runtime/GBeanOperation.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/gbean/GBeanInfoTest.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/MockGBean.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/config/MyGBean.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/jmx/JMXUtil.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/logging/log4j/Log4jService.java
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/DynamicGOperationInfo.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
DynamicGOperationInfo.java?view=diffrev=485321r1=485320r2=485321
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java (original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java Sun Dec 10
16:14:46 2006
@@ -24,14 +24,14 @@
*/
public class DynamicGOperationInfo extends GOperationInfo {
public DynamicGOperationInfo(String name) {
-super(name);
+super(name, java.lang.Object);
}
public DynamicGOperationInfo(String name, String[] paramTypes)
{
-super(name, paramTypes);
+super(name, paramTypes, java.lang.Object);
}
public DynamicGOperationInfo(String name, List parameters) {
-super(name, parameters);
+super(name, parameters, java.lang.Object);
}
}
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/GBeanInfoBuilder.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
GBeanInfoBuilder.java?view=diffrev=485321r1=485320r2=485321
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java (original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java Sun Dec 10 16:14:46
2006
@@ -187,8 +187,7 @@
for (Iterator i = source.getOperations().iterator();
i.hasNext();) {
GOperationInfo operationInfo = (GOperationInfo)
i.next();
-operations.put(new GOperationSignature
(operationInfo.getName(),
-operationInfo.getParameterList()),
operationInfo);
+operations.put(new GOperationSignature
Re: svn commit: r485321 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/gbean/ geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/ geronimo-kernel/s
The GOpeartionInfo has a field:
private final String methodName;
Which should really have been targetClass or returnType. Currently
it is initialized to the name of the method! If we must maintain
backward compatibility, I am open to suggestions..
Thanks
Anita
--- Gianny Damour [EMAIL PROTECTED] wrote:
Hi,
I am quickly scanning this commit and I would like to know if it was
not a little bit less intrusive to keep the existing addOperation and
search for the return type of the added operations against the target
gbeanType. This way, developers do not need to specify the return
type of the operations (also, the migration of the existing GBeanInfo
could have been avoided).
After reading GERONIMO-2607, it seems that the goal of the change was
to have a return type defined within JConsole for the GBean
operations. It seems that patching JMXUtil.toMBeanInfo would have
been another implementation approach: while getting the exposed
operations, the GBean class could be searched for returned types. One
of the advantages would have been to keep backward compatibility.
Thanks,
Gianny
On 11/12/2006, at 11:14 AM, [EMAIL PROTECTED] wrote:
Author: akulshreshtha
Date: Sun Dec 10 16:14:46 2006
New Revision: 485321
URL: http://svn.apache.org/viewvc?view=revrev=485321
Log:
GERONIMO-2607 Added returnType to GOperationInfo, This modifies
GBeanInfoBuilder and breaks backward compatibility
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/runtime/GBeanOperation.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/gbean/GBeanInfoTest.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/MockGBean.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/config/MyGBean.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/jmx/JMXUtil.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/logging/log4j/Log4jService.java
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/DynamicGOperationInfo.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
DynamicGOperationInfo.java?view=diffrev=485321r1=485320r2=485321
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java (original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java Sun Dec 10
16:14:46 2006
@@ -24,14 +24,14 @@
*/
public class DynamicGOperationInfo extends GOperationInfo {
public DynamicGOperationInfo(String name) {
-super(name);
+super(name, java.lang.Object);
}
public DynamicGOperationInfo(String name, String[] paramTypes)
{
-super(name, paramTypes);
+super(name, paramTypes, java.lang.Object);
}
public DynamicGOperationInfo(String name, List parameters) {
-super(name, parameters);
+super(name, parameters, java.lang.Object);
}
}
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/GBeanInfoBuilder.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
GBeanInfoBuilder.java?view=diffrev=485321r1=485320r2=485321
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java (original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java Sun Dec 10 16:14:46
2006
@@ -187,8 +187,7 @@
for (Iterator i = source.getOperations().iterator();
i.hasNext();) {
GOperationInfo operationInfo = (GOperationInfo)
i.next();
-operations.put(new GOperationSignature
(operationInfo.getName(),
-operationInfo.getParameterList()),
operationInfo);
+operations.put(new GOperationSignature
(operationInfo.getName(), operationInfo.getParameterList()),
Re: svn commit: r485321 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/gbean/ geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/ geronimo-kernel/s
It is not allowed to have public Object getObjectName() and public String
getObjectName() simultaneously.
--vamsi
On 12/11/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
Gianny,
Thanks for looking into this. I did consider the easy way out. But
the retrun type is part of the method signature. What happens if we
have
public class Myclass {
public Object getObjectName()
public String getObjectName()
..
}
If JMXUtil was patched which one should it return?
Thanks
Anita
--- Gianny Damour [EMAIL PROTECTED] wrote:
Hi,
I am quickly scanning this commit and I would like to know if it was
not a little bit less intrusive to keep the existing addOperation and
search for the return type of the added operations against the target
gbeanType. This way, developers do not need to specify the return
type of the operations (also, the migration of the existing GBeanInfo
could have been avoided).
After reading GERONIMO-2607, it seems that the goal of the change was
to have a return type defined within JConsole for the GBean
operations. It seems that patching JMXUtil.toMBeanInfo would have
been another implementation approach: while getting the exposed
operations, the GBean class could be searched for returned types. One
of the advantages would have been to keep backward compatibility.
Thanks,
Gianny
On 11/12/2006, at 11:14 AM, [EMAIL PROTECTED] wrote:
Author: akulshreshtha
Date: Sun Dec 10 16:14:46 2006
New Revision: 485321
URL: http://svn.apache.org/viewvc?view=revrev=485321
Log:
GERONIMO-2607 Added returnType to GOperationInfo, This modifies
GBeanInfoBuilder and breaks backward compatibility
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/runtime/GBeanOperation.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/gbean/GBeanInfoTest.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/MockGBean.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/config/MyGBean.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/jmx/JMXUtil.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/logging/log4j/Log4jService.java
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/DynamicGOperationInfo.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
DynamicGOperationInfo.java?view=diffrev=485321r1=485320r2=485321
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java (original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java Sun Dec 10
16:14:46 2006
@@ -24,14 +24,14 @@
*/
public class DynamicGOperationInfo extends GOperationInfo {
public DynamicGOperationInfo(String name) {
-super(name);
+super(name, java.lang.Object);
}
public DynamicGOperationInfo(String name, String[] paramTypes)
{
-super(name, paramTypes);
+super(name, paramTypes, java.lang.Object);
}
public DynamicGOperationInfo(String name, List parameters) {
-super(name, parameters);
+super(name, parameters, java.lang.Object);
}
}
Modified: geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/GBeanInfoBuilder.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
GBeanInfoBuilder.java?view=diffrev=485321r1=485320r2=485321
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java (original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java Sun Dec 10 16:14:46
2006
@@ -187,8 +187,7 @@
for (Iterator i = source.getOperations().iterator();
i.hasNext();) {
GOperationInfo operationInfo = (GOperationInfo)
i.next();
-operations.put(new GOperationSignature
(operationInfo.getName(),
-operationInfo.getParameterList()),
Re: Multiple Producers sharing single queue
No i have my own Requestor class in whih i am creating request queue using method : Destination requestQueue = session.createQueue(requestQueueName); I have multiple clients accessing this requestor class...i want to share the request queue among multiple clients so i want to have some method which can check if request queue is already existing or not in case not should create new one else should take the exitsing queue and create producer for that Is there any method which can implement this Thanks for ur reply rajdavies wrote: Do you mean your using the javax.jms.QueueRequestor class ? On 8 Dec 2006, at 22:17, garima015 wrote: no i am using multiple producers also sharing the same request queue. Is there any method to get the existing queue? Thanks amq user wrote: I assume you are running many CONSUMERs to share a same request queue. Then you should use topic instead of queue. All CONSUMER subscribed to that topic will get the message. On 12/8/06, garima015 [EMAIL PROTECTED] wrote: I need an urgent help I have many producers running on different thread need to share the same request queue.I am not getting how to implement this. I try to get some resolutions from FAQ's but was not able to understand the JNDIutil purpose fully also not sure whethar it will be useful in this case or not Any help will be really appreciated -- View this message in context: http://www.nabble.com/Multiple-Producers-sharing-single-queue- tf2783192.html#a7765511 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Multiple- Producers-sharing-single-queue-tf2783192.html#a7766352 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Multiple-Producers-sharing-single-queue-tf2783192.html#a7796124 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Accessing JBI from jsr181 pojo
Not sure if the file got uploaded, here is the xml file: ?xml version=1.0? beans xmlns:jsr181=http://servicemix.apache.org/jsr181/1.0; xmlns:demo=urn:servicemix:soap-binding xmlns:sm=http://servicemix.apache.org/config/1.0; classpath location./location /classpath sm:container id=jbi useMBeanServer=true createMBeanServer=true dumpStats=true statsInterval=10 sm:activationSpecs sm:activationSpec componentName=servicemix-jsr181 endpoint=test-TESTEP service=demo:TESTS destinationService=NewBindingComponent sm:component jsr181:component jsr181:endpoints jsr181:endpoint pojoClass=class1 annotations=none service=demo:TESTS endpoint=bcgi-TESTEP /jsr181:endpoint /jsr181:endpoints /jsr181:component /sm:component /sm:activationSpec sm:activationSpec componentName=NewBindingComponent endpoint=NewBindingComponent service=NewBindingComponent sm:component bean class=NewClass.NewBindingComponent / /sm:component /sm:activationSpec /sm:activationSpecs /sm:container /beans ajayk_goel wrote: I am trying to send message to the BUS from within the pojo but I keep getting Cannot find an instance of the service: serviceName. I am using the soap-binding example from apache-servicemix-3.0-M2-incubating. My xbean file is submitted as an attachment, I was hoping I could set the destination address in the xlm file but seems like adding destinationService here dpes not do anything so my code in the pojo looks like this ServiceMixClient client = new ServiceMixClientFacade(this.context); QName service = new QName(, RTBBindingComponent); EndpointResolver resolver = client.createResolverForService(service); InOut exchange = client.createInOutExchange(); NormalizedMessage inMessage = exchange.createMessage(); inMessage.setProperty(Test,Test); exchange.setService(service); client.send(exchange); What am I missing? -- View this message in context: http://www.nabble.com/Accessing-JBI-from-jsr181-pojo-tf2794472s12049.html#a7796237 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Multiple Producers sharing single queue
Just create a queue in each client as there is really only one queue for a given name in a broker. See... http://incubator.apache.org/activemq/how-do-i-create-new-destinations.html On 12/11/06, garima015 [EMAIL PROTECTED] wrote: No i have my own Requestor class in whih i am creating request queue using method : Destination requestQueue = session.createQueue(requestQueueName); I have multiple clients accessing this requestor class...i want to share the request queue among multiple clients so i want to have some method which can check if request queue is already existing or not in case not should create new one else should take the exitsing queue and create producer for that Is there any method which can implement this Thanks for ur reply rajdavies wrote: Do you mean your using the javax.jms.QueueRequestor class ? On 8 Dec 2006, at 22:17, garima015 wrote: no i am using multiple producers also sharing the same request queue. Is there any method to get the existing queue? Thanks amq user wrote: I assume you are running many CONSUMERs to share a same request queue. Then you should use topic instead of queue. All CONSUMER subscribed to that topic will get the message. On 12/8/06, garima015 [EMAIL PROTECTED] wrote: I need an urgent help I have many producers running on different thread need to share the same request queue.I am not getting how to implement this. I try to get some resolutions from FAQ's but was not able to understand the JNDIutil purpose fully also not sure whethar it will be useful in this case or not Any help will be really appreciated -- View this message in context: http://www.nabble.com/Multiple-Producers-sharing-single-queue- tf2783192.html#a7765511 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Multiple- Producers-sharing-single-queue-tf2783192.html#a7766352 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Multiple-Producers-sharing-single-queue-tf2783192.html#a7796124 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
Re: svn commit: r485477 - /geronimo/server/trunk/pom.xml
I agree with you. But then I thoght I'd use the -DassemblyId param in
one other place in the testsuite; the console-testsuite. The
webconsole-tomcat6 or webconsole-jetty6 car needs to be started and
stopped in the console-testsuite. Instead of using yet another config
param, I thought we could reuse the -DassemblyId.
However, this whole thing is supposed to be temporary. This hack of
getting the container name, the container name itself having the
version number in it, everything. Which is why I didn't modify
tomcat6 back to tomcat
Cheers
Prasad
1) There must be a better way to get the container type, either from
the running server or from geronimoHome or some such place, instead of
using too many
On 12/11/06, Jason Dillon [EMAIL PROTECTED] wrote:
Why are we giving the assembly id's the version suffix here? I don't
think we want to do this. I think the ids, which are simply to
select which assembly to use should be tomcat or jetty. IMO, this is
just that much more to type... for no real gain.
These are assembly ids, not artifact ids... they are supposed to be
short and simple. IMO this change only complicates them slightly by
forcing people to remember which jetty version they are using. And I
hope that we are not going to start supporting a bunch of different
jetty or tomcat versions per codeline... that would be a huge,
massive, ugly mess.
I recommend reverting this change, and changing the id's of the
tomcat6* bits to tomcat*.
--jason
On Dec 10, 2006, at 7:22 PM, [EMAIL PROTECTED] wrote:
Author: prasad
Date: Sun Dec 10 19:22:47 2006
New Revision: 485477
URL: http://svn.apache.org/viewvc?view=revrev=485477
Log:
* changing assemblyId to jetty6 to make it consistent with tomcat6
Modified:
geronimo/server/trunk/pom.xml
Modified: geronimo/server/trunk/pom.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?
view=diffrev=485477r1=485476r2=485477
==
--- geronimo/server/trunk/pom.xml (original)
+++ geronimo/server/trunk/pom.xml Sun Dec 10 19:22:47 2006
@@ -1256,7 +1256,7 @@
configuration
assemblies
assembly
-idjetty/id
+idjetty6/id
groupIdorg.apache.geronimo.assemblies/groupId
artifactIdgeronimo-jetty6-jee5/
artifactId
version${version}/version
@@ -1265,7 +1265,7 @@
/assembly
assembly
-idjetty-minimal/id
+idjetty6-minimal/id
groupIdorg.apache.geronimo.assemblies/groupId
artifactIdgeronimo-jetty-
minimal/artifactId
version${version}/version
@@ -1292,7 +1292,7 @@
/assembly
/assemblies
-defaultAssemblyIdjetty/defaultAssemblyId
+defaultAssemblyIdjetty6/defaultAssemblyId
optionSets
optionSet
Re: No legacy repos for Geronimo projects using Maven2
Jason V, Copying you for your feedback and awareness. On Dec 8, 2006, at 6:06 PM, Jason Dillon wrote: Maven does not behave well with a mix of default and legacy repos. I have gone through and moved all legacy repos only to the modules where they are used, and in some cases imported a module-local repo to hold those artifacts so that the build does not need to include a legacy repo. A few weeks ago I finally removed all the legacy repos and now they are starting to creep back in. Specifically the java.net repo, which is a legacy repo for jstl muck, was added. Something needs to be done about this, so this repo can be moved out of the project root, or removed altogether. The addition of the legacy repo is known to cause problems with SNAPSHOT resolution, and can get itself into a state with local metadata what other artifacts will start to resolve in very, very, very strange ways. So... don't use them. This is compounded even more by the poor network connectivity (and maybe connection limiting) done by the java.net repo, which is causing builds to timeout all over the place. * * * Basically... maven remote repos suck ass... and should be limited in use as much as possible if we want a stable and repeatable build for any of our projects. In a corporate environment, this problem is easily solved by managing a local repo which has copies of all of the artifacts which are required to build, often times stored in version control and labeled with project using it. If we are going to continue to use Maven (which I'm starting to really wonder if it is worth it), then we really need to address this problem... otherwise it will be an ongoing head-ache for the foreseeable future... and really builds will never reach any level of stability and will almost never have any ability to be reproduced. Ugh, I've already spent so many hours debugging other peoples reported issues, which most of the time end up resolve to problems with Maven. I've been away for a little bit working on build automation and in the few weeks I'm gone the build system has already regressed in a few areas, and IMO its well on its way to becoming out of control again while quickly. I am starting to believe that Maven promotes that chaos, especially so for larger projects. I also believe that Maven promotes build instability, where at times someone might change some dependency which could completely hose our build with out anyone really knowing why or having any paper trail (change logs) to debug it. IMO... the *ONLY* way to resolve these issues with Maven it so have *ONE* repository which holds all artifacts used by our projects, and have that repository under SVN control. So, for this example of jstl on java.net, those artifacts would be checked into the *ONE* repository and life goes on, no new pom config to configure a new repo, no side-effects of poor network connectivity to remote repositories, no strange behavior due to legacy vs. default layout metadata muck. If we were using Ant, then we would have needed to implement something like this already. Though its more cumbersome with Maven since most of the crap that is downloaded is for Maven itself, not for our dependencies, our dependencies are much, much, much easier to manage than the stew of jars required to make Maven and its horde of plugins work. The more I use Maven, the more I dislike it... and I don't really see a light at the end of the tunnel either... mvn is almost as slow moving as Geronimo has been for the past year, so not sure how viable it will be as a build tool for the future if they do not provide more bug fixes sooner and faster. At this point... and ya, I may be in a bad mood now... I don't think that mvn is an appropriate tool for building production quality products... period. --jason Matt Hogstrom [EMAIL PROTECTED]
Re: MyFaces 1.2 SNAPSHOT update
Ok looks like the MyFaces team is not going to product any 1.2 snapshots quite yet, but they have provided permission for me to include the 1.2 myfaces snapshots I've build into M1. I just need some instructions on how and where to this. Please advise. Thanks Tim Tim McConnell wrote: Looks like the MyFaces build 1.2 is using Continuum to automate their builds. It's supposed to automatically publish their snapshots but they have discovered after my query that it's doing a 'mvn install' instead of an 'mvn deploy'. So that's been fixed. Unfortunately though the MyFaces 1.2 build on Continuum isn't working although I can build it fine. More information to follow Thanks. Tim
Re: svn commit: r485321 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/gbean/ geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/ geronimo-kernel/s
When we add inteface using addInterface(..), we can end up with two
methods like this. This is not a very good example because the
objectName will end up as an attribute in GBeanInfoBuilder, not an
operation.
thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
It is not allowed to have public Object getObjectName() and public
String
getObjectName() simultaneously.
--vamsi
On 12/11/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
Gianny,
Thanks for looking into this. I did consider the easy way out.
But
the retrun type is part of the method signature. What happens if we
have
public class Myclass {
public Object getObjectName()
public String getObjectName()
..
}
If JMXUtil was patched which one should it return?
Thanks
Anita
--- Gianny Damour [EMAIL PROTECTED] wrote:
Hi,
I am quickly scanning this commit and I would like to know if it
was
not a little bit less intrusive to keep the existing addOperation
and
search for the return type of the added operations against the
target
gbeanType. This way, developers do not need to specify the return
type of the operations (also, the migration of the existing
GBeanInfo
could have been avoided).
After reading GERONIMO-2607, it seems that the goal of the change
was
to have a return type defined within JConsole for the GBean
operations. It seems that patching JMXUtil.toMBeanInfo would have
been another implementation approach: while getting the exposed
operations, the GBean class could be searched for returned types.
One
of the advantages would have been to keep backward compatibility.
Thanks,
Gianny
On 11/12/2006, at 11:14 AM, [EMAIL PROTECTED] wrote:
Author: akulshreshtha
Date: Sun Dec 10 16:14:46 2006
New Revision: 485321
URL: http://svn.apache.org/viewvc?view=revrev=485321
Log:
GERONIMO-2607 Added returnType to GOperationInfo, This modifies
GBeanInfoBuilder and breaks backward compatibility
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/runtime/GBeanOperation.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/gbean/GBeanInfoTest.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/MockGBean.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/config/MyGBean.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/jmx/JMXUtil.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/logging/log4j/Log4jService.java
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/DynamicGOperationInfo.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
DynamicGOperationInfo.java?view=diffrev=485321r1=485320r2=485321
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java (original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java Sun Dec 10
16:14:46 2006
@@ -24,14 +24,14 @@
*/
public class DynamicGOperationInfo extends GOperationInfo {
public DynamicGOperationInfo(String name) {
-super(name);
+super(name, java.lang.Object);
}
public DynamicGOperationInfo(String name, String[]
paramTypes)
{
-super(name, paramTypes);
+super(name, paramTypes, java.lang.Object);
}
public DynamicGOperationInfo(String name, List parameters)
{
-super(name, parameters);
+super(name, parameters, java.lang.Object);
}
}
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/GBeanInfoBuilder.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
GBeanInfoBuilder.java?view=diffrev=485321r1=485320r2=485321
==
---
Re: MyFaces 1.2 SNAPSHOT update
Didn't Paul just publish a snapshot? Wherever that was, can we just publish it there? On Dec 11, 2006, at 10:14 AM, Tim McConnell wrote: Ok looks like the MyFaces team is not going to product any 1.2 snapshots quite yet, but they have provided permission for me to include the 1.2 myfaces snapshots I've build into M1. I just need some instructions on how and where to this. Please advise. Thanks Tim Tim McConnell wrote: Looks like the MyFaces build 1.2 is using Continuum to automate their builds. It's supposed to automatically publish their snapshots but they have discovered after my query that it's doing a 'mvn install' instead of an 'mvn deploy'. So that's been fixed. Unfortunately though the MyFaces 1.2 build on Continuum isn't working although I can build it fine. More information to follow Thanks. Tim -sachin
Re: svn commit: r483201 [1/2] - in /geronimo/server/trunk: applications/console/geronimo-console-framework/ applications/console/geronimo-console-standard/ applications/demo/ applications/geronimo-ca-
FYI -- the following artifactIds are now renamed to use tomcat6. org.apache.geronimo.configs/tomcat6 org.apache.geronimo.configs/tomcat6-deployer org.apache.geronimo.modules/geronimo-tomcat6 org.apache.geronimo.modules/geronimo-tomcat6-builder org.apache.geronimo.assemblies/geronimo-tomcat6-jee5 org.apache.geronimo.assemblies/geronimo-tomcat6-minimal Best wishes, Paul On 12/6/06, David Jencks [EMAIL PROTECTED] wrote: I'm not sure who I've talked to about this or where but I think really really strongly that we should include the major version number of the projects we integrate in our artifactIds relating to those external projects. A couple people have pointed out that something like jetty_6 or geronimo-jetty6-builder is more consistent with our spec naming than jetty6 or geronimo-jetty6-naming. I don't really care about that, although I think the shorter tomcat6 is perfectly clear and easier to type. Other stuff: axis axis1 cxf cxf1 openjpa openjpa1 I think this will really reduce confusion about what is running in a server. So, I'd like the tomcat modules to be renamed geronimo-tomcat6, geronimo-tomcat6-builder, tomcat6, tomcat6-deployer. Can we discuss and settle this soon? thanks david jencks ps. I'm planning to remove the jetty[5] stuff from trunk soon.
[jira] Created: (GERONIMO-2642) welcome app not included in the jetty assembly.
welcome app not included in the jetty assembly. --- Key: GERONIMO-2642 URL: http://issues.apache.org/jira/browse/GERONIMO-2642 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.0-M1 Reporter: Prasad Kashyap Fix For: 2.0-M1 geronimo-welcome-jetty not included in the jetty assembly -- 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
Geronimo v1.2 documentation
Hi All, I updated most of the Geronimo v1.2 doc. I couldn't get rid of the *SNAPSHOT* for some screen captures so I guess it will be better to wait till the snapshot is removed from the build to finish updating those articles. I listed at the top of the page those articles that have not been updated yet. Here is the link http://cwiki.apache.org/GMOxDOC12/documentation.html Comments welcome! Help wanted! ;-) Cheers! Hernan
[jira] Assigned: (GERONIMO-2642) welcome app not included in the jetty assembly.
[ http://issues.apache.org/jira/browse/GERONIMO-2642?page=all ] Prasad Kashyap reassigned GERONIMO-2642: Assignee: Joe Bohn Creating this just a placeholder and assigning this to you since you said you'll look at it. You may reassign this to the right person, if you wish. welcome app not included in the jetty assembly. --- Key: GERONIMO-2642 URL: http://issues.apache.org/jira/browse/GERONIMO-2642 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0-M1 Reporter: Prasad Kashyap Assigned To: Joe Bohn Fix For: 2.0-M1 geronimo-welcome-jetty not included in the jetty assembly -- 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: r483201 [1/2] - in /geronimo/server/trunk: applications/console/geronimo-console-framework/ applications/console/geronimo-console-standard/ applications/demo/ applications/geronimo-ca-
It would be nice if before renaming/moving directories, a note announcing the change could be sent to the list. This will give people a chance to rename their local copies and avoid getting them wiped out by an svn update. Thanks Anita --- Paul McMahan [EMAIL PROTECTED] wrote: FYI -- the following artifactIds are now renamed to use tomcat6. org.apache.geronimo.configs/tomcat6 org.apache.geronimo.configs/tomcat6-deployer org.apache.geronimo.modules/geronimo-tomcat6 org.apache.geronimo.modules/geronimo-tomcat6-builder org.apache.geronimo.assemblies/geronimo-tomcat6-jee5 org.apache.geronimo.assemblies/geronimo-tomcat6-minimal Best wishes, Paul On 12/6/06, David Jencks [EMAIL PROTECTED] wrote: I'm not sure who I've talked to about this or where but I think really really strongly that we should include the major version number of the projects we integrate in our artifactIds relating to those external projects. A couple people have pointed out that something like jetty_6 or geronimo-jetty6-builder is more consistent with our spec naming than jetty6 or geronimo-jetty6-naming. I don't really care about that, although I think the shorter tomcat6 is perfectly clear and easier to type. Other stuff: axis axis1 cxf cxf1 openjpa openjpa1 I think this will really reduce confusion about what is running in a server. So, I'd like the tomcat modules to be renamed geronimo-tomcat6, geronimo-tomcat6-builder, tomcat6, tomcat6-deployer. Can we discuss and settle this soon? thanks david jencks ps. I'm planning to remove the jetty[5] stuff from trunk soon. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
Re: svn commit: r483201 [1/2] - in /geronimo/server/trunk: applications/console/geronimo-console-framework/ applications/console/geronimo-console-standard/ applications/demo/ applications/geronimo-ca-
Should the configs that are specific to these artifacts also be renamed? For example we have org.apache.geronimo.configs/webconsole-jetty6 but org.apache.geronimo.configs/webconsole-tomcat and the same for dojo. I'm asking because I was just about to update the welcome-jetty to welcome-jetty6 and include it in the jee5 assembly. Joe Paul McMahan wrote: FYI -- the following artifactIds are now renamed to use tomcat6. org.apache.geronimo.configs/tomcat6 org.apache.geronimo.configs/tomcat6-deployer org.apache.geronimo.modules/geronimo-tomcat6 org.apache.geronimo.modules/geronimo-tomcat6-builder org.apache.geronimo.assemblies/geronimo-tomcat6-jee5 org.apache.geronimo.assemblies/geronimo-tomcat6-minimal Best wishes, Paul On 12/6/06, David Jencks [EMAIL PROTECTED] wrote: I'm not sure who I've talked to about this or where but I think really really strongly that we should include the major version number of the projects we integrate in our artifactIds relating to those external projects. A couple people have pointed out that something like jetty_6 or geronimo-jetty6-builder is more consistent with our spec naming than jetty6 or geronimo-jetty6-naming. I don't really care about that, although I think the shorter tomcat6 is perfectly clear and easier to type. Other stuff: axis axis1 cxf cxf1 openjpa openjpa1 I think this will really reduce confusion about what is running in a server. So, I'd like the tomcat modules to be renamed geronimo-tomcat6, geronimo-tomcat6-builder, tomcat6, tomcat6-deployer. Can we discuss and settle this soon? thanks david jencks ps. I'm planning to remove the jetty[5] stuff from trunk soon.
[jira] Commented: (AMQ-591) add a per message authorization hook so that content-based authorization can be performed using a special plugin
[ https://issues.apache.org/activemq/browse/AMQ-591?page=comments#action_37644 ] John Kurtz commented on AMQ-591: How does this relate to bug AMQ-775? http://issues.apache.org/activemq/browse/AMQ-775 add a per message authorization hook so that content-based authorization can be performed using a special plugin Key: AMQ-591 URL: https://issues.apache.org/activemq/browse/AMQ-591 Project: ActiveMQ Issue Type: New Feature Reporter: james strachan Assigned To: james strachan Fix For: 4.0 RC2 Users may want to look in the message at headers to decide if a user can or cannot consume a message -- 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: No legacy repos for Geronimo projects using Maven2
Also, keep in mind that there is no way to bypass the local repository afaik. So if a bad artifact goes into the user local repo, it may disturb Geronimo's build, even if Geronimo build only use a single svn based remote repo. In such a case, the only way to ensure that the build will work is to start from a clean local repo. On 12/9/06, Jason Dillon [EMAIL PROTECTED] wrote: On Dec 8, 2006, at 6:41 PM, Prasad Kashyap wrote: ... At this point... and ya, I may be in a bad mood now... I don't think that mvn is an appropriate tool for building production quality products... period. I hear ye. I share the pain. But I fear the alternative - spending considerable time migrating to another build system. Ya, I know... I'm not suggesting that we change any time soon. But I do fear that there is going to be some serious ongoing pain. When you return from your bad mood to your jolly good ole' self again, I dunno... I'm jaded now... good ole jolly jason was eaten by the big angry maven monster... :-P can you please shed more light on what it would take to have this *ONE* repo; it's pros and cons and such.. I've sent a few emails about this in the past. Major hurtles to this are going to be sysadmin/network overheads, ASF infra politics, and of course keeping the artifacts in sync. There are just way to many things that need to get downloaded, making the window for problems really quite massive. I'm still trying to figure out how to effectively workaround this problem for an open community... in a corporate setting this is a no brainer, setup a machine, back it up, setup proximity or maven-proxy to aggregate remote repos, then create a few local repos backed by svn to hold custom artifacts or specific versions to help reduce risk incurred by remote artifact stability. Then each project just lists that one repo. This works well, but due to the way maven works, other dependencies may list repos, which will then get picked up and used for artifacts selection, which tends to pollute the sanity and stability, but usually not too much. But its yet another flaw in maven's architecture which while its flexible and easy for smaller projects, its nearly impossible to make any sort of assurances for larger more complicated projects. Actually even for smaller ones it makes it very very difficult to ensure build stability over the life of the project (past build repeatability and assumed future compatibility, as at any time someone could publish a plugin or artifact which completely breaks your build, often times requiring days to debug why). The only way around this is to have total ownership of imported build artifacts and an effective paper trail for changes (ie svn change logs). While maven has made many things simpler... it really has made it a lot harder to implement stable, reliable and durable builds. :-( Anyways, all I can really think of to step around this problem, is to checkin all of the artifacts which are needed into svn, configure the build to use a checkout of that repo for its local and then always run offline. And periodically update the svn repo from remotes as well as manage some artifacts by hand. Essentially removing any remoteness from Maven, which is IMO key to making builds stable, reliable and durable. Svn has all the artifacts needed, so svn co will get you the right bits, svn up will make sure its the latest, so no need to keep making all those network calls to check for artifacts, which will speed the build up dramatically. Svn will always have a trail of who changed what when which can be easily correlated to build failures using a CI tool. Mysterious dependency download, metadata corruption, bad network connections basically go a way from the list of normal problems we run into. The repository gets labeled when the software gets labeled, so you can *always* go back in time, checkout an old release and build it... and have a very, very, very high chance that it will work with no fuss, only things which may break it would be environment related (deep windows folder, wrong jdk version, missing heap settings, etc). Dunno if there are other options really... maybe... but I can't think of it at the moment. I think the mvn plugin system is good, getting better once they fix some of the annoying bugs... and even better once they document the apis more. Wish the dang pom was not so verbose... or need to carry version details into each and every pom... but those are all minor. The major issue is the remote repo. Once you eliminate that, then mvn starts to look a whole lot more attractive for serious production builds. --jason -- Cheers, Guillaume Nodet
[jira] Commented: (AMQ-775) MessageAuthorizationPolicy doesn't work
[ https://issues.apache.org/activemq/browse/AMQ-775?page=comments#action_37645 ] John Kurtz commented on AMQ-775: cross reference to: AMQ-591... https://issues.apache.org/activemq/browse/AMQ-591 MessageAuthorizationPolicy doesn't work --- Key: AMQ-775 URL: https://issues.apache.org/activemq/browse/AMQ-775 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0 Environment: windows NT 2003 server Reporter: Ning Li Use default config, set a MessageAuthorizationPolicy to BrokerService and start the broker. There are several issues: 1) In BrokerService::startTransportConnector() method, connector.setMessageAuthorizationPolicy(policy); is in the wrong place, it should be moved to almost the very end of the method, otherwise if you use JMX, the ManageedTransportConnector won't have authorization policy info. 2) ManagedTransportConnector doesn't pass the auth policy to ManagedTransport, I think the easiest way to fix it is in AbstractConnection constructor, adding this line: this.messageAuthorizationPolicy = connector.getMessageAuthorizationPolicy(); and remove this line: answer.setMessageAuthorizationPolicy(messageAuthorizationPolicy); from TransportConnector::createConnection(), then it will work for both TransportConnection and ManagedTransportConnection 3) AbstrctConnection doesn't pass the auth policy to ConnectionContext, I think this can be fixed by adding this line: context.setMessageAuthorizationPolicy(this.getMessageAuthorizationPolicy()); to AbstractConnection::processAddConnection() method. Now the auth policy can be reached by MessageAuthorizationPolicy::isAllowedToConsume(ConnectionContext context, Message message) method, but the real problem is message value is null, but we need to use it to check right, some of the right information is a property inside the message. Please take a look at the problem, thanks -- 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: (GERONIMO-2643) Stack trace (due to amq) while shutting down Geronimo
Stack trace (due to amq) while shutting down Geronimo - Key: GERONIMO-2643 URL: http://issues.apache.org/jira/browse/GERONIMO-2643 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: startup/shutdown Affects Versions: 2.0-M1 Reporter: Prasad Kashyap Assigned To: Anita Kulshreshtha Fix For: 2.0-M1 Long stacktrace when the Geronimo server is shut down. http://www.nabble.com/forum/ViewPost.jtp?post=7735287framed=y Creating this JIRA just as a placeholder so that we may track it. Anita, I took the liberty of assigning this to you since you said on the devlist that you were investigating it. Please fee free to reassign it if you think otherwise. -- 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
Patches in RTC (Geronimo - 2006-12-11)
Geronimo - Monday, December 11, 2006 4 Patches in RTC [GERONIMO-2485] PersistenceUnitGBean needs a NamespaceDrivenDeployer - Assignee: David Jencks - Reporter: David Jencks - Created: Wed Oct 11 21:23:29 GMT 2006 - Updated: Thu Dec 07 20:28:27 GMT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2485 [GERONIMO-1277] Change group-id to org.apache.geronimo - Assignee: Jason Dillon - Reporter: Dain Sundstrom - Created: Sat Dec 03 10:55:12 GMT 2005 - Updated: Tue Nov 07 23:57:44 GMT 2006 - Votes: 3 1 David Jencks 2 Donald Woods 3 Vamsavardhana Reddy - http://issues.apache.org/jira/browse/GERONIMO-1277 [GERONIMO-2015] Let's replace JKS to PKCS12 key store type - Assignee: Unassigned - Reporter: Nikolay Chugunov - Created: Fri May 12 21:54:17 GMT 2006 - Updated: Wed Dec 06 06:57:11 GMT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2015 [GERONIMODEVTOOLS-112] Loading deployment plan editor on empty file should auto-create plan - Assignee: Sachin Patel - Reporter: Sachin Patel - Created: Wed Oct 11 21:45:57 GMT 2006 - Updated: Wed Dec 06 14:11:15 GMT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-112 NOTE: This email is generated and does not constitute and offical vote or vote result. All official voting is done on the dev list. If you do not see your issue here, click the Begin RTC Review link under the Available Workflow Actions of the JIRA page. If you do not see your vote here, click the Vote link under the Operations section of the JIRA page. *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE *** Template: http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm
[jira] Updated: (GERONIMO-2638) Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile
[ http://issues.apache.org/jira/browse/GERONIMO-2638?page=all ] Sachin Patel updated GERONIMO-2638: --- Fix Version/s: 2.0-M2 (was: 2.0-M1) Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile --- Key: GERONIMO-2638 URL: http://issues.apache.org/jira/browse/GERONIMO-2638 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 2.0-M2 Attachments: GERONIMO-1526-v1.2.patch -- 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: Stack trace while shutting down amq in geronimo 2.0
Prasad, I am hoping that the fix Dain promised for the branch might help with this too.. I am waiting for it :) On Dec 7, 2006, at 10:32 AM, Dain Sundstrom wrote: We have an exception being thrown in shutdown from GBeanBinding.removeBinding():159 and I'll fix that today. http://www.nabble.com/1.2-Beta-Tasks-p7744896.html Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: The shutdown of geronimo-tomcat-minimal server produces this trace: 12:34:10,671 INFO [root] -- 12:38:32,171 WARN [BasicLifecycleMonitor] Exception occured while notifying listener java.lang.NullPointerException at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159) at org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireStoppedEvent(BasicLifecycleMonitor.java:259) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:359) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfig Thanks Anita Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.
Re: svn commit: r483201 [1/2] - in /geronimo/server/trunk: applications/console/geronimo-console-framework/ applications/console/geronimo-console-standard/ applications/demo/ applications/geronimo-ca-
My apologies, I had thought that the discussion on dev plus mail from scm would be sufficient notification but I could have also sent a heads-up notice. I also didn't realize svn could lose your local changes from an update -- usually it automatically merges them or marks a conflict and saves your files. I hope there is a way to recover your lost changes. Best wishes, Paul On 12/11/06, anita kulshreshtha [EMAIL PROTECTED] wrote: It would be nice if before renaming/moving directories, a note announcing the change could be sent to the list. This will give people a chance to rename their local copies and avoid getting them wiped out by an svn update. Thanks Anita --- Paul McMahan [EMAIL PROTECTED] wrote: FYI -- the following artifactIds are now renamed to use tomcat6. org.apache.geronimo.configs/tomcat6 org.apache.geronimo.configs/tomcat6-deployer org.apache.geronimo.modules/geronimo-tomcat6 org.apache.geronimo.modules/geronimo-tomcat6-builder org.apache.geronimo.assemblies/geronimo-tomcat6-jee5 org.apache.geronimo.assemblies/geronimo-tomcat6-minimal Best wishes, Paul On 12/6/06, David Jencks [EMAIL PROTECTED] wrote: I'm not sure who I've talked to about this or where but I think really really strongly that we should include the major version number of the projects we integrate in our artifactIds relating to those external projects. A couple people have pointed out that something like jetty_6 or geronimo-jetty6-builder is more consistent with our spec naming than jetty6 or geronimo-jetty6-naming. I don't really care about that, although I think the shorter tomcat6 is perfectly clear and easier to type. Other stuff: axis axis1 cxf cxf1 openjpa openjpa1 I think this will really reduce confusion about what is running in a server. So, I'd like the tomcat modules to be renamed geronimo-tomcat6, geronimo-tomcat6-builder, tomcat6, tomcat6-deployer. Can we discuss and settle this soon? thanks david jencks ps. I'm planning to remove the jetty[5] stuff from trunk soon. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
Re: svn commit: r483201 [1/2] - in /geronimo/server/trunk: applications/console/geronimo-console-framework/ applications/console/geronimo-console-standard/ applications/demo/ applications/geronimo-ca-
On 12/11/06, Joe Bohn [EMAIL PROTECTED] wrote: Should the configs that are specific to these artifacts also be renamed? For example we have org.apache.geronimo.configs/webconsole-jetty6 but org.apache.geronimo.configs/webconsole-tomcat and the same for dojo. I'm asking because I was just about to update the welcome-jetty to welcome-jetty6 and include it in the jee5 assembly. I don't think that's necessarily required but I'm happy to change those artifactIds as well if others think it would be beneficial. Best wishes, Paul
Re: svn commit: r483201 [1/2] - in /geronimo/server/trunk: applications/console/geronimo-console-framework/ applications/console/geronimo-console-standard/ applications/demo/ applications/geronimo-ca-
No problem.. It was late at night. My commit failed because something was not up-to-date. So I did svn update without checking the commit messages. The tomcat and tomcat-builder modules were gone! We must remember that everyone does not have access to commit messages. Thanks Anita --- Paul McMahan [EMAIL PROTECTED] wrote: My apologies, I had thought that the discussion on dev plus mail from scm would be sufficient notification but I could have also sent a heads-up notice. I also didn't realize svn could lose your local changes from an update -- usually it automatically merges them or marks a conflict and saves your files. I hope there is a way to recover your lost changes. Best wishes, Paul On 12/11/06, anita kulshreshtha [EMAIL PROTECTED] wrote: It would be nice if before renaming/moving directories, a note announcing the change could be sent to the list. This will give people a chance to rename their local copies and avoid getting them wiped out by an svn update. Thanks Anita --- Paul McMahan [EMAIL PROTECTED] wrote: FYI -- the following artifactIds are now renamed to use tomcat6. org.apache.geronimo.configs/tomcat6 org.apache.geronimo.configs/tomcat6-deployer org.apache.geronimo.modules/geronimo-tomcat6 org.apache.geronimo.modules/geronimo-tomcat6-builder org.apache.geronimo.assemblies/geronimo-tomcat6-jee5 org.apache.geronimo.assemblies/geronimo-tomcat6-minimal Best wishes, Paul On 12/6/06, David Jencks [EMAIL PROTECTED] wrote: I'm not sure who I've talked to about this or where but I think really really strongly that we should include the major version number of the projects we integrate in our artifactIds relating to those external projects. A couple people have pointed out that something like jetty_6 or geronimo-jetty6-builder is more consistent with our spec naming than jetty6 or geronimo-jetty6-naming. I don't really care about that, although I think the shorter tomcat6 is perfectly clear and easier to type. Other stuff: axis axis1 cxf cxf1 openjpa openjpa1 I think this will really reduce confusion about what is running in a server. So, I'd like the tomcat modules to be renamed geronimo-tomcat6, geronimo-tomcat6-builder, tomcat6, tomcat6-deployer. Can we discuss and settle this soon? thanks david jencks ps. I'm planning to remove the jetty[5] stuff from trunk soon. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
Re: Multiple Producers sharing single queue
Thanks for ur reply.I got my mistake. James.Strachan wrote: Just create a queue in each client as there is really only one queue for a given name in a broker. See... http://incubator.apache.org/activemq/how-do-i-create-new-destinations.html On 12/11/06, garima015 [EMAIL PROTECTED] wrote: No i have my own Requestor class in whih i am creating request queue using method : Destination requestQueue = session.createQueue(requestQueueName); I have multiple clients accessing this requestor class...i want to share the request queue among multiple clients so i want to have some method which can check if request queue is already existing or not in case not should create new one else should take the exitsing queue and create producer for that Is there any method which can implement this Thanks for ur reply rajdavies wrote: Do you mean your using the javax.jms.QueueRequestor class ? On 8 Dec 2006, at 22:17, garima015 wrote: no i am using multiple producers also sharing the same request queue. Is there any method to get the existing queue? Thanks amq user wrote: I assume you are running many CONSUMERs to share a same request queue. Then you should use topic instead of queue. All CONSUMER subscribed to that topic will get the message. On 12/8/06, garima015 [EMAIL PROTECTED] wrote: I need an urgent help I have many producers running on different thread need to share the same request queue.I am not getting how to implement this. I try to get some resolutions from FAQ's but was not able to understand the JNDIutil purpose fully also not sure whethar it will be useful in this case or not Any help will be really appreciated -- View this message in context: http://www.nabble.com/Multiple-Producers-sharing-single-queue- tf2783192.html#a7765511 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Multiple- Producers-sharing-single-queue-tf2783192.html#a7766352 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Multiple-Producers-sharing-single-queue-tf2783192.html#a7796124 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/Multiple-Producers-sharing-single-queue-tf2783192.html#a7798819 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: MyFaces 1.2 SNAPSHOT update
IIUC the myfaces jar isn't part of an official (i.e. voted upon) release or even considered a snapshot and we don't know if/when/how/where it will be published. Can we localize it in the module that needs it? See the dojo.zip in applications/geronimo-dojo/repository for an example. Best wishes, Paul On 12/11/06, Sachin Patel [EMAIL PROTECTED] wrote: Didn't Paul just publish a snapshot? Wherever that was, can we just publish it there? On Dec 11, 2006, at 10:14 AM, Tim McConnell wrote: Ok looks like the MyFaces team is not going to product any 1.2 snapshots quite yet, but they have provided permission for me to include the 1.2 myfaces snapshots I've build into M1. I just need some instructions on how and where to this. Please advise. Thanks Tim Tim McConnell wrote: Looks like the MyFaces build 1.2 is using Continuum to automate their builds. It's supposed to automatically publish their snapshots but they have discovered after my query that it's doing a 'mvn install' instead of an 'mvn deploy'. So that's been fixed. Unfortunately though the MyFaces 1.2 build on Continuum isn't working although I can build it fine. More information to follow Thanks. Tim -sachin
Re: svn commit: r483773 - in /geronimo/server/trunk: ./ applications/console/geronimo-console-standard/ applications/geronimo-examples/geronimo-jsp-examples/ configs/webconsole-jetty6/ configs/webcons
David, I wanted to get something committed that works for now. With trunk rev. 485719 I included jstl as a dependency in modules/geronimo-web-2.5-builder as well as in configs/jetty6 and configs/tomcat6 so that it would always be in the classpath for an application. I can change this if there is a better way. Thanks, Joe Joe Bohn wrote: David, I need a little direction. I know that there is someplace/way to add a dependency for the default environment. Such a dependency is then added dynamically to the module that is being deployed. At least I think that is what I recall hearing you mention before. But I'm having trouble finding the right place to add these dependencies. I tried adding the dependencies to the pom for modules/geronimo-web-2.5-builder but they didn't carry over to the deployed module. I also tried adding them to modules/geronimo-jetty6-builder and modules/geronimo-tomcat-builder with the same poor results. Adding them to the builders allowed me to deploy the applications successfully but the jars were never added to the deployed module's classpath and so the applications can't run. I'm sure I could force it to work if I added the dependencies directly in configs/tomcat and configs/jetty6 but that doesn't seem right since neither tomcat or jetty require the JSTL jars ... it's really the deployed applications running in these containers that might need them. Thanks in advance for your help, Joe Joe Bohn wrote: Yes, Paul is correct. It's not a spec jar so I'll include it in the default environment for the builder as David recommends. Thanks, Joe David Jencks wrote: On Dec 8, 2006, at 12:48 AM, Paul McMahan wrote: Should the JSTL classes be made available in the web container instead of being included in the web apps? Looking at the spec that seems to be the case. If this is a spec jar then according to current convention it should be included in the dependencies of the spec car. If not it should be included in the default environment for each web builder. thanks david jencks Best wishes, Paul On 12/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jbohn Date: Thu Dec 7 17:53:34 2006 New Revision: 483773 URL: http://svn.apache.org/viewvc?view=revrev=483773 Log: GERONIMO-2536 Update jetty6 and tomcat jee5 assemblies to include jstl 1.2 from glassfish Also update jspc-maven-plugin to 1.4.7-SNAPSHOT to pick up jgenender's inclusion of jasper 6 (Thanks Jeff) Modified: geronimo/server/trunk/applications/console/geronimo-console- standard/pom.xml geronimo/server/trunk/applications/geronimo-examples/geronimo- jsp-examples/pom.xml geronimo/server/trunk/configs/webconsole-jetty6/pom.xml geronimo/server/trunk/configs/webconsole-jetty6/src/plan/plan.xml geronimo/server/trunk/configs/webconsole-tomcat/pom.xml geronimo/server/trunk/configs/webconsole-tomcat/src/plan/plan.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/applications/console/geronimo- console-standard/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ applications/console/geronimo-console-standard/pom.xml? view=diffrev=483773r1=483772r2=483773 = = --- geronimo/server/trunk/applications/console/geronimo-console- standard/pom.xml (original) +++ geronimo/server/trunk/applications/console/geronimo-console- standard/pom.xml Thu Dec 7 17:53:34 2006 @@ -131,7 +131,7 @@ /dependency dependency -groupIdjavax.servlet/groupId +groupIdjstl/groupId artifactIdjstl/artifactId scopeprovided/scope /dependency Modified: geronimo/server/trunk/applications/geronimo-examples/ geronimo-jsp-examples/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ applications/geronimo-examples/geronimo-jsp-examples/pom.xml? view=diffrev=483773r1=483772r2=483773 = = --- geronimo/server/trunk/applications/geronimo-examples/geronimo- jsp-examples/pom.xml (original) +++ geronimo/server/trunk/applications/geronimo-examples/geronimo- jsp-examples/pom.xml Thu Dec 7 17:53:34 2006 @@ -53,7 +53,7 @@ /dependency dependency -groupIdjavax.servlet/groupId +groupIdjstl/groupId artifactIdjstl/artifactId /dependency Modified: geronimo/server/trunk/configs/webconsole-jetty6/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ webconsole-jetty6/pom.xml?view=diffrev=483773r1=483772r2=483773 = = --- geronimo/server/trunk/configs/webconsole-jetty6/pom.xml (original) +++ geronimo/server/trunk/configs/webconsole-jetty6/pom.xml Thu Dec 7 17:53:34 2006 @@ -181,7 +181,7 @@ /dependency dependency -
WARNING ... delete rename of Jetty items in trunk
In a short while (probably in about 3 hours or so), I plan to delete the and rename several Jetty items in Geronimo. This is because we are no longer supporting the j2ee assembly in trunk which IIUC is now devoted to JavaEE5. There are also a few loose ends for the Jetty JavaEE5 assembly that need to be finished off and this will make it easier. Here's what I plan to do (if there are no objections): Delete: - geronimo/server/trunk/modules/geronimo-jetty/* - geronimo/server/trunk/modules/geronimo-jetty-builder/* - geronimo/server/trunk/modules/geronimo-jetty-clustering-wadi/* - geronimo/server/trunk/configs/jetty/* - geronimo/server/trunk/configs/jetty-clustering-builder-wadi/* - geronimo/server/trunk/configs/jetty-clustering-wadi/* - geronimo/server/trunk/configs/jetty-deployer/* - geronimo/server/trunk/configs/dojo-jetty/* - geronimo/server/trunk/configs/uddi-jetty/* - geronimo/server/trunk/configs/webconsole-jetty/* - geronimo/server/trunk/configs/jetty/* - geronimo/server/trunk/assemblies/geronimo-jetty-j2ee/* Rework/rename/etc... as necessary for Jetty6 - geronimo/server/trunk/configs/welcome-jetty/* - geronimo/server/trunk/configs/remote-deploy-jetty/* - geronimo/server/trunk/configs/ca-helper-jetty/ - geronimo/server/trunk/assemblies/geronimo-jetty-minimal/* There will still be some more potential cleanup: - Removing the geronimo-boilderplate-j2ee and including content in geronimo-boilerplate-jee5? We could keep the j2ee one around but I'm not sure there is much value. thoughts? Thanks, Joe
Re: svn commit: r485321 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/gbean/ geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/ geronimo-kernel/s
On Dec 11, 2006, at 7:18 AM, anita kulshreshtha wrote:
When we add inteface using addInterface(..), we can end up with two
methods like this.
You can't have a class that implements both interfaces if they have
methods whose signature differs only in the return type. If there
are problems with trying to expose management interfaces that are not
actually implemented by the underlying bean maybe we should look for
other ways of dealing with the management aspects. Are there actual
problems with existing gbeans extracting the return type for
operations? If so, please indicate which gbean and which
operation I don't want to get lost in too much abstraction as I
so often do :-)
I very much share Gianni's concerns and was about to write a similar
note.
thanks
david jencks
This is not a very good example because the
objectName will end up as an attribute in GBeanInfoBuilder, not an
operation.
thanks
Anita
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
It is not allowed to have public Object getObjectName() and public
String
getObjectName() simultaneously.
--vamsi
On 12/11/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
Gianny,
Thanks for looking into this. I did consider the easy way out.
But
the retrun type is part of the method signature. What happens if we
have
public class Myclass {
public Object getObjectName()
public String getObjectName()
..
}
If JMXUtil was patched which one should it return?
Thanks
Anita
--- Gianny Damour [EMAIL PROTECTED] wrote:
Hi,
I am quickly scanning this commit and I would like to know if it
was
not a little bit less intrusive to keep the existing addOperation
and
search for the return type of the added operations against the
target
gbeanType. This way, developers do not need to specify the return
type of the operations (also, the migration of the existing
GBeanInfo
could have been avoided).
After reading GERONIMO-2607, it seems that the goal of the change
was
to have a return type defined within JConsole for the GBean
operations. It seems that patching JMXUtil.toMBeanInfo would have
been another implementation approach: while getting the exposed
operations, the GBean class could be searched for returned types.
One
of the advantages would have been to keep backward compatibility.
Thanks,
Gianny
On 11/12/2006, at 11:14 AM, [EMAIL PROTECTED] wrote:
Author: akulshreshtha
Date: Sun Dec 10 16:14:46 2006
New Revision: 485321
URL: http://svn.apache.org/viewvc?view=revrev=485321
Log:
GERONIMO-2607 Added returnType to GOperationInfo, This modifies
GBeanInfoBuilder and breaks backward compatibility
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GBeanInfoBuilder.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/GOperationInfo.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/runtime/GBeanOperation.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/gbean/GBeanInfoTest.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/MockGBean.java
geronimo/server/trunk/modules/geronimo-kernel/src/test/java/org/
apache/geronimo/kernel/config/MyGBean.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/jmx/JMXUtil.java
geronimo/server/trunk/modules/geronimo-system/src/main/java/org/
apache/geronimo/system/logging/log4j/Log4jService.java
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/
java/org/apache/geronimo/gbean/DynamicGOperationInfo.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-kernel/src/main/java/org/apache/geronimo/gbean/
DynamicGOperationInfo.java?view=diffrev=485321r1=485320r2=485321
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java (original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/
apache/geronimo/gbean/DynamicGOperationInfo.java Sun Dec 10
16:14:46 2006
@@ -24,14 +24,14 @@
*/
public class DynamicGOperationInfo extends GOperationInfo {
public DynamicGOperationInfo(String name) {
-super(name);
+super(name, java.lang.Object);
}
public DynamicGOperationInfo(String name, String[]
paramTypes)
{
-super(name, paramTypes);
+super(name, paramTypes, java.lang.Object);
}
public DynamicGOperationInfo(String name, List parameters)
{
-super(name, parameters);
+super(name, parameters, java.lang.Object);
}
}
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/
Re: WARNING ... delete rename of Jetty items in trunk
Fine with me, thanks for cleaning this up! thanks david jencks On Dec 11, 2006, at 9:42 AM, Joe Bohn wrote: In a short while (probably in about 3 hours or so), I plan to delete the and rename several Jetty items in Geronimo. This is because we are no longer supporting the j2ee assembly in trunk which IIUC is now devoted to JavaEE5. There are also a few loose ends for the Jetty JavaEE5 assembly that need to be finished off and this will make it easier. Here's what I plan to do (if there are no objections): Delete: - geronimo/server/trunk/modules/geronimo-jetty/* - geronimo/server/trunk/modules/geronimo-jetty-builder/* - geronimo/server/trunk/modules/geronimo-jetty-clustering-wadi/* - geronimo/server/trunk/configs/jetty/* - geronimo/server/trunk/configs/jetty-clustering-builder-wadi/* - geronimo/server/trunk/configs/jetty-clustering-wadi/* - geronimo/server/trunk/configs/jetty-deployer/* - geronimo/server/trunk/configs/dojo-jetty/* - geronimo/server/trunk/configs/uddi-jetty/* - geronimo/server/trunk/configs/webconsole-jetty/* - geronimo/server/trunk/configs/jetty/* - geronimo/server/trunk/assemblies/geronimo-jetty-j2ee/* Rework/rename/etc... as necessary for Jetty6 - geronimo/server/trunk/configs/welcome-jetty/* - geronimo/server/trunk/configs/remote-deploy-jetty/* - geronimo/server/trunk/configs/ca-helper-jetty/ - geronimo/server/trunk/assemblies/geronimo-jetty-minimal/* There will still be some more potential cleanup: - Removing the geronimo-boilderplate-j2ee and including content in geronimo-boilerplate-jee5? We could keep the j2ee one around but I'm not sure there is much value. thoughts? Thanks, Joe
Re: WARNING ... delete rename of Jetty items in trunk
Do we need to include the jetty version number in the configs that support the applications/* artifacts? My take away from the tomcat v6 conversation was that the version number was for the artifacts that incorporate the third party component plus their configs and assemblies. But I realize that point of view is affected by a bias against including the version number at all :-) Best wishes, Paul On 12/11/06, Joe Bohn [EMAIL PROTECTED] wrote: In a short while (probably in about 3 hours or so), I plan to delete the and rename several Jetty items in Geronimo. This is because we are no longer supporting the j2ee assembly in trunk which IIUC is now devoted to JavaEE5. There are also a few loose ends for the Jetty JavaEE5 assembly that need to be finished off and this will make it easier. Here's what I plan to do (if there are no objections): Delete: - geronimo/server/trunk/modules/geronimo-jetty/* - geronimo/server/trunk/modules/geronimo-jetty-builder/* - geronimo/server/trunk/modules/geronimo-jetty-clustering-wadi/* - geronimo/server/trunk/configs/jetty/* - geronimo/server/trunk/configs/jetty-clustering-builder-wadi/* - geronimo/server/trunk/configs/jetty-clustering-wadi/* - geronimo/server/trunk/configs/jetty-deployer/* - geronimo/server/trunk/configs/dojo-jetty/* - geronimo/server/trunk/configs/uddi-jetty/* - geronimo/server/trunk/configs/webconsole-jetty/* - geronimo/server/trunk/configs/jetty/* - geronimo/server/trunk/assemblies/geronimo-jetty-j2ee/* Rework/rename/etc... as necessary for Jetty6 - geronimo/server/trunk/configs/welcome-jetty/* - geronimo/server/trunk/configs/remote-deploy-jetty/* - geronimo/server/trunk/configs/ca-helper-jetty/ - geronimo/server/trunk/assemblies/geronimo-jetty-minimal/* There will still be some more potential cleanup: - Removing the geronimo-boilderplate-j2ee and including content in geronimo-boilerplate-jee5? We could keep the j2ee one around but I'm not sure there is much value. thoughts? Thanks, Joe
Re: svn commit: r485321 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/gbean/ geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/ geronimo-kernel/s
On Dec 11, 2006, at 5:38 AM, anita kulshreshtha wrote:
Gianny,
Thanks for looking into this. I did consider the easy way out. But
the retrun type is part of the method signature. What happens if we
have
public class Myclass {
public Object getObjectName()
public String getObjectName()
..
}
If JMXUtil was patched which one should it return?
The return type actually isn't part of the signature and the code
above won't compile.
A Java method is uniquely identified by class, method name and
parameters. Once you have those three, you can always determine the
return type.
-dain
Re: svn commit: r483773 - in /geronimo/server/trunk: ./ applications/console/geronimo-console-standard/ applications/geronimo-examples/geronimo-jsp-examples/ configs/webconsole-jetty6/ configs/webcons
On Dec 11, 2006, at 9:18 AM, Joe Bohn wrote:
David,
I wanted to get something committed that works for now. With trunk
rev. 485719 I included jstl as a dependency in modules/geronimo-
web-2.5-builder as well as in configs/jetty6 and configs/tomcat6 so
that it would always be in the classpath for an application. I can
change this if there is a better way.
oops getting behind on my email
in the jetty6-deployer plan in the JettyWebBuilder gbean config
there's a defaultEnvironment xml attribute. If you add the jstl
dependency to
dependencies
dependency
groupId${pom.groupId}/groupId
artifactIdjetty6/artifactId
typecar/type
/dependency
/dependencies
I think it will be added to every web app deployed to jetty6.
However this will result in each web app getting its own copy of
jstl. If it would be better to share a copy of jstl among all web
apps we could either
- include it in the jetty6 config classpath (IIUC this is what you
are currently doing). However jetty doesn't need it so this may not
be ideal in some theoretical sense.
- make a jstl config including only (??) the jstl jar and include a
dependency on that config
- if jstl can only be used from jsps (??? displaying my total
ignorance here :-)) maybe we could make a jasper config and include
jstl there and put the jasper stuff in the defaultEnvironment.
Hope this clarifies what I was explaining poorly :-)
thanks
david jencks
Thanks,
Joe
Joe Bohn wrote:
David,
I need a little direction.
I know that there is someplace/way to add a dependency for the
default environment. Such a dependency is then added dynamically
to the module that is being deployed. At least I think that is
what I recall hearing you mention before. But I'm having trouble
finding the right place to add these dependencies.
I tried adding the dependencies to the pom for modules/geronimo-
web-2.5-builder but they didn't carry over to the deployed
module. I also tried adding them to modules/geronimo-jetty6-
builder and modules/geronimo-tomcat-builder with the same poor
results. Adding them to the builders allowed me to deploy the
applications successfully but the jars were never added to the
deployed module's classpath and so the applications can't run.
I'm sure I could force it to work if I added the dependencies
directly in configs/tomcat and configs/jetty6 but that doesn't
seem right since neither tomcat or jetty require the JSTL jars ...
it's really the deployed applications running in these containers
that might need them.
Thanks in advance for your help,
Joe
Joe Bohn wrote:
Yes, Paul is correct. It's not a spec jar so I'll include it in
the default environment for the builder as David recommends.
Thanks,
Joe
David Jencks wrote:
On Dec 8, 2006, at 12:48 AM, Paul McMahan wrote:
Should the JSTL classes be made available in the web container
instead
of being included in the web apps? Looking at the spec that
seems to
be the case.
If this is a spec jar then according to current convention it
should be included in the dependencies of the spec car. If not
it should be included in the default environment for each web
builder.
thanks
david jencks
Best wishes,
Paul
On 12/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jbohn
Date: Thu Dec 7 17:53:34 2006
New Revision: 483773
URL: http://svn.apache.org/viewvc?view=revrev=483773
Log:
GERONIMO-2536 Update jetty6 and tomcat jee5 assemblies to
include jstl 1.2 from glassfish
Also update jspc-maven-plugin to 1.4.7-SNAPSHOT to pick up
jgenender's inclusion of jasper 6 (Thanks Jeff)
Modified:
geronimo/server/trunk/applications/console/geronimo-
console- standard/pom.xml
geronimo/server/trunk/applications/geronimo-examples/
geronimo- jsp-examples/pom.xml
geronimo/server/trunk/configs/webconsole-jetty6/pom.xml
geronimo/server/trunk/configs/webconsole-jetty6/src/plan/
plan.xml
geronimo/server/trunk/configs/webconsole-tomcat/pom.xml
geronimo/server/trunk/configs/webconsole-tomcat/src/plan/
plan.xml
geronimo/server/trunk/pom.xml
Modified: geronimo/server/trunk/applications/console/geronimo-
console-standard/pom.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
applications/console/geronimo-console-standard/pom.xml?
view=diffrev=483773r1=483772r2=483773
=
=
--- geronimo/server/trunk/applications/console/geronimo-
console- standard/pom.xml (original)
+++ geronimo/server/trunk/applications/console/geronimo-
console- standard/pom.xml Thu Dec 7 17:53:34 2006
@@ -131,7 +131,7 @@
/dependency
dependency
-groupIdjavax.servlet/groupId
+groupIdjstl/groupId
artifactIdjstl/artifactId
Re: Stack trace while shutting down amq in geronimo 2.0
On Dec 11, 2006, at 8:33 AM, anita kulshreshtha wrote: Prasad, I am hoping that the fix Dain promised for the branch might help with this too.. I am waiting for it :) On Dec 7, 2006, at 10:32 AM, Dain Sundstrom wrote: We have an exception being thrown in shutdown from GBeanBinding.removeBinding():159 and I'll fix that today. http://www.nabble.com/1.2-Beta-Tasks-p7744896.html It's back :( When I went to fix it last week, it was gone so I didn't look any further. How did you create the error or does it always happen now? -dain
[DISCUSS] specs versioning
The versioning policy for our geronimo specs has been floating around for a while now. I'd like to see this issue resolved. There have been two approaches discussed 1) Single version -- all specs are released under the same version number. 2) Separate version -- each spec is versioned separately from the other specs. Dain created a review of the two proposals in the wiki -- http:// cwiki.apache.org/confluence/display/GMOxDEV/Spec+Versioning I think you can quibble over a few of the details, but it does a good job at summarizing the issue. IMO, there are going to be drawbacks no matter which approach we take. However, I'm going to be happy with either approach as long as we reach a *decision*. I'd prefer that we reach consensus on this discussion thread. However, if necessary, we can vote on the issue. Personally, I think we should use a single version for releasing our specs. I think this makes it easier for us as developers in managing spec releases. I think users will find it easier to collect a consistent set of specifications. I think these benefits outweigh concerns over the lack of flexibility and the wasteful aspects of re- releasing unchanged specifications. I suppose there's a hybrid option where we release separate versions, now, and move to a single version policy (2.0?) for our next release. --kevan
Re: MyFaces 1.2 SNAPSHOT update
Good suggestion Paul, I like that idea. Tim Paul McMahan wrote: IIUC the myfaces jar isn't part of an official (i.e. voted upon) release or even considered a snapshot and we don't know if/when/how/where it will be published. Can we localize it in the module that needs it? See the dojo.zip in applications/geronimo-dojo/repository for an example. Best wishes, Paul On 12/11/06, Sachin Patel [EMAIL PROTECTED] wrote: Didn't Paul just publish a snapshot? Wherever that was, can we just publish it there? On Dec 11, 2006, at 10:14 AM, Tim McConnell wrote: Ok looks like the MyFaces team is not going to product any 1.2 snapshots quite yet, but they have provided permission for me to include the 1.2 myfaces snapshots I've build into M1. I just need some instructions on how and where to this. Please advise. Thanks Tim Tim McConnell wrote: Looks like the MyFaces build 1.2 is using Continuum to automate their builds. It's supposed to automatically publish their snapshots but they have discovered after my query that it's doing a 'mvn install' instead of an 'mvn deploy'. So that's been fixed. Unfortunately though the MyFaces 1.2 build on Continuum isn't working although I can build it fine. More information to follow Thanks. Tim -sachin
Re: test-ejbcontainer working?
I'm seeing a different problem. The openejb-itests-core cannot be distributed since it has a dependency on j2ee-corba-yoko/1.2-SNAPSHOT. Here's how the chain is broken. - Geronimo 2.0-SNAPSHOT pulls in OpenEJB 2.2. - OpenEJB 2.2 has a dependency on Geronimo 1.2-SNAPSHOT. Cheers Prasad On 12/11/06, Gianny Damour [EMAIL PROTECTED] wrote: Hi, I am trying to debug a couple of test-ejbcontainer itests and the test-ejbcontainer itests seem to be broken (I was able to run them on Friday last week) as the org.apache.geronimo.configs/j2ee-corba-yoko/ 2.0-SNAPSHOT/car configuration cannot be started due to the following reason: java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_cha nged(Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange (PIManager.java:531) It seems that I am running against a wrong version of the CORBA spec. After some investigations, I have discovered that the method being looked up is only defined by yoko-spec-corba-1.0-incubating-M2- SNAPSHOT.jar and not by the corba specs of the JVM I am using: yoko: void adapter_manager_state_changed (String id, short state); my JVM: void adapter_manager_state_changed (int id, short state); Any idea? Thanks, Gianny
Re: Stack trace while shutting down amq in geronimo 2.0
I've been seeing it on all recent 2.0-SNAPSHOT assemblies. Just hit cntlr+c in a running geronimo window or use the shutdown. The geronimo.log would have the stacktrace or the window running the server would, depending on how you started it. Cheers Prasad On 12/11/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Dec 11, 2006, at 8:33 AM, anita kulshreshtha wrote: Prasad, I am hoping that the fix Dain promised for the branch might help with this too.. I am waiting for it :) On Dec 7, 2006, at 10:32 AM, Dain Sundstrom wrote: We have an exception being thrown in shutdown from GBeanBinding.removeBinding():159 and I'll fix that today. http://www.nabble.com/1.2-Beta-Tasks-p7744896.html It's back :( When I went to fix it last week, it was gone so I didn't look any further. How did you create the error or does it always happen now? -dain
G2.0 and OpenEJB 2.2 relation broken.
Geronimo 2.0-SNAPSHOT pulls in OpenEJB-2.2 OpenEJB-2.2 has a dependency on Geronimo-1.2-SNAPSHOT Cheers Prasad
Re: [DISCUSS] specs versioning
I'm in favor of a single version for all specs. Versioning the specs individually has some advantages but makes the release manager's job more difficult since the tooling doesn't readily support that approach. And as a developer (at least for me) a single version is more intuitive, evidenced by my recent snafu where I created the initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason keeps a very close eye on things and suggested using 1.0-SNAPSHOT instead. I also believe having the specs all at a single release is consistent with the approach we use in server/trunk, where the artifacts share the same geronimo version and when necessary a version number can be included in the artifactId. Consistency has its benefits. Best wishes, Paul On 12/11/06, Kevan Miller [EMAIL PROTECTED] wrote: The versioning policy for our geronimo specs has been floating around for a while now. I'd like to see this issue resolved. There have been two approaches discussed 1) Single version -- all specs are released under the same version number. 2) Separate version -- each spec is versioned separately from the other specs. Dain created a review of the two proposals in the wiki -- http:// cwiki.apache.org/confluence/display/GMOxDEV/Spec+Versioning I think you can quibble over a few of the details, but it does a good job at summarizing the issue. IMO, there are going to be drawbacks no matter which approach we take. However, I'm going to be happy with either approach as long as we reach a *decision*. I'd prefer that we reach consensus on this discussion thread. However, if necessary, we can vote on the issue. Personally, I think we should use a single version for releasing our specs. I think this makes it easier for us as developers in managing spec releases. I think users will find it easier to collect a consistent set of specifications. I think these benefits outweigh concerns over the lack of flexibility and the wasteful aspects of re- releasing unchanged specifications. I suppose there's a hybrid option where we release separate versions, now, and move to a single version policy (2.0?) for our next release. --kevan
Re: Convention on dropping tests under the test framework
On 12/10/06, David Jencks [EMAIL PROTECTED] wrote: On Dec 8, 2006, at 1:29 PM, Prasad Kashyap wrote: David, Check out this patch http://people.apache.org/~prasad/manifestcp.patch Apply it from the geronimo/testsuite/depoyment-testsuite directory. It will create 2 directories under it. -- The manifestcp will create the ear for. -- The test-manifestcp will deploy and undeploy it. Throw your testcases under test-manifestcp. When I apply the patch I get files with many copies of the content. Assuming this builds for you can you commit it? IIRC there there aren't any tests needed for this, if it deploys it works. When it's committed I'll check. Sure. let me work on commiting it for you. I think I'd prefer everything including the tests to be under the manifestcp dir, but we can try to rearrange this later. I think we need to study how to best set this up. Usually, that shouldn't have been a problem but for the fact that it might be left out of the entire reporting structure of the test framework. Let me see how I can pull in the surefire-reports from the deploy/undeploy of the manifestcp.ear if it gets embedded inside this pom thanks david jencks Cheers Prasad Cheers Prasad On 12/8/06, David Jencks [EMAIL PROTECTED] wrote: On Dec 8, 2006, at 6:30 AM, Prasad Kashyap wrote: On 12/8/06, David Jencks [EMAIL PROTECTED] wrote: For instance it might be useful to have a maven archetype to set up everything except the app to test and the actual test cases. thanks david jencks I have alrady written an archetype plugin called testsuite-archetype-plugin that will let you create a testsuite with an empty testset project under it. Please see http://cwiki.apache.org/GMOxDEV/integration- testing.html#IntegrationTesting-Gettingstarted However, in your case, since you don't want us to be createing any moe testsuites till we have colected enough tests, this is what you should do : 1) just make a copy of test-deployment, (say call it cxf- deployment) 2) use it's child profile to go thro the complete maven lifecycle - compile, build and test your apps. 3) it's parent (deployment-testsuite) will take care of the server start/stop and reporting for you. I wasn't able to make anything work where the app being tested was under the directory that's a copy of *-deployment. Now I'm working with a structure where the *-deployment is a child of the app build directory, and it seems to work. Once I straighten out the tests so they work I'll check it in and we can see if it can be reorganized to be simpler. I was wondering why the SeleniumTestSupport and ExtendedSelenium classes were in the tests themselves rather than in a support jar. I'd think these would be used by just about all tests. FIxing the tests is likely to take me all day. If you'd like to demonstrate what you think is correct structure you could set something up with the test ear from GERONIMO-2125 http://issues.apache.org/jira/secure/attachment/12336683/manifestcp- itest-v3.jar which has a maven project to build a test ear. With luck deploying it stlll works :-) thanks david jencks Cheers Prasad Cheers Prasad On Dec 7, 2006, at 8:31 PM, Prasad Kashyap wrote: Since there were some questions today on where to drop new tests, I'll take a stab at creating a convention. Feel free to offer your suggestions so that we can modify it as we go along. We began by having 2 testsuites just as an example. geronimo/testsuite/ console-testsuite deployment-testsuite But almost everything can fall under the category of the deployment-testsuite since most tests do need some deployable artifact. So I think we should use the deployment-testsuite purely for testing the deploy tool. Especially, it should be used to test features like hot-deploy, redeploy and undeploy which have had JIRAs before. We should categorize the tests so that they reflect the broad functional areas of the server. * web-testsuite (servlets, jsp, jstl) * enterprise-testsuite (ejb, jpa, jms, jacc, jta, javamail, jaf etc) * mgmt-testsuite (jee management, deployment) * webservices-testsuite (wsee, jaxb, stax, saaj, ws-metadata etc) * performance-testsuite (server startup time, server footprint etc) * security-testsuite * console-testsuite * regression (compatibility) If nobody has any objection to this top categorization, I shall go ahead and create these testsuites over the weekend. Meanwhile you may drop your tests in the existing testsuites for now. I shall move them appropriately. Lastly, how do we deal with super apps like daytrader that can span across multiple testsuites ? Cheers Prasad
Re: Convention on dropping tests under the test framework
Starting and stopping the server for each app ? Wouldn't that be a tad too much. Currently the start/stop is designed to happen for a suite (eg. web). So a bunch of related tests (servlet tests, jsp tests, jsf tests etc) can be performed in a suite with required apps getting deployed and undeployed for the tests. Cheers Prasad On 12/11/06, David Jencks [EMAIL PROTECTED] wrote: I thought about this a little more and have some ideas about what I'd like. I dunno if this is remotely possible. - keep the test app and test code close together in svn. It's going to be a lot easier to work with a single test if these are close together, rather than like the testsupport stuff that is far from the tests that use it. - make it easy to run the tests on a single app... so there's an easy way to build the test app, start up a server, and run the tests for that app. - make it relatively quick to run all the tests which I think means starting a server, then for each app, deploying, running tests, and undeploying. My current understanding of what we have now is that the server is going to be started and stopped for each app if we've set things up for my second requirement :-) thanks david jencks On Dec 8, 2006, at 1:21 PM, Prasad Kashyap wrote: I know what you mean. I just worked on the app that David was talking about those do need a separate module by themselves. I didn't realise his scenario until I saw the JIRA. I was talking about something like testsuite/web-testsuite/test-servlet25. This example builds a war and tests it in the same pom. Cheers Prasad On 12/8/06, Jason Dillon [EMAIL PROTECTED] wrote: On Dec 8, 2006, at 6:30 AM, Prasad Kashyap wrote: 1) just make a copy of test-deployment, (say call it cxf- deployment) 2) use it's child profile to go thro the complete maven lifecycle - compile, build and test your apps. 3) it's parent (deployment-testsuite) will take care of the server start/stop and reporting for you. This won't actually work as easily as you may have imagined Prasad. To effectively build some apps, you actually need to have them live in their own module, so that they can be built using the associated maven plugins. I do not believe that the current testsuite setup takes this into account... and this is why I think it is premature to simply roll out the same config/layout with out having some more real tests, which build these test applications and allow for effective organization. I don't think we are quite there yet... close, but still a bit off. --jason
Re: test-ejbcontainer working?
On Dec 11, 2006, at 10:44 AM, Prasad Kashyap wrote: I'm seeing a different problem. The openejb-itests-core cannot be distributed since it has a dependency on j2ee-corba-yoko/1.2-SNAPSHOT. What is the error you get? Here's how the chain is broken. - Geronimo 2.0-SNAPSHOT pulls in OpenEJB 2.2. - OpenEJB 2.2 has a dependency on Geronimo 1.2-SNAPSHOT. All org.apache.geronimo.* deps in OpenEJB were marked as non- transitive. It's been very heavily tested that you can build G 2.0- SNAPSHOT without pulling in any G 1.2-SNAPSHOTS at all. -David Cheers Prasad On 12/11/06, Gianny Damour [EMAIL PROTECTED] wrote: Hi, I am trying to debug a couple of test-ejbcontainer itests and the test-ejbcontainer itests seem to be broken (I was able to run them on Friday last week) as the org.apache.geronimo.configs/j2ee-corba-yoko/ 2.0-SNAPSHOT/car configuration cannot be started due to the following reason: java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_ cha nged(Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange (PIManager.java:531) It seems that I am running against a wrong version of the CORBA spec. After some investigations, I have discovered that the method being looked up is only defined by yoko-spec-corba-1.0-incubating-M2- SNAPSHOT.jar and not by the corba specs of the JVM I am using: yoko: void adapter_manager_state_changed (String id, short state); my JVM: void adapter_manager_state_changed (int id, short state); Any idea? Thanks, Gianny
Re: G2.0 and OpenEJB 2.2 relation broken.
On Dec 11, 2006, at 10:51 AM, Prasad Kashyap wrote: Geronimo 2.0-SNAPSHOT pulls in OpenEJB-2.2 OpenEJB-2.2 has a dependency on Geronimo-1.2-SNAPSHOT All org.apache.geronimo.* deps in OpenEJB were marked as non- transitive. It's been very heavily tested that you can build G 2.0- SNAPSHOT without pulling in any G 1.2-SNAPSHOTS at all. -David
Re: G2.0 and OpenEJB 2.2 relation broken.
Prasad Kashyap wrote: Geronimo 2.0-SNAPSHOT pulls in OpenEJB-2.2 OpenEJB-2.2 has a dependency on Geronimo-1.2-SNAPSHOT When the openejb-2.2 branch was created, the Geronimo branch was updated to have a dependency on OpenEJB-2.3. How did this get back to a 2.2 dependency? Rick Cheers Prasad
Re: G2.0 and OpenEJB 2.2 relation broken.
Yes. I have been able to build Geronimo-2.0-SNAPSHOT on a clean repo without pulling in anything from 1.2 (except tranql-connector-derby-common). However, when I build Openejb-2.2, it pulls in all Geronimo-1.2 artifacts. Next, the openjeb-itests-core.jar now fails to install on Geronimo-2.0-SNAPSHOT b'coz it has a dependency on 1.2 too. Cheers Prasad On 12/11/06, David Blevins [EMAIL PROTECTED] wrote: On Dec 11, 2006, at 10:51 AM, Prasad Kashyap wrote: Geronimo 2.0-SNAPSHOT pulls in OpenEJB-2.2 OpenEJB-2.2 has a dependency on Geronimo-1.2-SNAPSHOT All org.apache.geronimo.* deps in OpenEJB were marked as non- transitive. It's been very heavily tested that you can build G 2.0- SNAPSHOT without pulling in any G 1.2-SNAPSHOTS at all. -David
Re: test-ejbcontainer working?
On 12/11/06, David Blevins [EMAIL PROTECTED] wrote: On Dec 11, 2006, at 10:44 AM, Prasad Kashyap wrote: I'm seeing a different problem. The openejb-itests-core cannot be distributed since it has a dependency on j2ee-corba-yoko/1.2-SNAPSHOT. What is the error you get? [INFO] [INFO] Distributing module artifact: C:\Documents and Settings\Administrator\.m2\repository\org\apache\openejb\openejb-itests-core\2.2-incubating-SNAPSHOT\openejb-itests-core-2.2-incubating-SNAPSHOT.jar with plan null [WARNING] Deployer operation failed: Unable to create configuration for deployment [WARNING] org.apache.geronimo.common.DeploymentException: Unable to create configuration for deployment ... ... ... [WARNING] Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency org.apache.geronimo.configs/j2ee-corba-yoko/1.2-SNAPSHOT/car Cheers Prasad
[jira] Created: (GERONIMO-2644) Fix leaking ClassLoaders
Fix leaking ClassLoaders Key: GERONIMO-2644 URL: http://issues.apache.org/jira/browse/GERONIMO-2644 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 1.2, 2.0-M1 Reporter: Kevan Miller Fix For: 1.2, 2.0-M1 Looks like we're leaking ClassLoaders. If you deploy/undeploy an app the ClassLoader(s) created for the app are not being GC'ed. Eventually, you'll run out of PermGen space. I assume that this is also causing the PermGen problems when running tests. -- 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: G2.0 and OpenEJB 2.2 relation broken.
On Dec 11, 2006, at 11:36 AM, Prasad Kashyap wrote: Yes. I have been able to build Geronimo-2.0-SNAPSHOT on a clean repo without pulling in anything from 1.2 Great. (except tranql-connector-derby-common). As far as I can see, both G 1.2 and 2.0 are using the exact same versions of all the tranql jars. However, when I build Openejb-2.2, it pulls in all Geronimo-1.2 artifacts. Sure, the openejb build is a different build. Next, the openjeb-itests-core.jar now fails to install on Geronimo-2.0-SNAPSHOT b'coz it has a dependency on 1.2 too. Let's pick this up in the test thread. Maven-wise, there is no dep from the openejb-itests-core.jar to any 1.2 geronimo jars. -David Cheers Prasad On 12/11/06, David Blevins [EMAIL PROTECTED] wrote: On Dec 11, 2006, at 10:51 AM, Prasad Kashyap wrote: Geronimo 2.0-SNAPSHOT pulls in OpenEJB-2.2 OpenEJB-2.2 has a dependency on Geronimo-1.2-SNAPSHOT All org.apache.geronimo.* deps in OpenEJB were marked as non- transitive. It's been very heavily tested that you can build G 2.0- SNAPSHOT without pulling in any G 1.2-SNAPSHOTS at all. -David
Re: [DISCUSS] specs versioning
On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote: I'm in favor of a single version for all specs. Versioning the specs individually has some advantages but makes the release manager's job more difficult since the tooling doesn't readily support that approach. Um.. that's not true. Maven has full support for this. Also it doesn't make the release manager's job harder. And as a developer (at least for me) a single version is more intuitive, evidenced by my recent snafu where I created the initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason keeps a very close eye on things and suggested using 1.0-SNAPSHOT instead. Um I think that goes both ways. Because all specs are currently at 1.1-SNAPSHOT, you mistakenly created a new spec at 1.1-SNAPSHOT. As specs become more independent, I would expect you would naturally choose 1.0-SNAPSHOT for a new spec. In addition, new specs do not come along that often so making a mistake once a year is not a big deal. I also believe having the specs all at a single release is consistent with the approach we use in server/trunk, where the artifacts share the same geronimo version and when necessary a version number can be included in the artifactId. Consistency has its benefits. In that case, why not move specs into the server tree? -dain
[jira] Assigned: (GERONIMO-2644) Fix leaking ClassLoaders
[ http://issues.apache.org/jira/browse/GERONIMO-2644?page=all ] Kevan Miller reassigned GERONIMO-2644: -- Assignee: Kevan Miller Fix leaking ClassLoaders Key: GERONIMO-2644 URL: http://issues.apache.org/jira/browse/GERONIMO-2644 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.2, 2.0-M1 Reporter: Kevan Miller Assigned To: Kevan Miller Fix For: 1.2, 2.0-M1 Looks like we're leaking ClassLoaders. If you deploy/undeploy an app the ClassLoader(s) created for the app are not being GC'ed. Eventually, you'll run out of PermGen space. I assume that this is also causing the PermGen problems when running tests. -- 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: (SM-762) Address in WSDL is incorrectly adding the protocol information in the begining of the URL
[ https://issues.apache.org/activemq/browse/SM-762?page=all ] Jeff Puro resolved SM-762. -- Resolution: Fixed Please see notes on attached patches. Address in WSDL is incorrectly adding the protocol information in the begining of the URL - Key: SM-762 URL: https://issues.apache.org/activemq/browse/SM-762 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1 Attachments: servicemix-http-host-port-is-secure.patch, servicemix-http-host-port-scheme.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Here is an example of the error when generating the WSDL: service name=HttpService port binding=tns:nullBinding wsdlsoap:address location=HTTP/1.1://10.0.102.12:8080/servicemix-web/jbi/tracker// /port /service -- 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] Updated: (GERONIMO-2630) sun j2ee schemas are being redistributed in jsp and servlet specs
[ http://issues.apache.org/jira/browse/GERONIMO-2630?page=all ] Jarek Gawor updated GERONIMO-2630: -- Attachment: Clean.java Attached is a simple Java program that removes any xsd:annotation elements and XML comments from a specified xsd file. It can be useful for comparing hand-typed xsd files with original files without any comments or annotations. Compile: javac Clean.java Run: java -cp . Clean jsp_2_0.xsd.sun jsp_2_0.xsd.sun.clean Compare: diff -w jsp_2_0.xsd.typed jsp_2_0.xsd.sun.clean sun j2ee schemas are being redistributed in jsp and servlet specs - Key: GERONIMO-2630 URL: http://issues.apache.org/jira/browse/GERONIMO-2630 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 1.2, 2.0 Reporter: Kevan Miller Assigned To: Kevan Miller Priority: Blocker Fix For: 1.2, 2.0 Attachments: Clean.java A variety of Sun J2EE xsd's and dtd's are being redistributed in our corba 3.0, jsp and servlet specs. We had the same problem in our j2ee-schema module a while back. Without written outhorization from Sun, we cannot redistribute these xsd's and dtd's. Here's a list of problem files, that I see: trunk/geronimo-corba_3.0_spec/src/main/idl/CosTransactions.idl:11://Copyright 1995-1996, Sun Microsystems, Inc. trunk/geronimo-jsp_2.0_spec/src/main/schema/jsp_2_0.xsd:18: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-jsp_2.0_spec/src/main/schema/web-jsptaglibrary_2_0.xsd:19: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-jsp_2.1_spec/src/main/schema/jsp_2_0.xsd:34: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-jsp_2.1_spec/src/main/schema/jsp_2_1.xsd:35: Copyright 2003-2005 Sun Microsystems, Inc. trunk/geronimo-jsp_2.1_spec/src/main/schema/web-jsptaglibrary_2_0.xsd:35: Copyright 2003 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-jsp_2.1_spec/src/main/schema/web-jsptaglibrary_2_1.xsd:36: Copyright 2003-2005 Sun Microsystems, Inc. trunk/geronimo-servlet_2.4_spec/src/main/schema/j2ee_1_4.xsd:18: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-servlet_2.4_spec/src/main/schema/j2ee_web_services_1_1.xsd:18: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-servlet_2.4_spec/src/main/schema/j2ee_web_services_client_1_1.xsd:18: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-servlet_2.4_spec/src/main/schema/web-app_2_3.dtd:2:Copyright 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road, trunk/geronimo-servlet_2.4_spec/src/main/schema/web-app_2_3.dtd:38:Copyright 2000-2001 Sun Microsystems, Inc., trunk/geronimo-servlet_2.4_spec/src/main/schema/web-app_2_4.xsd:18: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-servlet_2.5_spec/src/main/java/javax/servlet/http/package.html:6: Copyright 2001 Sun Microsystems, Inc. All Rights Reserved. trunk/geronimo-servlet_2.5_spec/src/main/java/javax/servlet/package.html:6: Copyright 2001 Sun Microsystems, Inc. All Rights Reserved. trunk/geronimo-servlet_2.5_spec/src/main/schema/j2ee_1_4.xsd:34: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-servlet_2.5_spec/src/main/schema/j2ee_web_services_1_1.xsd:34: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-servlet_2.5_spec/src/main/schema/j2ee_web_services_client_1_1.xsd:34: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio trunk/geronimo-servlet_2.5_spec/src/main/schema/web-app_2_3.dtd:18:Copyright 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road, trunk/geronimo-servlet_2.5_spec/src/main/schema/web-app_2_3.dtd:54:Copyright 2000-2001 Sun Microsystems, Inc., trunk/geronimo-servlet_2.5_spec/src/main/schema/web-app_2_4.xsd:34: Copyright 2002 Sun Microsystems, Inc., 901 San Antonio -- 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] Reopened: (SM-762) Address in WSDL is incorrectly adding the protocol information in the begining of the URL
[ https://issues.apache.org/activemq/browse/SM-762?page=all ] Jeff Puro reopened SM-762: -- Address in WSDL is incorrectly adding the protocol information in the begining of the URL - Key: SM-762 URL: https://issues.apache.org/activemq/browse/SM-762 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1 Attachments: servicemix-http-host-port-is-secure.patch, servicemix-http-host-port-scheme.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Here is an example of the error when generating the WSDL: service name=HttpService port binding=tns:nullBinding wsdlsoap:address location=HTTP/1.1://10.0.102.12:8080/servicemix-web/jbi/tracker// /port /service -- 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: svn commit: r485548 - /geronimo/javamail/trunk/geronimo-javamail_1.4_provider/pom.xml
On Dec 11, 2006, at 1:26 AM, Christopher M. Cardona wrote: When we updated to JavaMail 1.4 and Activation 1.1 we got this warning message when building trunk: [WARNING] POM for 'org.apache.geronimo.javamail:geronimo- javamail_1.4_provider:pom:1.0-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM The reason for this warning was it couldn't resolve the version for the said specs so I added it. I already published a new snapshot with these changes that's why we don't get this problem anymore but I forgot to update the source. Um, if mvn could not resolve the version for these artifacts, then it would have stopped the build with an error. This warning means that it was able to resolve the artifact, but if found a pom with it which was not valid, probably an m1 generated pom instead of an m2 pom. I really don't see how adding version details to the child module's pom helped this in any way. Thanks for the pointers. Not sure if we have conventions on creating properties but if I create 'javamail14Version' and 'activation11Version' in the parent pom will that work for you? I was not referring to properties at all. Maven 2 has a dependencyManangement section which is intented to hold version details for child modules. If you really need to add these version elements, then add them to the parent's dependencyManagement section, so that the child poms can be free from version details. Please do not not add version properties. I have been removing most of them that I find and converting them to dependnecyManagement entries as they should be. Properties for versions should not be used IMO, except rarely, when using Maven 2. --jason
Re: Strange build problem
Not sure... might be getting picked up as a dependency too. You removed it? Where are you getting jstl 2.0 from now? --jason On Dec 11, 2006, at 1:49 AM, Joe Bohn wrote: I removed the legacy java.net repo from the root pom Friday PM. Are there others? Joe Jason Dillon wrote: Strange dependency muck like this often happens when a legacy repo is in the mix. --jason On Dec 10, 2006, at 8:55 PM, anita kulshreshtha wrote: When I build cxf-builder from modules directory, I get this error: Missing: -- 1) wsdl4j:wsdl4j:jar:1.6.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=wsdl4j - DartifactId=wsdl4j \ -Dversion=1.6.1 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-cxf-builder:jar:2.0-SNAPSHOT 2) org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.0-incubator-M1-SNAPSHOT 3) org.apache.cxf:cxf-tools-common:jar:2.0-incubator-M1-SNAPSHOT 4) wsdl4j:wsdl4j:jar:1.6.1 -- This jar is not in my .m2 repo, only a pom is present. When I build from geronimo-cxf-builder directory, the module builds fine. it appears to be using wsdl4j-1.5.2 jar. Is anyone else having this problem? Thanks Anita __ __ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
[jira] Created: (SM-771) ServiceMix-Http component has its ConnectionManager shutdown when installed under the servicemix-web module (managed mode)
ServiceMix-Http component has its ConnectionManager shutdown when installed under the servicemix-web module (managed mode) -- Key: SM-771 URL: https://issues.apache.org/activemq/browse/SM-771 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1, 3.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.1, 3.0.1 When using an HTTP provider endpoint while the service unit is deployed using the apache servicemix web project (that is using managed mode), it generates the following Exception. java.lang.IllegalStateException: Connection factory has been shutdown. at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:454) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnectionWithTimeout(MultiThreadedHttpConnectionManager.java:407) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:152) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346) at org.apache.servicemix.http.processors.ProviderProcessor.process(ProviderProcessor.java:153) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:410) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:43) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:624) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:170) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:177) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:227) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) -- 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] Updated: (SM-771) An IllegalStateException is generated when using an http provider endpoint when it is deployed using the Servicemix Web war (managed mode).
[ https://issues.apache.org/activemq/browse/SM-771?page=all ] Jeff Puro updated SM-771: - Summary: An IllegalStateException is generated when using an http provider endpoint when it is deployed using the Servicemix Web war (managed mode). (was: ServiceMix-Http component has its ConnectionManager shutdown when installed under the servicemix-web module (managed mode)) An IllegalStateException is generated when using an http provider endpoint when it is deployed using the Servicemix Web war (managed mode). --- Key: SM-771 URL: https://issues.apache.org/activemq/browse/SM-771 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1, 3.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1, 3.1 Original Estimate: 1 hour Remaining Estimate: 1 hour When using an HTTP provider endpoint while the service unit is deployed using the apache servicemix web project (that is using managed mode), it generates the following Exception. java.lang.IllegalStateException: Connection factory has been shutdown. at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:454) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnectionWithTimeout(MultiThreadedHttpConnectionManager.java:407) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:152) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346) at org.apache.servicemix.http.processors.ProviderProcessor.process(ProviderProcessor.java:153) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:410) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:43) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:624) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:170) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:177) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:227) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) -- 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: (SM-762) Address in WSDL is incorrectly adding the protocol information in the begining of the URL
[ https://issues.apache.org/activemq/browse/SM-762?page=all ] Guillaume Nodet resolved SM-762. Resolution: Fixed Author: gnodet Date: Mon Dec 11 12:37:35 2006 New Revision: 485860 URL: http://svn.apache.org/viewvc?view=revrev=485860 Log: SM-762: Address in WSDL is incorrectly adding the protocol information in the beginning of the URL Patch provided by Jeff Puro Modified: incubator/servicemix/branches/servicemix-3.0/servicemix-http/src/main/java/org/apache/servicemix/http/processors/ConsumerProcessor.java Address in WSDL is incorrectly adding the protocol information in the begining of the URL - Key: SM-762 URL: https://issues.apache.org/activemq/browse/SM-762 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1 Attachments: servicemix-http-host-port-is-secure.patch, servicemix-http-host-port-scheme.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Here is an example of the error when generating the WSDL: service name=HttpService port binding=tns:nullBinding wsdlsoap:address location=HTTP/1.1://10.0.102.12:8080/servicemix-web/jbi/tracker// /port /service -- 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: [DISCUSS] specs versioning
On 12/11/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote: I'm in favor of a single version for all specs. Versioning the specs individually has some advantages but makes the release manager's job more difficult since the tooling doesn't readily support that approach. Um.. that's not true. Maven has full support for this. Also it doesn't make the release manager's job harder. Maybe I read too much into the wiki page that Kevan referenced, which lists the following advantage for using a single version for specs: - Release process is simple and can be fully automated with the release plugin And the following listed as a disadvantage of versioning the specs individually: - Releases are more difficult because the person performing the release must be aware of any dependencies and must also rerelease those jars. (eliminated with working version-ranges) and lists as a supporting fact: - Version ranges don't work several (most?) important maven plugins Is the wiki page outdated or am I missing the point? And as a developer (at least for me) a single version is more intuitive, evidenced by my recent snafu where I created the initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason keeps a very close eye on things and suggested using 1.0-SNAPSHOT instead. Um I think that goes both ways. Because all specs are currently at 1.1-SNAPSHOT, you mistakenly created a new spec at 1.1-SNAPSHOT. As specs become more independent, I would expect you would naturally choose 1.0-SNAPSHOT for a new spec. In addition, new specs do not come along that often so making a mistake once a year is not a big deal. I agree that could go either way. Besides, what seems intuitive for me usually ends up getting me into trouble so I shouldn't have even brought it up. :-) I also believe having the specs all at a single release is consistent with the approach we use in server/trunk, where the artifacts share the same geronimo version and when necessary a version number can be included in the artifactId. Consistency has its benefits. In that case, why not move specs into the server tree? So a single version of specs can support more than one version of the server. Would that not be the case with the 1.2 and 2.0-M1 versions of the server? -dain
Re: Strange build problem
I wish I could say I removed it without any additional qualification. :-P However, what I actually said was that I removed it *from the root pom*. I still have references to the java.net as a legacy repo in modules/geronimo-web-2.5-builder, configs/tomcat6 and configs/jetty6 to pick up jstl 1.2. AFAIK this shouldn't cause a problem for modules/geronimo-cxf-builder or generally anything other than children of the poms I changed ... right? Joe Jason Dillon wrote: Not sure... might be getting picked up as a dependency too. You removed it? Where are you getting jstl 2.0 from now? --jason On Dec 11, 2006, at 1:49 AM, Joe Bohn wrote: I removed the legacy java.net repo from the root pom Friday PM. Are there others? Joe Jason Dillon wrote: Strange dependency muck like this often happens when a legacy repo is in the mix. --jason On Dec 10, 2006, at 8:55 PM, anita kulshreshtha wrote: When I build cxf-builder from modules directory, I get this error: Missing: -- 1) wsdl4j:wsdl4j:jar:1.6.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=wsdl4j - DartifactId=wsdl4j \ -Dversion=1.6.1 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-cxf-builder:jar:2.0-SNAPSHOT 2) org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.0-incubator-M1-SNAPSHOT 3) org.apache.cxf:cxf-tools-common:jar:2.0-incubator-M1-SNAPSHOT 4) wsdl4j:wsdl4j:jar:1.6.1 -- This jar is not in my .m2 repo, only a pom is present. When I build from geronimo-cxf-builder directory, the module builds fine. it appears to be using wsdl4j-1.5.2 jar. Is anyone else having this problem? Thanks Anita __ __ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
Re: [discuss] sun xsd's and dtd's in specs source tree
I attached to https://issues.apache.org/jira/browse/GERONIMO-2630 a simple Java program that can remove any XML comments or xsd:annotation elements from a given XSD file. It might be useful to check the hand-typed files with the the cleaned up files (generated by this tool using the Sun's original files). Jarek On 12/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Bugger...the 1.4 XSD is done...I'm wondering about how to verify the accuracy of these. I have been experimenting a bit while doing this. One thing I started doing was closing of xsd:elements. For instance: Where the original doc had something like: xsd:element name=res-type type=j2ee:fully-qualified-classType xsd:annotation xsd:documentation The res-type element specifies the type of the data source. The type is specified by the fully qualified Java language class or interface expected to be implemented by the data source. /xsd:documentation /xsd:annotation /xsd:element I entered: xsd:element name=res-type type=j2ee:fully-qualified-classType / Although syntactically the same its a bit harder to verify. I was thinking about writing a quick parser that would read the Sun XSDs and verify the content throwing out whitespace and documentation. Perhaps we can do something with XMLBeans? David, any thoughts? On Dec 9, 2006, at 2:39 AM, Matt Hogstrom wrote: Thoughts, please... FYI the files are listed below: web-app_2_4.xsd jsp_2_0.xsd web-jsptaglibrary_2_0.xsd jsp_2_1.xsd j2ee_1_4.xsd is done. I'll look at the 2_1 taglibrary next. I'll do the above tonight...I have the first two done but thought that I should give a heads up. web-jsptaglibrary_2_1.xsd j2ee_web_services_1_1.xsd j2ee_web_services_client_1_1.xsd web-app_2_3.dtd Are these really necessary? geronimo/specs/trunk/geronimo-servlet_2.5_spec/src/main/java/ javax/servlet/http/package.html geronimo/specs/trunk/geronimo-servlet_2.5_spec/src/main/java/ javax/servlet/package.html --kevan Matt Hogstrom [EMAIL PROTECTED] Matt Hogstrom [EMAIL PROTECTED] Matt Hogstrom [EMAIL PROTECTED]
[jira] Updated: (SM-771) An IllegalStateException is generated when using an http provider endpoint when it is deployed using the Servicemix Web war (managed mode).
[ https://issues.apache.org/activemq/browse/SM-771?page=all ] Jeff Puro updated SM-771: - Attachment: servicemix-http-connection-manager-3.0.1.patch The attached file is a patch for ServiceMix 3.0.1. This solves the issue by setting the connectionManager and client object references to null so that when doInit is executed again it reinitializes the connectionManager. There will be a subsequent patch file for 3.1. An IllegalStateException is generated when using an http provider endpoint when it is deployed using the Servicemix Web war (managed mode). --- Key: SM-771 URL: https://issues.apache.org/activemq/browse/SM-771 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1, 3.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1, 3.1 Attachments: servicemix-http-connection-manager-3.0.1.patch Original Estimate: 1 hour Remaining Estimate: 1 hour When using an HTTP provider endpoint while the service unit is deployed using the apache servicemix web project (that is using managed mode), it generates the following Exception. java.lang.IllegalStateException: Connection factory has been shutdown. at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:454) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnectionWithTimeout(MultiThreadedHttpConnectionManager.java:407) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:152) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346) at org.apache.servicemix.http.processors.ProviderProcessor.process(ProviderProcessor.java:153) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:410) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:43) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:624) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:170) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:177) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:227) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) -- 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: Convention on dropping tests under the test framework
On 12/10/06, David Jencks [EMAIL PROTECTED] wrote: On Dec 8, 2006, at 1:29 PM, Prasad Kashyap wrote: David, Check out this patch http://people.apache.org/~prasad/manifestcp.patch Apply it from the geronimo/testsuite/depoyment-testsuite directory. It will create 2 directories under it. -- The manifestcp will create the ear for. -- The test-manifestcp will deploy and undeploy it. Throw your testcases under test-manifestcp. When I apply the patch I get files with many copies of the content. Assuming this builds for you can you commit it? I have committed this code. Please read the comments in deployment-testsuite/manifestcp/pom.xml Cheers Prasad
Re: [DISCUSS] specs versioning
On Dec 11, 2006, at 12:40 PM, Paul McMahan wrote: On 12/11/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote: I'm in favor of a single version for all specs. Versioning the specs individually has some advantages but makes the release manager's job more difficult since the tooling doesn't readily support that approach. Um.. that's not true. Maven has full support for this. Also it doesn't make the release manager's job harder. Maybe I read too much into the wiki page that Kevan referenced, which lists the following advantage for using a single version for specs: - Release process is simple and can be fully automated with the release plugin And the following listed as a disadvantage of versioning the specs individually: - Releases are more difficult because the person performing the release must be aware of any dependencies and must also rerelease those jars. (eliminated with working version-ranges) I thought you were referring to the Geronimo server releases. Yes the above is true for releasing specs, but releasing specs is a very rare thing since specs are rarely added or removed. and lists as a supporting fact: - Version ranges don't work several (most?) important maven plugins Is the wiki page outdated or am I missing the point? Nope that is accurate. I also believe having the specs all at a single release is consistent with the approach we use in server/trunk, where the artifacts share the same geronimo version and when necessary a version number can be included in the artifactId. Consistency has its benefits. In that case, why not move specs into the server tree? So a single version of specs can support more than one version of the server. Would that not be the case with the 1.2 and 2.0-M1 versions of the server? I was being a devil's advocate. In general, once we release a spec is should never change (i.e., should be 1.0 forever). Only in the rare case where we find bugs in a spec would we release an update. In that case, the specs would support all versions of the server that need that spec, another project using our specs, and any user applications using our specs. -dain
[jira] Commented: (AMQCPP-23) active-cpp persistent problem
[ https://issues.apache.org/activemq/browse/AMQCPP-23?page=comments#action_37647 ] Timothy Bish commented on AMQCPP-23: I've checked a fix into trunk. Seems to work for me, try it out if you can and let me know if it resolves the issue. active-cpp persistent problem - Key: AMQCPP-23 URL: https://issues.apache.org/activemq/browse/AMQCPP-23 Project: ActiveMQ C++ Client Issue Type: Bug Components: Stomp Affects Versions: 1.0 Environment: ActiveMQ 4.0.2 activemq-cpp-1.0 fedora 5 Reporter: james nomingo Assigned To: Timothy Bish Fix For: 1.1 I'm struggling with persistent option in activemq-cpp client. (my java client does the trick) part of my code looks like: producer-setDeliveryMode( DeliveryMode::PERSISTANT ); The problem is after I send a message, and stop the broker. The message is gone. If I send a lot of message exceeding the memory size the broker handles, I got resource unavailable exception. It looks to me the message I send over using cpp doesn't instruct the broker to use persistent. I'm using ActiveMQ 4.0.2, and activemq-cpp-1.0. -- 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: test-ejbcontainer working?
On Dec 11, 2006, at 11:38 AM, Prasad Kashyap wrote:
On 12/11/06, David Blevins [EMAIL PROTECTED] wrote:
On Dec 11, 2006, at 10:44 AM, Prasad Kashyap wrote:
I'm seeing a different problem. The openejb-itests-core cannot be
distributed since it has a dependency on j2ee-corba-yoko/1.2-
SNAPSHOT.
What is the error you get?
[INFO] [INFO] Distributing module artifact: C:\Documents and
Settings\Administrator\.m2\repository\org\apache\openejb\openejb-
itests-core\2.2-incubating-SNAPSHOT\openejb-itests-core-2.2-
incubating-SNAPSHOT.jar
with plan null
[WARNING] Deployer operation failed: Unable to create configuration
for deployment
[WARNING] org.apache.geronimo.common.DeploymentException: Unable to
create configuration for deployment
...
...
...
[WARNING] Caused by:
org.apache.geronimo.kernel.repository.MissingDependencyException:
Unable to resolve dependency
org.apache.geronimo.configs/j2ee-corba-yoko/1.2-SNAPSHOT/car
I'm a bit confused.. I'm looking in geronimo/server/trunk/testsuite/
enterprise-testsuite/test-ejbcontainer/pom.xml which has a reference to:
module
groupIdorg.apache.openejb/groupId
artifactIdopenejb-itests-core/artifactId
version${openejbVersion}/version
typecar/type
/module
Where is the car file created? I can't seem to find it.
-David
Cheers
Prasad
Re: [DISCUSS] specs versioning
On Dec 11, 2006, at 12:40 PM, Paul McMahan wrote: On 12/11/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote: I'm in favor of a single version for all specs. Versioning the specs individually has some advantages but makes the release manager's job more difficult since the tooling doesn't readily support that approach. Um.. that's not true. Maven has full support for this. Also it doesn't make the release manager's job harder. Maybe I read too much into the wiki page that Kevan referenced, which lists the following advantage for using a single version for specs: - Release process is simple and can be fully automated with the release plugin And the following listed as a disadvantage of versioning the specs individually: - Releases are more difficult because the person performing the release must be aware of any dependencies and must also rerelease those jars. (eliminated with working version-ranges) That's actually not true as you can mark all the deps of a spec as 'scopeprovided' which shuts off maven's transitivity. Then all this pom interlinking between specs which makes everyone's brain hurt just goes away. -David and lists as a supporting fact: - Version ranges don't work several (most?) important maven plugins Is the wiki page outdated or am I missing the point? And as a developer (at least for me) a single version is more intuitive, evidenced by my recent snafu where I created the initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason keeps a very close eye on things and suggested using 1.0-SNAPSHOT instead. Um I think that goes both ways. Because all specs are currently at 1.1-SNAPSHOT, you mistakenly created a new spec at 1.1-SNAPSHOT. As specs become more independent, I would expect you would naturally choose 1.0-SNAPSHOT for a new spec. In addition, new specs do not come along that often so making a mistake once a year is not a big deal. I agree that could go either way. Besides, what seems intuitive for me usually ends up getting me into trouble so I shouldn't have even brought it up. :-) I also believe having the specs all at a single release is consistent with the approach we use in server/trunk, where the artifacts share the same geronimo version and when necessary a version number can be included in the artifactId. Consistency has its benefits. In that case, why not move specs into the server tree? So a single version of specs can support more than one version of the server. Would that not be the case with the 1.2 and 2.0-M1 versions of the server? -dain
MileStone 1 Release of Geronimo 2.0 Branch Notice
All, Being the overly optimistic one that I am I'd like to branch trunk tomorrow in the afternoon. The goal of the branch is to stabilize a milestone release with the content previously discussed. So far it looks like we have: JSF, Java Mail Tomcat 6 Jetty 6 JSTL Java 1.5 ready and JPA I think Kevan is working on the specs which need to be completed for Geronimo 2.0 as well as 1.2. OpenEJB will need to release as well so I'm hoping to have an answer on the DayTrader issues tonight or tomorrow. I'm currently working through some issues with DayTrader on 1.2 which also apply to Geronimo 2.0. My thiking is that people will continue to work on trunk (2.0) while the M1 release is cleaned and made ready. I'll do the packaging and people can happily continue to hack away at trunk. Any major items missing? Matt Hogstrom [EMAIL PROTECTED]
Re: [discuss] sun xsd's and dtd's in specs source tree
On Dec 11, 2006, at 3:44 PM, Jarek Gawor wrote: I attached to https://issues.apache.org/jira/browse/GERONIMO-2630 a simple Java program that can remove any XML comments or xsd:annotation elements from a given XSD file. It might be useful to check the hand-typed files with the the cleaned up files (generated by this tool using the Sun's original files). Nice. Thanks Jarek! I believe that Matt is working on web-jsptaglibrary_2_1.xsd. That leaves the following: j2ee_web_services_1_1.xsd j2ee_web_services_client_1_1.xsd web-app_2_3.dtd I'll be starting w/ j2ee_web_services_1_1.xsd, and work my way down the list. If anybody is interested in chipping in. Let me know... --kevan
Re: [DISCUSS] specs versioning
IMHO I like option 3 which is both option 1 and 2. First, I think all SPECs should be versioned independently as not everyone is interested in all the specs. If, for instance, the Tomcat dudes decide to pick up anything we have they would only be interested in a subset and shouldn't be forced to consume the whole Java EE banana. So, in that light I think they should all be versioned separately. We should probably have a separate uber spec project that pulls in a set of versioned specs and releases them as a set so that people that want the whole enchilada can get them. The uber approach would only be compiling a set of released specs (which were released separately. For this proposal...I'd say release them individually and make the uber spec as the next step. IMHO small largely immutable specs make sense to me. On Dec 11, 2006, at 1:13 PM, Kevan Miller wrote: The versioning policy for our geronimo specs has been floating around for a while now. I'd like to see this issue resolved. There have been two approaches discussed 1) Single version -- all specs are released under the same version number. 2) Separate version -- each spec is versioned separately from the other specs. Dain created a review of the two proposals in the wiki -- http:// cwiki.apache.org/confluence/display/GMOxDEV/Spec+Versioning I think you can quibble over a few of the details, but it does a good job at summarizing the issue. IMO, there are going to be drawbacks no matter which approach we take. However, I'm going to be happy with either approach as long as we reach a *decision*. I'd prefer that we reach consensus on this discussion thread. However, if necessary, we can vote on the issue. Personally, I think we should use a single version for releasing our specs. I think this makes it easier for us as developers in managing spec releases. I think users will find it easier to collect a consistent set of specifications. I think these benefits outweigh concerns over the lack of flexibility and the wasteful aspects of re-releasing unchanged specifications. I suppose there's a hybrid option where we release separate versions, now, and move to a single version policy (2.0?) for our next release. --kevan Matt Hogstrom [EMAIL PROTECTED]
Re: [discuss] sun xsd's and dtd's in specs source tree
I can take web-app_2_3 On Dec 11, 2006, at 4:08 PM, Kevan Miller wrote: On Dec 11, 2006, at 3:44 PM, Jarek Gawor wrote: I attached to https://issues.apache.org/jira/browse/GERONIMO-2630 a simple Java program that can remove any XML comments or xsd:annotation elements from a given XSD file. It might be useful to check the hand-typed files with the the cleaned up files (generated by this tool using the Sun's original files). Nice. Thanks Jarek! I believe that Matt is working on web-jsptaglibrary_2_1.xsd. That leaves the following: j2ee_web_services_1_1.xsd j2ee_web_services_client_1_1.xsd web-app_2_3.dtd I'll be starting w/ j2ee_web_services_1_1.xsd, and work my way down the list. If anybody is interested in chipping in. Let me know... --kevan -sachin
[jira] Created: (GERONIMO-2645) stax-api was regressed from 1.0.1 in G1.1.1 to 1.0 in G1.2
stax-api was regressed from 1.0.1 in G1.1.1 to 1.0 in G1.2 -- Key: GERONIMO-2645 URL: http://issues.apache.org/jira/browse/GERONIMO-2645 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Donald Woods Geronimo 1.1.1 included stax-api-1.0.1.jar, but the Geronimo 1.2 branch was never updated to match and still uses the older stax-api-1.0.jar 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
Re: Strange build problem
On Dec 11, 2006, at 12:43 PM, Joe Bohn wrote: I wish I could say I removed it without any additional qualification. :-P However, what I actually said was that I removed it *from the root pom*. I still have references to the java.net as a legacy repo in modules/geronimo-web-2.5-builder, configs/tomcat6 and configs/jetty6 to pick up jstl 1.2. AFAIK this shouldn't cause a problem for modules/geronimo-cxf- builder or generally anything other than children of the poms I changed ... right? Joe Ya, that is what I had thought. I believe this is why the strange build problem is occurring, as Anita says it happens when building from modules/ and not when building from geronimo-cxf-builder. When building from modules/ mvn will scan all modules and generate pom state for them, which includes setting up repos. 10 to 1, if you have the required artifacts in your repo already, then comment out those legacy repos (leaving the dependencies along), then this problem will go away. Really need to find a better solution to this immediate need for jstl and keep in mind in the future to now include legacy repos in the build. --jason
Re: [DISCUSS] specs versioning
On Dec 11, 2006, at 1:13 PM, Matt Hogstrom wrote: IMHO I like option 3 which is both option 1 and 2. First, I think all SPECs should be versioned independently as not everyone is interested in all the specs. If, for instance, the Tomcat dudes decide to pick up anything we have they would only be interested in a subset and shouldn't be forced to consume the whole Java EE banana. So, in that light I think they should all be versioned separately. We should probably have a separate uber spec project that pulls in a set of versioned specs and releases them as a set so that people that want the whole enchilada can get them. The uber approach would only be compiling a set of released specs (which were released separately. That sounds interesting, but I think we should wait until someone asks for that feature. I personally have found that in most cases you end up using only a couple of specs at a time. If someone has a good use case for an uber bundle, then we pull it together uber jar (or uber pom for maven users). -dain
[jira] Created: (GERONIMO-2646) WAR without a geronimo-web.xml deploys to the wrong context
WAR without a geronimo-web.xml deploys to the wrong context --- Key: GERONIMO-2646 URL: http://issues.apache.org/jira/browse/GERONIMO-2646 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.0-M1 Environment: tomcat6-jee5 and tomcat6-minimal assemblies Reporter: Paul McMahan Assigned To: Paul McMahan Priority: Critical Fix For: 2.0-M1 Deploy a simple war without a context-root defined in geronimo-web.xml : deploy.bat deploy helloworld.war Using GERONIMO_BASE: C:\geronimo-tomcat6-minimal-2.0-SNAPSHOT Using GERONIMO_HOME: C:\geronimo-tomcat6-minimal-2.0-SNAPSHOT Using GERONIMO_TMPDIR: C:\geronimo-tomcat6-minimal-2.0-SNAPSHOT\var\temp Using JRE_HOME:C:\Program Files\Java\jdk1.5.0_07\jre Deployed default/helloworld/1165871553812/war @ http://localhost:8080//helloworld Note the two forward slashes after the port number. Trying to access this location results in a HTTP 404 status code. -- 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: MileStone 1 Release of Geronimo 2.0 Branch Notice
Why? I don't see why we would want to make a branch just for 2.0-m1. SVN is not the best tool for working with many branches, so I would recommend keeping the active branches to an absolute minimum. What happened to stabilizing 1.2 and getting that out? I think that if you want to make 2.0-m1, then just pick a time on trunk when it looks good, then make the release and move on to the next milestone. IMO adding more branches here will just complicate the matter way more than it needs to be for a pre-alpha release. --jason On Dec 11, 2006, at 1:05 PM, Matt Hogstrom wrote: All, Being the overly optimistic one that I am I'd like to branch trunk tomorrow in the afternoon. The goal of the branch is to stabilize a milestone release with the content previously discussed. So far it looks like we have: JSF, Java Mail Tomcat 6 Jetty 6 JSTL Java 1.5 ready and JPA I think Kevan is working on the specs which need to be completed for Geronimo 2.0 as well as 1.2. OpenEJB will need to release as well so I'm hoping to have an answer on the DayTrader issues tonight or tomorrow. I'm currently working through some issues with DayTrader on 1.2 which also apply to Geronimo 2.0. My thiking is that people will continue to work on trunk (2.0) while the M1 release is cleaned and made ready. I'll do the packaging and people can happily continue to hack away at trunk. Any major items missing? Matt Hogstrom [EMAIL PROTECTED]
Re: test-ejbcontainer working?
The openejb-itests-core is created in the openejb itself.
http://svn.apache.org/viewvc/incubator/openejb/branches/v2_2/openejb2/itests/
The top level pom in openejb has the geronimoVersion property set to
1.2-SNAPSHOT.
So the itests-core's pom and plans all use this property during
resource filtering and thus have a dependency on it.
Cheers
Prasad
On 12/11/06, David Blevins [EMAIL PROTECTED] wrote:
On Dec 11, 2006, at 11:38 AM, Prasad Kashyap wrote:
On 12/11/06, David Blevins [EMAIL PROTECTED] wrote:
On Dec 11, 2006, at 10:44 AM, Prasad Kashyap wrote:
I'm seeing a different problem. The openejb-itests-core cannot be
distributed since it has a dependency on j2ee-corba-yoko/1.2-
SNAPSHOT.
What is the error you get?
[INFO] [INFO] Distributing module artifact: C:\Documents and
Settings\Administrator\.m2\repository\org\apache\openejb\openejb-
itests-core\2.2-incubating-SNAPSHOT\openejb-itests-core-2.2-
incubating-SNAPSHOT.jar
with plan null
[WARNING] Deployer operation failed: Unable to create configuration
for deployment
[WARNING] org.apache.geronimo.common.DeploymentException: Unable to
create configuration for deployment
...
...
...
[WARNING] Caused by:
org.apache.geronimo.kernel.repository.MissingDependencyException:
Unable to resolve dependency
org.apache.geronimo.configs/j2ee-corba-yoko/1.2-SNAPSHOT/car
I'm a bit confused.. I'm looking in geronimo/server/trunk/testsuite/
enterprise-testsuite/test-ejbcontainer/pom.xml which has a reference to:
module
groupIdorg.apache.openejb/groupId
artifactIdopenejb-itests-core/artifactId
version${openejbVersion}/version
typecar/type
/module
Where is the car file created? I can't seem to find it.
-David
Cheers
Prasad
Re: MileStone 1 Release of Geronimo 2.0 Branch Notice
Another Q. If a branch is made, would the code there have to maintained ? Would bug fixes in 1.2 be rolled into the trunk as well as the M1 branch ? I hope not. I hope it is just for tagging purpose and the code there would not have to be maintained post M1 release. Cheers Prasad On 12/11/06, Jason Dillon [EMAIL PROTECTED] wrote: Why? I don't see why we would want to make a branch just for 2.0-m1. SVN is not the best tool for working with many branches, so I would recommend keeping the active branches to an absolute minimum. What happened to stabilizing 1.2 and getting that out? I think that if you want to make 2.0-m1, then just pick a time on trunk when it looks good, then make the release and move on to the next milestone. IMO adding more branches here will just complicate the matter way more than it needs to be for a pre-alpha release. --jason On Dec 11, 2006, at 1:05 PM, Matt Hogstrom wrote: All, Being the overly optimistic one that I am I'd like to branch trunk tomorrow in the afternoon. The goal of the branch is to stabilize a milestone release with the content previously discussed. So far it looks like we have: JSF, Java Mail Tomcat 6 Jetty 6 JSTL Java 1.5 ready and JPA I think Kevan is working on the specs which need to be completed for Geronimo 2.0 as well as 1.2. OpenEJB will need to release as well so I'm hoping to have an answer on the DayTrader issues tonight or tomorrow. I'm currently working through some issues with DayTrader on 1.2 which also apply to Geronimo 2.0. My thiking is that people will continue to work on trunk (2.0) while the M1 release is cleaned and made ready. I'll do the packaging and people can happily continue to hack away at trunk. Any major items missing? Matt Hogstrom [EMAIL PROTECTED]
Re: [DISCUSS] specs versioning
On Dec 11, 2006, at 10:13 AM, Kevan Miller wrote: Personally, I think we should use a single version for releasing our specs. I think this makes it easier for us as developers in managing spec releases. I think users will find it easier to collect a consistent set of specifications. I think these benefits outweigh concerns over the lack of flexibility and the wasteful aspects of re-releasing unchanged specifications. I'm obviously +1 on this. One version provides much needed simplification for the build process. IMO maven's existing model of versioning each module separately is a dangerous build anti-pattern and we should not follow it. I suppose there's a hybrid option where we release separate versions, now, and move to a single version policy (2.0?) for our next release. Ya, thats probably what I would recommend... though really, if we can agree to use one version then we could just a 2.0 now and update G 1.2 and 2.0 to just use those versions. --jason
Re: MileStone 1 Release of Geronimo 2.0 Branch Notice
In order to make a release you have to touch several files, such as bumping the versions from 2.0-SNAPSHOT to 2.0-M1 in the poms. IIUC that is all we need the branch for and can otherwise continue working on trunk without porting changes back to the branch. Best wishes, Paul On 12/11/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Another Q. If a branch is made, would the code there have to maintained ? Would bug fixes in 1.2 be rolled into the trunk as well as the M1 branch ? I hope not. I hope it is just for tagging purpose and the code there would not have to be maintained post M1 release. Cheers Prasad On 12/11/06, Jason Dillon [EMAIL PROTECTED] wrote: Why? I don't see why we would want to make a branch just for 2.0-m1. SVN is not the best tool for working with many branches, so I would recommend keeping the active branches to an absolute minimum. What happened to stabilizing 1.2 and getting that out? I think that if you want to make 2.0-m1, then just pick a time on trunk when it looks good, then make the release and move on to the next milestone. IMO adding more branches here will just complicate the matter way more than it needs to be for a pre-alpha release. --jason On Dec 11, 2006, at 1:05 PM, Matt Hogstrom wrote: All, Being the overly optimistic one that I am I'd like to branch trunk tomorrow in the afternoon. The goal of the branch is to stabilize a milestone release with the content previously discussed. So far it looks like we have: JSF, Java Mail Tomcat 6 Jetty 6 JSTL Java 1.5 ready and JPA I think Kevan is working on the specs which need to be completed for Geronimo 2.0 as well as 1.2. OpenEJB will need to release as well so I'm hoping to have an answer on the DayTrader issues tonight or tomorrow. I'm currently working through some issues with DayTrader on 1.2 which also apply to Geronimo 2.0. My thiking is that people will continue to work on trunk (2.0) while the M1 release is cleaned and made ready. I'll do the packaging and people can happily continue to hack away at trunk. Any major items missing? Matt Hogstrom [EMAIL PROTECTED]
Re: [DISCUSS] specs versioning
On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote: On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote: I'm in favor of a single version for all specs. Versioning the specs individually has some advantages but makes the release manager's job more difficult since the tooling doesn't readily support that approach. Um.. that's not true. Maven has full support for this. Also it doesn't make the release manager's job harder. Sure it does Dain, running one set of `mvn release:prepare mvn release:perform` vs, running one per spec module. That is significantly more work for the latter. Also, if you consider hooking up this process to a build automation tool, so that each build gets released by that tool, then the specs project effectively needs to get split up into a project per-module, which is a bunch of unneeded overhead. While mvn can go both ways, one version for many modules is significantly easier. And as a developer (at least for me) a single version is more intuitive, evidenced by my recent snafu where I created the initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason keeps a very close eye on things and suggested using 1.0-SNAPSHOT instead. Um I think that goes both ways. Because all specs are currently at 1.1-SNAPSHOT, you mistakenly created a new spec at 1.1-SNAPSHOT. As specs become more independent, I would expect you would naturally choose 1.0-SNAPSHOT for a new spec. In addition, new specs do not come along that often so making a mistake once a year is not a big deal. Could be, though the error was because it was a svn copy, not because someone though that it should start at a different version. So the exact same problem could happen either way. The only way to remove that completely is to remove the version from the equation... one version for all specs does just that. --jason
