[jira] Resolved: (SM-828) OutBinding doesn't allow for DeliveryChannel.accept()
[ https://issues.apache.org/activemq/browse/SM-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-828. Resolution: Fixed Fix Version/s: 3.2 3.1.1 Assignee: Guillaume Nodet Thanks for this patch ! Author: gnodet Date: Thu Feb 15 01:52:58 2007 New Revision: 507870 URL: http://svn.apache.org/viewvc?view=revrev=507870 Log: SM-828: OutBinding does not allow for DeliveryChannel.accept() Modified: incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/components/util/OutBinding.java Author: gnodet Date: Thu Feb 15 01:55:04 2007 New Revision: 507871 URL: http://svn.apache.org/viewvc?view=revrev=507871 Log: SM-828: OutBinding does not allow for DeliveryChannel.accept() Modified: incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/components/util/OutBinding.java OutBinding doesn't allow for DeliveryChannel.accept() - Key: SM-828 URL: https://issues.apache.org/activemq/browse/SM-828 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 3.0 Environment: Windows XP ServiceMix 3.0 JDK 1.5 Reporter: James Lorenzen Assigned To: Guillaume Nodet Priority: Blocker Fix For: 3.1.1, 3.2 Attachments: OutBinding.java The incorrect use of AtomicBoolean in OutBinding prevents components from ever receiving a new MessageExchange through the DeliveryChannel accept() method. The variable stop gets initialized with false. The start method sets it to true. The run method checks the value and only calls accept if this statement is true: while(!stop.get()). Since the value of stop is true, the component never calls DeliveryChannel.accept(). This bug has been found because we attempted to deploy our component, who extends OutBinding, in OpenESB/Glassfish. Our component was never receiving the message and this is how we discovered the bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-834) Provide File Marshalling for CSV/variable, fixed and heirarchial messages
[ https://issues.apache.org/activemq/browse/SM-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38519 ] Juergen Mayrbaeurl commented on SM-834: --- Just upgraded to ServiceMix 3.1 - SimpleFlatFileMarshaler didn't work anymore. Changed it to use StringSource instead of StreamSource (Source attached) Provide File Marshalling for CSV/variable, fixed and heirarchial messages - Key: SM-834 URL: https://issues.apache.org/activemq/browse/SM-834 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.2 Attachments: zpv-contrib-servicemix-file.zip Provide file marshalling for file binding components similar to Parser Service Engine from Bostech ChainBuilder ESB (http://chainforge.net/chainbuilder/index.html) Sources as starting point attached. They show how to get CSV or fixed-length flat files on the bus in a generic way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-834) Provide File Marshalling for CSV/variable, fixed and heirarchial messages
[ https://issues.apache.org/activemq/browse/SM-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juergen Mayrbaeurl updated SM-834: -- Attachment: SimpleFlatFileMarshaler.java Working version of SimpleFlatFileMarshaler for ServiceMix 3.1 Provide File Marshalling for CSV/variable, fixed and heirarchial messages - Key: SM-834 URL: https://issues.apache.org/activemq/browse/SM-834 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.2 Attachments: SimpleFlatFileMarshaler.java, zpv-contrib-servicemix-file.zip Provide file marshalling for file binding components similar to Parser Service Engine from Bostech ChainBuilder ESB (http://chainforge.net/chainbuilder/index.html) Sources as starting point attached. They show how to get CSV or fixed-length flat files on the bus in a generic way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-839) java.lang.IllegalStateException: Could not find valid implementation for: 2.0
[ https://issues.apache.org/activemq/browse/SM-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38521 ] Guillaume Nodet commented on SM-839: I've seen the spring 1.2.6 jar. I will remove it. But how do you see the IllegalStateException, as the spring classes are usually loaded from the container classloader ? java.lang.IllegalStateException: Could not find valid implementation for: 2.0 - Key: SM-839 URL: https://issues.apache.org/activemq/browse/SM-839 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 3.1 Environment: AIX\ websphere 6.1 Reporter: Alper Sogukpinar Theres is spring-1.2.6.jar in servicemix-jsr181-3.1-incubating-installer.zip. When spring-1.2.6.jar put in application classpath it generates java.lang.IllegalStateException: Could not find valid implementation for: 2.0 exception. When I changed spring-1.2.6.jar in my classpath with 2.0., the problem solved. spring-1.2.6.jar must be changed with spring-2.0.jar in servicemix-jsr181-3.1-incubating-installer.zip archive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-839) java.lang.IllegalStateException: Could not find valid implementation for: 2.0
[ https://issues.apache.org/activemq/browse/SM-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-839. Resolution: Fixed Fix Version/s: 3.2 3.1.1 Assignee: Guillaume Nodet Author: gnodet Date: Thu Feb 15 02:33:54 2007 New Revision: 507877 URL: http://svn.apache.org/viewvc?view=revrev=507877 Log: SM-839: java.lang.IllegalStateException: Could not find valid implementation for: 2.0 Modified: incubator/servicemix/trunk/deployables/serviceengines/servicemix-jsr181/pom.xml Author: gnodet Date: Thu Feb 15 02:35:37 2007 New Revision: 507878 URL: http://svn.apache.org/viewvc?view=revrev=507878 Log: SM-839: java.lang.IllegalStateException: Could not find valid implementation for: 2.0 Modified: incubator/servicemix/branches/servicemix-3.1/deployables/serviceengines/servicemix-jsr181/pom.xml java.lang.IllegalStateException: Could not find valid implementation for: 2.0 - Key: SM-839 URL: https://issues.apache.org/activemq/browse/SM-839 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 3.1 Environment: AIX\ websphere 6.1 Reporter: Alper Sogukpinar Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 Theres is spring-1.2.6.jar in servicemix-jsr181-3.1-incubating-installer.zip. When spring-1.2.6.jar put in application classpath it generates java.lang.IllegalStateException: Could not find valid implementation for: 2.0 exception. When I changed spring-1.2.6.jar in my classpath with 2.0., the problem solved. spring-1.2.6.jar must be changed with spring-2.0.jar in servicemix-jsr181-3.1-incubating-installer.zip archive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SM-236) Unable to start ServiceMix 2.1-SNAPSHOT - ClassCircularityError
[ https://issues.apache.org/activemq/browse/SM-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed SM-236. -- Resolution: Won't Fix Unable to start ServiceMix 2.1-SNAPSHOT - ClassCircularityError Key: SM-236 URL: https://issues.apache.org/activemq/browse/SM-236 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 2.0.2, 3.0-M1 Environment: AIX 5.3, RedHat Linux AS 3.0; IBM JVM 1.4 aand 1.5 Beta Reporter: Jonathan Edwards Priority: Blocker Original Estimate: 0 minutes Remaining Estimate: 0 minutes This defect also affects IBM JVM 1.4. When attempting to start ServiceMix, the following exception is thrown which halts execution: /opt/java/IBMJava2-150-beta/bin/java -Xmx512M -Dderby.system.home=/opt/apps/servicemix/servicemix-2.1-SNAPSHOT-1050-1/var -Dderby.storage.fileSyncTransactionLog=true -classpath .:/opt/apps/ant/current/lib/ant.jar:/opt/apps/ant/current/lib/ant-launcher.jar:/opt/apps/active/4.0/classes:.:/opt/apps/ant/current/lib/ant.jar:/opt/apps/ant/current/lib/ant-launcher.jar:/opt/apps/active/4.0/classes::/opt/apps/servicemix/servicemix-2.1-SNAPSHOT-1050-1/conf:/opt/apps/servicemix/servicemix-2.1-SNAPSHOT-1050-1/lib/classworlds-1.0.1.jar -Dclassworlds.conf=/opt/apps/servicemix/servicemix-2.1-SNAPSHOT-1050-1/conf/servicemix.conf -Dservicemix.home=/opt/apps/servicemix/servicemix-2.1-SNAPSHOT-1050-1 -Dcygwin.user.home= -Djava.endorsed.dirs=/opt/apps/servicemix/servicemix-2.1-SNAPSHOT-1050-1/lib/endorsed org.codehaus.classworlds.Launcher ServiceMix ESB: 2.1-SNAPSHOT Loading ServiceMix from servicemix.xml on the CLASSPATH Dec 12, 2005 12:13:02 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions INFO: Loading XML bean definitions from class path resource [servicemix.xml] Exception in thread main java.lang.ClassCircularityError at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.access$000(ClassLoader.java:30) at java.lang.ClassLoader$1.run(ClassLoader.java:212) at java.security.AccessController.doPrivileged(AccessController.java:217) at java.lang.ClassLoader.defineClass(ClassLoader.java:210) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:146) at java.net.URLClassLoader.defineClass(URLClassLoader.java:531) at java.net.URLClassLoader.access$400(URLClassLoader.java:116) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:911) at java.security.AccessController.doPrivileged(AccessController.java:270) at java.net.URLClassLoader.findClass(URLClassLoader.java:462) at java.lang.ClassLoader.loadClass(ClassLoader.java:542) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClassDirect(DefaultClassRealm.java:412) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:376) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:506) at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:75) at java.lang.J9VMInternals.verify(J9VMInternals.java:40) at java.lang.ClassLoader.resolveClass(ClassLoader.java:566) at java.lang.ClassLoader.loadClass(ClassLoader.java:550) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClassDirect(DefaultClassRealm.java:412) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:376) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:506) at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.access$000(ClassLoader.java:30) at java.lang.ClassLoader$1.run(ClassLoader.java:212) at java.security.AccessController.doPrivileged(AccessController.java:217) at java.lang.ClassLoader.defineClass(ClassLoader.java:210) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:146) at java.net.URLClassLoader.defineClass(URLClassLoader.java:531) at java.net.URLClassLoader.access$400(URLClassLoader.java:116) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:911) at java.security.AccessController.doPrivileged(AccessController.java:270) at
[jira] Created: (SM-844) Using Shared Libraries from LW SUs
Using Shared Libraries from LW SUs -- Key: SM-844 URL: https://issues.apache.org/activemq/browse/SM-844 Project: ServiceMix Issue Type: Improvement Components: servicemix-lwcontainer Affects Versions: 3.1 Environment: ServiceMix LW Container Reporter: Juergen Mayrbaeurl Fix For: 3.2 With ServiceMix 3.1 it isn't possible to use shared libraries in LW service units, because classloading (and configuration) and referencing shared libraries isn't supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-845) servicemix-quartz includes unneeded spring libraries
servicemix-quartz includes unneeded spring libraries Key: SM-845 URL: https://issues.apache.org/activemq/browse/SM-845 Project: ServiceMix Issue Type: Bug Components: servicemix-quartz Affects Versions: 3.1 Reporter: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-834) Provide File Marshalling for CSV/variable, fixed and heirarchial messages
[ https://issues.apache.org/activemq/browse/SM-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38524 ] Guillaume Nodet commented on SM-834: Hi Juergen ! Thanks for this patch. Could you please add the Apache headers to the source files and provide a single diff file (with the needed modifications on the pom.xml to add commons-io dependency) please ? Also, do you have a simple test case for the SimpleFlatFileMarshaler, which is the main class of this patch ? Provide File Marshalling for CSV/variable, fixed and heirarchial messages - Key: SM-834 URL: https://issues.apache.org/activemq/browse/SM-834 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.2 Attachments: FileExtensionPropertyExpression.java, SimpleFlatFileMarshaler.java, zpv-contrib-servicemix-file.zip Provide file marshalling for file binding components similar to Parser Service Engine from Bostech ChainBuilder ESB (http://chainforge.net/chainbuilder/index.html) Sources as starting point attached. They show how to get CSV or fixed-length flat files on the bus in a generic way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2485) PersistenceUnitGBean needs a NamespaceDrivenDeployer
[ https://issues.apache.org/jira/browse/GERONIMO-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473323 ] David Jencks commented on GERONIMO-2485: In rev 507861 I made it so persistence units specified with persistence.xml embedded in geronimo plans won't have name collisions by providing a EARContext for ejb modules that has a module specific name but shares the underlying Configuration and everything else with the ear's EARContext. This puts the ejb module name into the persistence unit's name just like other gbeans from the ejb module. This will also eliminate similar name collisions between plain gbeans in different ejb modules in the same ear. The code that constructs an abstract name using the location of the persistence unit in the ear is not yet finished. PersistenceUnitGBean needs a NamespaceDrivenDeployer Key: GERONIMO-2485 URL: https://issues.apache.org/jira/browse/GERONIMO-2485 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: persistence Reporter: David Jencks Assigned To: David Jencks Fix For: 2.0-M2 Most of the config into in PersistenceUnitGBean can be read out of persistence.xml. We should write a NamespaceDrivenBuilder that uses custom xml and can either set stuff from the supplied xml, look for persistence.xml in a specified location, or look for persistence.xml in a default location, and parse persistence.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Daytrader newbie
Hi Chris, Thanks for the information but still it is getting failed for me. Following are the steps I have followed the current situation. May be you might have some more insight on it than me. 1. Get the latest source code from DT trunk (revision 507843). 2. Build the source code using mvn clean install. 3. Start the G 1.2 beta server. 4. Create the derby database using createDB.sh. (I have given it in the DAYTRADER-35 patch would be greately appriciated if someone can review it too) 5. Deploy the daytrader-ear-2.0-SNAPSHOT.ear dtTrunk_geronimo12-beta-plan.xml using G console. 6. Getting following error :(. Thanks Again, Lasantha 15:01:14,658 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/j2ee-corba-yoko/1.2-beta/car?ServiceModule=org.apache.geronimo.configs/j2ee-corba-yoko/1.2-beta/car,j2eeType=CORBANameService,name=NameServer java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_changed(Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange(PIManager.java:531) at org.apache.yoko.orb.OBPortableServer.POAManager_impl.activate(POAManager_impl.java:212) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.initialize(TransientNameService.java:129) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.run(TransientNameService.java:114) at org.apache.openejb.yoko.ORBConfigAdapter.createNameService(ORBConfigAdapter.java:167) at org.apache.openejb.yoko.ORBConfigAdapter$$FastClassByCGLIB$$c8ca5bf1.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.openejb.corba.security.config.ConfigAdapter$$EnhancerByCGLIB$$825d752c.createNameService(generated) at org.apache.openejb.corba.NameService.doStart(NameService.java:162) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:984) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:543) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:378) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:527) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:508) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at
Re: [CONF] Apache Geronimo Documentation: Tips for writing and formatting documentation (page edited)
Aight... I've re-crafted this page, have a look:
http://cwiki.apache.org/geronimo/tips-for-writing-and-formatting-
documentation.html
--jason
On Feb 14, 2007, at 2:43 PM, Hernan Cunico wrote:
As I said before, my idea for that doc was not to show all the
options Confluence offer but how to apply some of those formats
specifically on the Geronimo documentation.
Please, feel free to update the document with the format you think
would be easier to understand. That was just my vision for
explaining these formats consistently applied to a specific case.
Others pls chime in with your opinions too, the more comments the
better. Ultimately, the goal is to provide a clear message of how
to format an article in a consistent way with the rest of the
documentation.
Cheers!
Hernan
Jason Dillon wrote:
On Feb 14, 2007, at 5:54 AM, Hernan Cunico wrote:
Jason Dillon wrote:
This style of page is not really very easy to read... as it
basically tosses out any use of any markup... and does not link
to urls, etc...
That's the whole point, so you can see how to the wiki markup
should used. Otherwise you would be seeing just the end result
(which you can also see by looking to any other doc anyway) and
will have to check the page source (edit) to see how it is
implemented.
Um, you are missing *my point* Hernan, that *most* of the content
on that page is *not* wiki markup, but explanations on how to use
the markup, with small examples of wiki markup.
Because you have wrapped the entire content in a big {noformat}
then *nothing* else inside can use wiki notation, and it won't
render URLs... so the URLs you added for http://www.openoffice.org
or http://confluence.atlassian.com/display/CONFEXT/Gliffy+Plugin
+for+Confluence+-+Diagram+and+draw+in+Confluence simply don't
render as links.
This style is also hard to read... since you can't differentiate
sections of the tips very well.
My recommendation is still, to *not* use a *big* {noformat} for
*all* of the content, but to only wrap the wiki notation examples
with {noformat}, and let the rest make use of the mark up to help
organize/display the content better.
--jason
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ https://issues.apache.org/jira/browse/GERONIMO-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473363 ] Shiva Kumar H R commented on GERONIMO-2577: --- Opened a bug in Tomcat Bugzilla for context level clustering problem: Context level clustering on 3 or more nodes fails in Tomcat 5.5.20 http://issues.apache.org/bugzilla/show_bug.cgi?id=41620; Created a separate article on Geronimo Tomcat Host Level Clustering http://cwiki.apache.org/GMOxDOC11/geronimo-tomcat-context-level-clustering-sample-application.html And updated the current clustering article http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html with the following warning: Context level clustering has a known bug in Tomcat as reported in https://issues.apache.org/jira/browse/GERONIMO-2577 and http://issues.apache.org/bugzilla/show_bug.cgi?id=41620. Hence we recommend that you use Host level clustering as documented in http://cwiki.apache.org/GMOxDOC11/geronimo-tomcat-host-level-clustering-sample-application.html. - Shiva Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down. --- Key: GERONIMO-2577 URL: https://issues.apache.org/jira/browse/GERONIMO-2577 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering, Tomcat Affects Versions: 1.1, 1.1.1 Environment: JDK - Sun java version 1_5_0_09(32bit) OS- Red Hat Enterprise Linux ES4 update4(32bit) Http Server - Apache 2.0.59 +mod_jk 1.2.19 Reporter: Kaoru Matsumura Attachments: appClustering_context.xml, appClustering_server.xml, config.xml, context.xml, geronimo-new.log, geronimo-web-hostlevel.xml, geronimo-web-new.xml, geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, geronimo-web.xml, new-config.xml, server-nodeA.xml, server-nodeB.xml, server-nodeC.xml We run Geronimo cluster with three nodes. In our environment, with DeltaManager set for replication module, we found that the last node cound not continue the processes when the other nodes is intentionally halted in order. We recognize Tomcat 5.5.15 is OK with the same configuration and operations. Test Application The Web application program, which was used for the test, simply reads the number of access count, and then write the count to HttpSession object. Configuration?Files == We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html * config.xml We add the following parameters to the standard configuration. gbean name=TomcatEngine attribute name=initParamsname=Geronimo jvmRoute=nodeA/attribute /gbean Operations === 1 Have browser access to Test Application , and reload several times.(*1) HttpSession object is created on the nodeA. 2 And then, We kill the process of geronimo on the nodeA with $kill -9 Process ID.(*2) 3 Reload the browser at one time. The node changes to nodeB.(*3) 4 Reload the browser several times.(*4) 5 And then, We kill the process of geronimo on the nodeB with $kill -9 Process ID.(*5) 6 Reload the browser at one time.(And then, We expect that the process continues at the nodeC.) But the HttpSessionID of the HttpSession object is changed to another ID and the counter value is back to 1.(*6) As a result, the geronimo cluster cannot continue the process. For avoidance === When replication module is SimpleTcpReplicationManager, the geronimo cluster can continue the process. Debug levels logs == (*1) nodeA -- 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is 7160C8614D20687D3548E8488AB65AC3.nodeA 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL PROTECTED] at /ClusterCheck 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec 20:06:17,737 DEBUG [MsgContext] COMMIT 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] === MimeHeaders === 20:06:17,737 DEBUG [MsgContext] CLOSE 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on /ClusterCheck/counter 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. 20:06:17,757 DEBUG [McastService] Mcast receive ping from member org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, alive=58960] --- nodeC --- 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 ms. 20:06:17,655 DEBUG [DeltaManager]
[jira] Commented: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473370 ] Rakesh Midha commented on GERONIMO-2742: Try adding org.apache.geronimo.configs/sharedlib/2.0-SNAPSHOT/car in /var/config/offline-deployer-list if you want to use sharedlib with offline build. If you face an error specified in http://issues.apache.org/jira/browse/GERONIMO-2765 please let us know, otherwise things should work fine for you. Thanks Rakesh Deployer cannot access libaries in shared/lib and shared/classes Key: GERONIMO-2742 URL: https://issues.apache.org/jira/browse/GERONIMO-2742 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: Windows XP, Geronimo 1.2-beta Reporter: Aman Nanner Attachments: sharedlib-2.0.zip, sharedlib.zip, testing.ear.zip It seems that when running the deployer to deploy my EAR file, the classloaders during deployment cannot access the shared/lib and shared/classes directory. My app has dependencies on libraries that are stored in both shared/classes and shared/lib. Because these libraries cannot be found, the deployment fails. Neither regular deployment nor hot deployment works. My EAR file used to hot deploy properly in Geronimo 1.1.1 (I never used the regular deployer in 1.1.1, so I don't know if that would have worked too). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-834) Provide File Marshalling for CSV/variable, fixed and heirarchial messages
[ https://issues.apache.org/activemq/browse/SM-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38525 ] Juergen Mayrbaeurl commented on SM-834: --- Hi Guillaume! I've just build ServiceMix 3.2 and will now add my contribution. BTW the build didn't work, because XFire 1.2.2 uses a non existing repository location for its parent pom (see xfire-all-1.2.2.pom: repository entry 'java.net public repo' on 'https://maven-repository.dev.java.net/nonav/repository' has no group for org.codehaus.xfire). Simply commenting out the complete repositories block solves the problem. Maybe ServiceMix 3.2 should use XFire 1.2.3+. Do you have coding conventions for ServiceMix? Eclipse settings for code formatting? I'll provide some simple test cases. Provide File Marshalling for CSV/variable, fixed and heirarchial messages - Key: SM-834 URL: https://issues.apache.org/activemq/browse/SM-834 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.2 Attachments: FileExtensionPropertyExpression.java, SimpleFlatFileMarshaler.java, zpv-contrib-servicemix-file.zip Provide file marshalling for file binding components similar to Parser Service Engine from Bostech ChainBuilder ESB (http://chainforge.net/chainbuilder/index.html) Sources as starting point attached. They show how to get CSV or fixed-length flat files on the bus in a generic way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-834) Provide File Marshalling for CSV/variable, fixed and heirarchial messages
[ https://issues.apache.org/activemq/browse/SM-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38526 ] Guillaume Nodet commented on SM-834: We usually use sun conventions with 120 characters per line (or more) But nothing has been voted officially ... Will start a thread on dev list and create a wiki page Provide File Marshalling for CSV/variable, fixed and heirarchial messages - Key: SM-834 URL: https://issues.apache.org/activemq/browse/SM-834 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.2 Attachments: FileExtensionPropertyExpression.java, SimpleFlatFileMarshaler.java, zpv-contrib-servicemix-file.zip Provide file marshalling for file binding components similar to Parser Service Engine from Bostech ChainBuilder ESB (http://chainforge.net/chainbuilder/index.html) Sources as starting point attached. They show how to get CSV or fixed-length flat files on the bus in a generic way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Killing straggling processes
Just a general question for the unix readers out there... Can anyone think of an easy way to effectively kill straggling processes? For some of our automated builds, we use a system to distribute to remote agents. Some of that work involves starting up Geronimo, and other servers. Sometimes those servers don't stop properly, which messes up future execution of jobs sent to that agent. I'm trying to figure out a simple way, to allow those future executions to have a better chance of success by making sure there are no straggling processes left behind. Idea is also to just kill the children processes of the agent, but not anything else (like a su, or ssh for that user). Any sh-hackers out there know how to just get the list of a processes children (and children's children)... list as pids of course, so I can kill -9 them. My brain is fried... can't think of an easy way to do this... if anyone knows, please drop some knowledge :-) Thanks, --jason
[PROPOSAL] Coding standards
I propose the following coding standards (taken from the Geronimo web site) which are actually the most common in ServiceMix code base: http://cwiki.apache.org/SM/coding-standards.html Does anyone want to modify / add / change something ? -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Re: Killing straggling processes
disclaimerI did not write this and have no clue how it works :)/disclaimer We faced a similar situation in gump: http://issues.apache.org/jira/browse/GUMP-35 Leo Simons wrote this piece of code: http://svn.apache.org/viewvc/gump/branches/Gump3/pygump/python/gump/util/executor.py?view=markup thanks, dims On 2/15/07, Jason Dillon [EMAIL PROTECTED] wrote: Just a general question for the unix readers out there... Can anyone think of an easy way to effectively kill straggling processes? For some of our automated builds, we use a system to distribute to remote agents. Some of that work involves starting up Geronimo, and other servers. Sometimes those servers don't stop properly, which messes up future execution of jobs sent to that agent. I'm trying to figure out a simple way, to allow those future executions to have a better chance of success by making sure there are no straggling processes left behind. Idea is also to just kill the children processes of the agent, but not anything else (like a su, or ssh for that user). Any sh-hackers out there know how to just get the list of a processes children (and children's children)... list as pids of course, so I can kill -9 them. My brain is fried... can't think of an easy way to do this... if anyone knows, please drop some knowledge :-) Thanks, --jason -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: Error when configuring JMS through Geronimo console
Pls create a JIRA detailing the error. Cheers! Hernan Lasantha Ranaweera wrote: Hi Karthiga, I observed the same problem in the 1.2 beta release of Geronimo. But it works correctly in 2.x releases. I am not sure either what can we do for this kind of issue. Can somebody in the list please let us know whether we need to create a JIRA or not? It would be ideal if someone explain the future of 1.2 release. Thanks, Lasantha Karthiga Ratnam wrote: Hi All, I'm working on Configuring JMS document for v1.2 of Geronimo. I noticed an error when I try to deploy the JMS Resources or when I try to view its deployment plan. I tried on both Linux and Windows environments. Please find the error below: - 16:01:24,343 ERROR [AbstractHandler] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.create Configuration(JMXDeploymentManager.java:299) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(Ab stractHandler.java:471) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBef oreView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPageP ortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java :690) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java :170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java :68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java :82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java :617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java :170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 68) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication Context.java:633) at org.apache.geronimo.jetty.JettyWebAppContext.handle (JettyWebAppContex t.java:329) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.apache.geronimo.jetty.JettyWebAppContext.handle(JettyWebAppContex t.java:313) at org.mortbay.http.HttpServer.service (HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:820) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986) at org.mortbay.http.HttpConnection.handle (HttpConnection.java:837) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java: 245) at org.mortbay.util.ThreadedServer.handle(
Re: Conversion Tool
David... Here is the exception I get... Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml org.apache.geronimo.common.DeploymentException: Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:166) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:134) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$$FastClassByCGLIB$$cd80af20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$d2a1ea22.createModule(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:723) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:355) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:257) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$9cf6437.getDeploymentPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:114) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:595) I have placed the plan file and ear that I am using at the following location... http://people.apache.org/~cjblythe/m2_deploy/ Thanks... Chris On 2/14/07, David Blevins [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote: Dain and David... Took a swag at deploying Daytrader on Geronimo 2.0-M2... During deployment, it complained about the openejb-jar.xml file missing from the EJB module. I added the one you provided earlier in this chain, but for some reason it is still complaining that the openejb- jar.xml file is missing from the EJB module. I think Matt is probably running into the same issue... Does the or-mapping file also need to go in the ear/jar somewhere? Should this work on M2? Is there anything else that needs to go into the jar/ear? It really seems to me like we need way too many extra xml files to deploy this thing. You shouldn't need any files in the ear, i.e. passing the plan as a parameter on the command line should work as always. Post the message text and a stack trace (if there is one) and I'll see if I can't find what part of the code is confused. -David Thanks... Chris On 2/7/07, Dain Sundstrom [EMAIL PROTECTED] wrote:I just fix that allows nested openejb plans to work correctly. This was a big problem in the
Re: 505174 build failure
I am getting this on revision 507910 Any idea how to fix it? Thanks Rakesh On 2/9/07, Ted Kirby [EMAIL PROTECTED] wrote: Now, I get this failure: [INFO] Executing tasks [unzip] Expanding: C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee _5.ear into C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee_5-unpacked .ear [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error executing ant tasks Embedded error: Error while expanding C:\g\modules\geronimo-j2ee-builder\target\ test-ear-javaee_5.ear C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee_5.ear (The system cann ot find the file specified.) On 2/9/07, Ted Kirby [EMAIL PROTECTED] wrote: From head 505174, I was getting this error: Compiling 89 source files to C:\g\modules\geronimo-connector\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\g\modules\geronimo-connector\src\main\java\org\apache\geronimo\connector\outbound\GeronimoConnectionEventListener.java:[28,34] package org.apache.commons.logging does not exist C:\g\modules\geronimo-connector\src\main\java\org\apache\geronimo\connector\outbound\Gero I added the dependency to C:\g\modules\geronimo-connector\pom.xml, and was able to progress: dependency groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId /dependency
Re: Exceptions during deployment of testsupport EARs
On 2/14/07, David Jencks [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 8:01 PM, David Blevins wrote: snip Here's the test jar- http://people.apache.org/~prasad/test-ear-j2ee_1.4-2.0-SNAPSHOT.ear Source: http://svn.apache.org/viewvc/geronimo/server/trunk/testsupport/test-deployment-j2ee_1.4/ Ok, there's definitely something stuck somewhere in Geronimo-land now -- possibly caused by a failed ejb something-or-other. (very specific, huh :) Hey David J., do you have any ideas off the top of your head on under what circumstances we might consider an ear (not sure how to phrase) still deployed or unsuccessfully undeployed? I've run into this problem more times than I can count, but haven't investigated. All I know is that if you manually delete the directory from the g. repo you can then deploy. So I wonder we could do one of 2 things: 1. try harder to delete the directory on undeploy, maybe with more finally blocks 2. look harder to see if something's there on deploy, such as the config.ser file. If missing, it seems like we could rm the dir and deploy anyway. In this case, the files left behind in the repository\org\apache\geronimo\testsupport\test-ear-j2ee_1.4\2.0-SNAPSHOT\test-ear-j2ee_1.4-2.0-SNAPSHOT.ear directory are ejb.jar --- this file is bundled in the ear ejb-cmp2.jar -- this file gets generated by the conversion tool, I think There is such a big lock on these 2 files that the server has to be stopped before they can be deleted. Cheers Prasad But I haven't investigated thoroughly Would be great to get this fixed. thanks david jencks -David -David
[jira] Updated: (SM-834) Provide File Marshalling for CSV/variable, fixed and heirarchial messages
[ https://issues.apache.org/activemq/browse/SM-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juergen Mayrbaeurl updated SM-834: -- Attachment: servicemix-core.diff Patch for servicemix-core artifact containing contributed sources Provide File Marshalling for CSV/variable, fixed and heirarchial messages - Key: SM-834 URL: https://issues.apache.org/activemq/browse/SM-834 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Fix For: 3.2 Attachments: FileExtensionPropertyExpression.java, servicemix-core.diff, SimpleFlatFileMarshaler.java, zpv-contrib-servicemix-file.zip Provide file marshalling for file binding components similar to Parser Service Engine from Bostech ChainBuilder ESB (http://chainforge.net/chainbuilder/index.html) Sources as starting point attached. They show how to get CSV or fixed-length flat files on the bus in a generic way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GERONIMO-2816 patch
Yes, that results from the null pointer exception from ClassFinder when a class
file is not part of a package. Many of the class files in these examples are not
part of a package
Thanks,
Tim McConnell
David Blevins wrote:
On Feb 14, 2007, at 1:07 PM, Tim McConnell wrote:
... and not too surprising--it runs much faster now as well
I bet :)
Hey, so I'm running into an issue with the Jetty JSP Examples config
that seems to be realted to your patch. Did you see this or know what
it's about?
[INFO]
[INFO] Building Geronimo Configs :: JSP Examples Jetty
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target
[INFO] Deleting directory
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/classes
[INFO] Deleting directory
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/test-classes
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/classes/META-INF
[INFO] Copying 2 files to
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration:
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/plan/plan.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Exception encountered processing annotations for module:
org.apache.geronimo.configs/jsp-examples-jetty/2.0-SNAPSHOT/car
-David
Thanks,
Tim McConnell
David Blevins wrote:
On Feb 12, 2007, at 5:14 AM, Tim McConnell wrote:
Great, I'll work on these changes today. Thanks much
Reviewing the new patch! There are a few spec things that need to be
fixed but it looks pretty great overall.
-David
Re: [jira] [PROPOSAL] Coding standards
OK for me. Can anyone provide an Eclipse code formatting setup? Kind regards Juergen gnodet wrote: I propose the following coding standards (taken from the Geronimo web site) which are actually the most common in ServiceMix code base: http://cwiki.apache.org/SM/coding-standards.html Does anyone want to modify / add / change something ? -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/-PROPOSAL--Coding-standards-tf3233686s12049.html#a8987468 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: GERONIMO-2816 patch
Yep, I'm still failing here as well. Did the patch for ClassFinder not make it
into a new snapshot yet ??
Thanks,
Tim McConnell
David Blevins wrote:
On Feb 14, 2007, at 1:07 PM, Tim McConnell wrote:
... and not too surprising--it runs much faster now as well
I bet :)
Hey, so I'm running into an issue with the Jetty JSP Examples config
that seems to be realted to your patch. Did you see this or know what
it's about?
[INFO]
[INFO] Building Geronimo Configs :: JSP Examples Jetty
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target
[INFO] Deleting directory
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/classes
[INFO] Deleting directory
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/test-classes
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/classes/META-INF
[INFO] Copying 2 files to
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration:
/Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/target/plan/plan.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Exception encountered processing annotations for module:
org.apache.geronimo.configs/jsp-examples-jetty/2.0-SNAPSHOT/car
-David
Thanks,
Tim McConnell
David Blevins wrote:
On Feb 12, 2007, at 5:14 AM, Tim McConnell wrote:
Great, I'll work on these changes today. Thanks much
Reviewing the new patch! There are a few spec things that need to be
fixed but it looks pretty great overall.
-David
[jira] Commented: (SM-844) Using Shared Libraries from LW SUs
[ https://issues.apache.org/activemq/browse/SM-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38528 ] Juergen Mayrbaeurl commented on SM-844: --- Where in the source code is the SU class loading? Using Shared Libraries from LW SUs -- Key: SM-844 URL: https://issues.apache.org/activemq/browse/SM-844 Project: ServiceMix Issue Type: Improvement Components: servicemix-lwcontainer Affects Versions: 3.1 Environment: ServiceMix LW Container Reporter: Juergen Mayrbaeurl Fix For: 3.2 With ServiceMix 3.1 it isn't possible to use shared libraries in LW service units, because classloading (and configuration) and referencing shared libraries isn't supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Daytrader newbie
I am using java -jar server.jar. Does it really affects? Lasantha What command are you using to start the server? startup.sh|bat? or are you starting it some other way? On 2/15/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi Chris, Thanks for the information but still it is getting failed for me. Following are the steps I have followed the current situation. May be you might have some more insight on it than me. 1. Get the latest source code from DT trunk (revision 507843). 2. Build the source code using mvn clean install. 3. Start the G 1.2 beta server. 4. Create the derby database using createDB.sh. (I have given it in the DAYTRADER-35 patch would be greately appriciated if someone can review it too) 5. Deploy the daytrader-ear-2.0-SNAPSHOT.ear dtTrunk_geronimo12-beta-plan.xml using G console. 6. Getting following error :(. Thanks Again, Lasantha 15:01:14,658 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs /j2ee-corba-yoko/1.2-beta/car?ServiceModule=org.apache.geronimo.configs /j2ee-corba-yoko/1.2-beta/car,j2eeType=CORBANameService,name=NameServer java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_changed (Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange(PIManager.java :531) at org.apache.yoko.orb.OBPortableServer.POAManager_impl.activate (POAManager_impl.java:212) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.initialize( TransientNameService.java:129) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.run( TransientNameService.java:114) at org.apache.openejb.yoko.ORBConfigAdapter.createNameService( ORBConfigAdapter.java:167) at org.apache.openejb.yoko.ORBConfigAdapter$$FastClassByCGLIB$$c8ca5bf1.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke( FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke( GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java :820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke( RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept( ProxyMethodInterceptor.java:96) at org.apache.openejb.corba.security.config.ConfigAdapter$$EnhancerByCGLIB$$825d752c.createNameService (generated) at org.apache.openejb.corba.NameService.doStart(NameService.java:162) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance( GBeanInstance.java:984) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start( GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java :529) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart( GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget( GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running( GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent( BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300( BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent (BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start( GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive( GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive( GBeanInstance.java:543) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean( BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans (ConfigurationUtil.java:378) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start( KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration (SimpleConfigurationManager.java:527) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration (SimpleConfigurationManager.java:508) at
[DISCUSS] February Code drop (M3?)
We're getting to the end of February so its time to discuss what will drop and what we call it. On the original set of goals this next drop would be beta-1 but based on recent e-mail discussions as well as IRC and some experimentation I think the soup needs a few more items before we turn the flame to simmer. That said, I think that translates the February drop to be M3 rather than beta-1. We've improved deployment, made a lot of plumbing changes, etc so I'll solicit people's input for the highlights of this next Milestone (and if we al concur this is the right designation). If we're all tracking on this then I'd plan to follow the previous plan of branching at around 1700 next Wednesday (ET) of course not disrupting trunk and the progress that is being made. This would mean that we are settling into a monthly release in tune with release early and often (even if its not soup yet ;-) BEA recently announced that they have a developer release of WebLogic that has passed CTS so we're not alone out there in the world. I have to admit it feels pretty good to be on the forming wave rather than paddling to catch one that has already left. As far as assemblies are concerned I recommend using the same assemblies we did for last month as I don't think Axis or Cayenne are really integrated enough yet for people to try out. correct me if my understanding is not correct. Comments, and feedback welcome. Thanks Matt
Re: [jira] [PROPOSAL] Coding standards
Here is the one i use: http://cwiki.apache.org/confluence/download/attachments/45778/eclipse-formater.xml?version=1 It should be available from a link on the wiki page. On 2/15/07, Juergen Mayrbaeurl [EMAIL PROTECTED] wrote: OK for me. Can anyone provide an Eclipse code formatting setup? Kind regards Juergen gnodet wrote: I propose the following coding standards (taken from the Geronimo web site) which are actually the most common in ServiceMix code base: http://cwiki.apache.org/SM/coding-standards.html Does anyone want to modify / add / change something ? -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/-PROPOSAL--Coding-standards-tf3233686s12049.html#a8987468 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Re: 505174 build failure
And I'm seeing it on rev. 507970 as well. I don't see any recent changes in this space. The target doesn't contain the ear it is supposed to and after the failure we just have an empty directory with the ear name suffixed with -unpacked. Building within the module didn't help. Joe Rakesh Midha wrote: I am getting this on revision 507910 Any idea how to fix it? Thanks Rakesh On 2/9/07, *Ted Kirby* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Now, I get this failure: [INFO] Executing tasks [unzip] Expanding: C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee _5.ear into C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee_5-unpacked .ear [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error executing ant tasks Embedded error: Error while expanding C:\g\modules\geronimo-j2ee-builder\target\ test-ear-javaee_5.ear C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee_5.ear (The system cann ot find the file specified.) On 2/9/07, Ted Kirby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: From head 505174, I was getting this error: Compiling 89 source files to C:\g\modules\geronimo-connector\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\g\modules\geronimo-connector\src\main\java\org\apache\geronimo\connector\outbound\GeronimoConnectionEventListener.java:[28,34] package org.apache.commons.logging does not exist C:\g\modules\geronimo-connector\src\main\java\org\apache\geronimo\connector\outbound\Gero I added the dependency to C:\g\modules\geronimo-connector\pom.xml, and was able to progress: dependency groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId /dependency
Re: 505174 build failure
What's the failure? Does this use the dependency-maven-plugin (or now the maven-dependency-plugin)? I updated that last night (or was it this morning)... --jason On Feb 15, 2007, at 7:56 AM, Joe Bohn wrote: And I'm seeing it on rev. 507970 as well. I don't see any recent changes in this space. The target doesn't contain the ear it is supposed to and after the failure we just have an empty directory with the ear name suffixed with -unpacked. Building within the module didn't help. Joe Rakesh Midha wrote: I am getting this on revision 507910 Any idea how to fix it? Thanks Rakesh On 2/9/07, *Ted Kirby* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Now, I get this failure: [INFO] Executing tasks [unzip] Expanding: C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee _5.ear into C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee_5- unpacked .ear [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Error executing ant tasks Embedded error: Error while expanding C:\g\modules\geronimo-j2ee-builder\target\ test-ear-javaee_5.ear C:\g\modules\geronimo-j2ee-builder\target\test-ear- javaee_5.ear (The system cann ot find the file specified.) On 2/9/07, Ted Kirby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: From head 505174, I was getting this error: Compiling 89 source files to C:\g\modules\geronimo-connector\target\classes [INFO] - --- [ERROR] BUILD FAILURE [INFO] - --- [INFO] Compilation failure C:\g\modules\geronimo-connector\src\main\java\org\apache \geronimo\connector\outbound\GeronimoConnectionEventListener.java: [28,34] package org.apache.commons.logging does not exist C:\g\modules\geronimo-connector\src\main\java\org\apache \geronimo\connector\outbound\Gero I added the dependency to C:\g\modules\geronimo-connector\pom.xml, and was able to progress: dependency groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId /dependency
Re: Daytrader newbie
On Feb 15, 2007, at 7:44 AM, Lasantha Ranaweera wrote: I am using java -jar server.jar. Does it really affects? yes. If the application uses PortableRemoteObject.narrow rather than casts you MUST start geronimo specifying the endorsed dirs java -Djava.endorsed.dirs=lib/endorsed -jar bin/server.jar --long (well, the --long isn't necessary but does give more info if something goes wrong during startup) thanks david jencks Lasantha What command are you using to start the server? startup.sh|bat? or are you starting it some other way? On 2/15/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi Chris, Thanks for the information but still it is getting failed for me. Following are the steps I have followed the current situation. May be you might have some more insight on it than me. 1. Get the latest source code from DT trunk (revision 507843). 2. Build the source code using mvn clean install. 3. Start the G 1.2 beta server. 4. Create the derby database using createDB.sh. (I have given it in the DAYTRADER-35 patch would be greately appriciated if someone can review it too) 5. Deploy the daytrader-ear-2.0-SNAPSHOT.ear dtTrunk_geronimo12-beta-plan.xml using G console. 6. Getting following error :(. Thanks Again, Lasantha 15:01:14,658 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs /j2ee-corba-yoko/1.2-beta/car? ServiceModule=org.apache.geronimo.configs /j2ee-corba-yoko/1.2-beta/ car,j2eeType=CORBANameService,name=NameServer java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state _changed (Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange (PIManager.java :531) at org.apache.yoko.orb.OBPortableServer.POAManager_impl.activate (POAManager_impl.java:212) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.initializ e( TransientNameService.java:129) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.run( TransientNameService.java:114) at org.apache.openejb.yoko.ORBConfigAdapter.createNameService( ORBConfigAdapter.java:167) at org.apache.openejb.yoko.ORBConfigAdapter$$FastClassByCGLIB$ $c8ca5bf1.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java: 53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke( FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke( GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java :820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke( RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept( ProxyMethodInterceptor.java:96) at org.apache.openejb.corba.security.config.ConfigAdapter$ $EnhancerByCGLIB$$825d752c.createNameService (generated) at org.apache.openejb.corba.NameService.doStart(NameService.java:162) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance( GBeanInstance.java:984) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStar t( GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start( GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start (GBeanInstance.java :529) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart( GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget( GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running( GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEv ent( BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300( BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor $RawLifecycleBroadcaster.fireRunningEvent (BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStar t( GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start( GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive( GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive( GBeanInstance.java:543) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean( BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurati onGBeans (ConfigurationUtil.java:378) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(
Re: [DISCUSS] February Code drop (M3?)
On 2/15/07, Matt Hogstrom [EMAIL PROTECTED] wrote: We've improved deployment, made a lot of plumbing changes, etc so I'll solicit people's input for the highlights of this next Milestone (and if we al concur this is the right designation). If we're all tracking on this then I'd plan to follow the previous plan of branching at around 1700 next Wednesday (ET) of course not disrupting trunk and the progress that is being made. This would mean that we are settling into a monthly release in tune with release early and often (even if its not soup yet ;-) I think that even if we're not at the point where we would've liked to be it's as important to be feature-rich as released early and often. I'd propose that we stick to the next Wednesday as the vote day so the M3 would go to the public on February. /me going for lunch after Matt's delicious email ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Clustering Geronimo with Open Terracotta
I've added an article to the Geronimo wiki that describes how to cluster Geronimo HTTP Session web application data using the Open Terracotta project. http://cwiki.apache.org/GMOxDEV/clustering-geronimo-with-open-terracotta.html Feel free to get it a try.. Also, the clustering articles in the wiki were recently reorganized (Thanks Hernan) to be rooted on a common page.. http://cwiki.apache.org/GMOxDEV/clustering.html Though I suspect the Clustering - Initial Discussion article on this page is somewhat stale.. -Dave-
[jira] Assigned: (SM-807) Add jboss-service.xml to servicemix component so they can be properly deployed in jboss.
[ https://issues.apache.org/activemq/browse/SM-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SM-807: -- Assignee: Eric Dofonsou Add jboss-service.xml to servicemix component so they can be properly deployed in jboss. Key: SM-807 URL: https://issues.apache.org/activemq/browse/SM-807 Project: ServiceMix Issue Type: Improvement Components: servicemix-assembly, servicemix-audit, servicemix-bpe, servicemix-common, servicemix-components, servicemix-core, servicemix-drools, servicemix-eip, servicemix-file, servicemix-ftp, servicemix-http, servicemix-jbi, servicemix-jms, servicemix-jsr181, servicemix-lwcontainer, servicemix-quartz, servicemix-saxon, servicemix-sca, servicemix-script, servicemix-soap, servicemix-wsn2005 Affects Versions: 3.1 Environment: JBoss 4.0.5 GA Reporter: Eric Dofonsou Assigned To: Eric Dofonsou Fix For: 3.2 Original Estimate: 1 hour Remaining Estimate: 1 hour Right now there are no dependencies set on the servicemix components to ensure that they are loaded after the servicemix deployer. This can cause bugs when the component are deployed before the servicemix deployer, and thus are not handled by servicemix (and therefore not available). The fix for this is do include a dependence in the META-INF/jboss-service.xml of the component .zip file. here is the content of the file : - ?xml version=1.0 encoding=UTF-8? server dependsorg.servicemix:service=Deployer/depends /server - PS : The servicemix-http component already has a jboss-web.xml see issue (SM-584) file this should be deleted and the content of the new jboss-service.xml file should now be : - server class-loading loader-repository org.apache.commons.httpclient:loader=commons-httpclient-3.0.jar /loader-repository /class-loading dependsorg.servicemix:service=Deployer/depends /server --- Eric, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: XBean web site
On Feb 14, 2007, at 7:00 AM, Hernan Cunico wrote: As for the cwiki, we discussed earlier (well, long time ago) that the cwiki and the web site should not be the same, so we went very similar but not exactly the same. Some folks were concerned that we would end up focusing on the cwiki and leave aside the main web site. (pls don't make me find that thread ;-) ) Um... dig it up :-P I think that http://geronimo.apache.org *should* contain content which is rendered into static files from cwiki and copied into place (and/or added to svn I don't care) on people. Just look at what Cayenne has done: http://cayenne.apache.org/ And ActiveMQ: http://activemq.apache.org/home.html and OpenEJB: http://incubator.apache.org/openejb/ And there are probably more that I have not see yet... These are really functional, easy to maintain, easy to grow, easy to refactor, dang pretty to look at websites driven by Confluence + autoexport. I think we should do the same. --jason
Re: 505174 build failure
On Feb 15, 2007, at 11:07 AM, Jason Dillon wrote: What's the failure? Does this use the dependency-maven-plugin (or now the maven-dependency-plugin)? I updated that last night (or was it this morning)... I haven't hit the error, but I suspect that it's being caused by the dependency plugin change. It's shown up on both trunk and 1.2. --kevan
Re: XBean web site
Let's do it then! I'll start another thread for discussion Cheers! Hernan Jason Dillon wrote: On Feb 14, 2007, at 7:00 AM, Hernan Cunico wrote: As for the cwiki, we discussed earlier (well, long time ago) that the cwiki and the web site should not be the same, so we went very similar but not exactly the same. Some folks were concerned that we would end up focusing on the cwiki and leave aside the main web site. (pls don't make me find that thread ;-) ) Um... dig it up :-P I think that http://geronimo.apache.org *should* contain content which is rendered into static files from cwiki and copied into place (and/or added to svn I don't care) on people. Just look at what Cayenne has done: http://cayenne.apache.org/ And ActiveMQ: http://activemq.apache.org/home.html and OpenEJB: http://incubator.apache.org/openejb/ And there are probably more that I have not see yet... These are really functional, easy to maintain, easy to grow, easy to refactor, dang pretty to look at websites driven by Confluence + autoexport. I think we should do the same. --jason
Re: 505174 build failure
Here's the details: [DEBUG] getProperty(ns=null, name=project.build.directory, user=false) [unzip] Expanding: /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear into /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5-unpacked.ear [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error executing ant tasks Embedded error: Error while expanding /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear (No such file or directory) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing ant tasks at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:114) at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: Error while expanding /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:128) at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:92) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108) ... 19 more Caused by: java.io.FileNotFoundException: /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear (No such file or directory) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.init(RandomAccessFile.java:212) at org.apache.tools.zip.ZipFile.init(ZipFile.java:140) at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:117) ... 24 more Jason Dillon wrote: What's the failure? Does this use the dependency-maven-plugin (or now the maven-dependency-plugin)? I updated that last night (or was it this morning)... --jason On Feb 15, 2007, at 7:56 AM, Joe Bohn wrote: And I'm seeing it on rev. 507970 as well. I don't see any recent changes in this space. The target doesn't contain the ear it is supposed to and after the failure we just have an empty directory with the ear name suffixed with -unpacked. Building within the module didn't help. Joe Rakesh Midha wrote: I am getting this on revision 507910 Any idea how to fix it? Thanks Rakesh On 2/9/07, *Ted Kirby* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Now, I get this failure: [INFO] Executing tasks [unzip] Expanding: C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee _5.ear into C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee_5-unpacked .ear [INFO]
Re: 505174 build failure
Hmm.. Wonder why I haven't hit the error on 3 builds since last night ! All builds do a clean repo. Cheers Prasad On 2/15/07, Kevan Miller [EMAIL PROTECTED] wrote: On Feb 15, 2007, at 11:07 AM, Jason Dillon wrote: What's the failure? Does this use the dependency-maven-plugin (or now the maven-dependency-plugin)? I updated that last night (or was it this morning)... I haven't hit the error, but I suspect that it's being caused by the dependency plugin change. It's shown up on both trunk and 1.2. --kevan
Re: 505174 build failure
Yes, it does use the maven-dependency-plugin. Joe Joe Bohn wrote: Here's the details: [DEBUG] getProperty(ns=null, name=project.build.directory, user=false) [unzip] Expanding: /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear into /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5-unpacked.ear [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error executing ant tasks Embedded error: Error while expanding /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear (No such file or directory) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing ant tasks at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:114) at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: Error while expanding /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:128) at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:92) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108) ... 19 more Caused by: java.io.FileNotFoundException: /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear (No such file or directory) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.init(RandomAccessFile.java:212) at org.apache.tools.zip.ZipFile.init(ZipFile.java:140) at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:117) ... 24 more Jason Dillon wrote: What's the failure? Does this use the dependency-maven-plugin (or now the maven-dependency-plugin)? I updated that last night (or was it this morning)... --jason On Feb 15, 2007, at 7:56 AM, Joe Bohn wrote: And I'm seeing it on rev. 507970 as well. I don't see any recent changes in this space. The target doesn't contain the ear it is supposed to and after the failure we just have an empty directory with the ear name suffixed with -unpacked. Building within the module didn't help. Joe Rakesh Midha wrote: I am getting this on revision 507910 Any idea how to fix it? Thanks Rakesh On 2/9/07, *Ted Kirby* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Now, I get this failure: [INFO] Executing tasks [unzip] Expanding: C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee _5.ear into
Re: 505174 build failure
I've not see any problems building 1.2... have you? --jason On Feb 15, 2007, at 8:39 AM, Kevan Miller wrote: On Feb 15, 2007, at 11:07 AM, Jason Dillon wrote: What's the failure? Does this use the dependency-maven-plugin (or now the maven-dependency-plugin)? I updated that last night (or was it this morning)... I haven't hit the error, but I suspect that it's being caused by the dependency plugin change. It's shown up on both trunk and 1.2. --kevan
Re: 505174 build failure
I'm looking now... --jason On Feb 15, 2007, at 8:44 AM, Joe Bohn wrote: Here's the details: [DEBUG] getProperty(ns=null, name=project.build.directory, user=false) [unzip] Expanding: /home/tck/geronimo/trunk/modules/geronimo- j2ee-builder/target/test-ear-javaee_5.ear into /home/tck/geronimo/ trunk/modules/geronimo-j2ee-builder/target/test-ear-javaee_5- unpacked.ear [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Error executing ant tasks Embedded error: Error while expanding /home/tck/geronimo/trunk/ modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear /home/tck/geronimo/trunk/modules/geronimo-j2ee-builder/target/test- ear-javaee_5.ear (No such file or directory) [INFO] -- -- [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif ecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand leFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment s(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: 115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing ant tasks at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks (AbstractAntMojo.java:114) at org.apache.maven.plugin.antrun.AntRunMojo.execute (AntRunMojo.java:83) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) ... 16 more Caused by: Error while expanding /home/tck/geronimo/trunk/modules/ geronimo-j2ee-builder/target/test-ear-javaee_5.ear at org.apache.tools.ant.taskdefs.Expand.expandFile (Expand.java:128) at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java: 92) at org.apache.tools.ant.UnknownElement.execute (UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks (AbstractAntMojo.java:108) ... 19 more Caused by: java.io.FileNotFoundException: /home/tck/geronimo/trunk/ modules/geronimo-j2ee-builder/target/test-ear-javaee_5.ear (No such file or directory) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.init(RandomAccessFile.java:212) at org.apache.tools.zip.ZipFile.init(ZipFile.java:140) at org.apache.tools.ant.taskdefs.Expand.expandFile (Expand.java:117) ... 24 more Jason Dillon wrote: What's the failure? Does this use the dependency-maven-plugin (or now the maven-dependency-plugin)? I updated that last night (or was it this morning)... --jason On Feb 15, 2007, at 7:56 AM, Joe Bohn wrote: And I'm seeing it on rev. 507970 as well. I don't see any recent changes in this space. The target doesn't contain the ear it is supposed to and after the failure we just have an empty directory with the ear name suffixed with -unpacked. Building within the module didn't help. Joe Rakesh Midha wrote: I am getting this on revision 507910 Any idea how to fix it? Thanks Rakesh On 2/9/07, *Ted Kirby* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Now, I get this failure: [INFO] Executing tasks [unzip] Expanding: C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee
Re: 505174 build failure
Oh, I missed that... Is he using Maven 2.0.4 still by chance? I ran a build on gbuild.org just now for trunk and its fine, been running 1.2 builds all night after the change just fine... only thing is I'm using maven 2.0.5 now. Anyways, looking into it more... --jason On Feb 15, 2007, at 8:53 AM, Kevan Miller wrote: On Feb 15, 2007, at 11:47 AM, Jason Dillon wrote: I've not see any problems building 1.2... have you? Rick said he ran a 1.2 build and it failed in the same way... --kevan
Re: 505174 build failure
It looks like its a problem with Maven 2.0.4... builds of modules/ geronimo-j2ee-builder fail with 2.0.4, work fine with 2.0.5. Time to upgrade folks ;-) Its relatively painless (download, unzip, done)... ;-) --jason On Feb 15, 2007, at 8:53 AM, Kevan Miller wrote: On Feb 15, 2007, at 11:47 AM, Jason Dillon wrote: I've not see any problems building 1.2... have you? Rick said he ran a 1.2 build and it failed in the same way... --kevan
[Discussion] Geronimo web site update
Folks, after lots of separated discussions on different threads it is clear the spirit for moving the authoring of our web site over Confluence. Let's bring to this thread all the ideas and discussion. Proposal: The idea is to use Confluence as the authoring tool for Geronimo's web site. To achieve this we will use the autoexport plugin already installed and in use on the cwiki.apache.org. With the autoexport plugin we can customize the generated HTML look and feel by using templates. The current POC can be viewed at http://cwiki.apache.org/GMOxSITE (thx Jason D.) Some suggestions (mine ;-) ) - Avoid JIRA references/direct imports, if JIRA is down or running slow it will affect the main web site. - Remove edit/print/export links from the generated site. Only Geronimo committers will have edit access - Update the template LF. Why not? It is a good opportunity to do it !!! - Need to define how to integrate the other subprojects web sites (consider confluence spaces too). - pls chime in!!! I volunteer to start updating the content (matching with what we already have on the live site), unless somebody else wants to go it! I will also look at some alternative templates. Cheers! Hernan
Re: 505174 build failure
Upgrading to maven 2.0.5 fixed the problem for me. Thanks Jason! :-) Joe Jason Dillon wrote: It looks like its a problem with Maven 2.0.4... builds of modules/geronimo-j2ee-builder fail with 2.0.4, work fine with 2.0.5. Time to upgrade folks ;-) Its relatively painless (download, unzip, done)... ;-) --jason On Feb 15, 2007, at 8:53 AM, Kevan Miller wrote: On Feb 15, 2007, at 11:47 AM, Jason Dillon wrote: I've not see any problems building 1.2... have you? Rick said he ran a 1.2 build and it failed in the same way... --kevan
Re: [Discussion] Geronimo web site update
Hernan, The geronimo web site currently serves up the plugin catalogs at http://geronimo.apache.org/plugins. Will migrating the web site to confluence affect our ability to host the plugin catalogs at that location? See this thread for background discussion on how this location came about: http://tinyurl.com/2yewg7 Also, the geronimo.apache.org site currently provides a redirect service for certain URLs present in the welcome app and the admin console. See site/trunk/docs/redirects/.htaccess. Will moving the site to confluence affect our ability to service these redirects? In general I'm wondering how moving the site to confluence will affect our ability to serve up non-wiki resources from geronimo.apache.org. Best wishes, Paul On 2/15/07, Hernan Cunico [EMAIL PROTECTED] wrote: Folks, after lots of separated discussions on different threads it is clear the spirit for moving the authoring of our web site over Confluence. Let's bring to this thread all the ideas and discussion. Proposal: The idea is to use Confluence as the authoring tool for Geronimo's web site. To achieve this we will use the autoexport plugin already installed and in use on the cwiki.apache.org. With the autoexport plugin we can customize the generated HTML look and feel by using templates. The current POC can be viewed at http://cwiki.apache.org/GMOxSITE (thx Jason D.) Some suggestions (mine ;-) ) - Avoid JIRA references/direct imports, if JIRA is down or running slow it will affect the main web site. - Remove edit/print/export links from the generated site. Only Geronimo committers will have edit access - Update the template LF. Why not? It is a good opportunity to do it !!! - Need to define how to integrate the other subprojects web sites (consider confluence spaces too). - pls chime in!!! I volunteer to start updating the content (matching with what we already have on the live site), unless somebody else wants to go it! I will also look at some alternative templates. Cheers! Hernan
Re: [Discussion] Geronimo web site update
On Feb 15, 2007, at 9:17 AM, Hernan Cunico wrote: Folks, after lots of separated discussions on different threads it is clear the spirit for moving the authoring of our web site over Confluence. Let's bring to this thread all the ideas and discussion. Proposal: The idea is to use Confluence as the authoring tool for Geronimo's web site. To achieve this we will use the autoexport plugin already installed and in use on the cwiki.apache.org. With the autoexport plugin we can customize the generated HTML look and feel by using templates. The current POC can be viewed at http://cwiki.apache.org/GMOxSITE (thx Jason D.) Some suggestions (mine ;-) ) - Avoid JIRA references/direct imports, if JIRA is down or running slow it will affect the main web site. Eh... maybe... though JIRA should not be down or slow. These are also static pages, which only pull images off of the JIRA webapp, but we could remove the icon from the rendering. I personally think its useful to show some JIRA activity on some page on the website. Shows that we are still moving even if the website content isn't. - Remove edit/print/export links from the generated site. Only Geronimo committers will have edit access Fine w/me. - Update the template LF. Why not? It is a good opportunity to do it !!! Ya, probably some changes to be made... I like the Cayenne site a lot... clean, simple... nice popup menus. - Need to define how to integrate the other subprojects web sites (consider confluence spaces too). Aye, we need a basic theme that works for the main site, documentation sites and sub-project sites. - pls chime in!!! I volunteer to start updating the content (matching with what we already have on the live site), unless somebody else wants to go it! I will also look at some alternative templates. I really would like to see this happen... so I can lend a hand. --jason
Re: [Discussion] Geronimo web site update
On Feb 15, 2007, at 9:31 AM, Paul McMahan wrote: Hernan, The geronimo web site currently serves up the plugin catalogs at http://geronimo.apache.org/plugins. Will migrating the web site to confluence affect our ability to host the plugin catalogs at that location? Nope. We can still manage this the way we do now. See this thread for background discussion on how this location came about: http://tinyurl.com/2yewg7 Also, the geronimo.apache.org site currently provides a redirect service for certain URLs present in the welcome app and the admin console. See site/trunk/docs/redirects/.htaccess. Will moving the site to confluence affect our ability to service these redirects? Nope. From the httpd's perspective its exactly the same. The difference is that the content will come from a rsync off of another directory on people, which we can of course tailor to make sure that bits we still want to keep in svn don't get clobbered. In general I'm wondering how moving the site to confluence will affect our ability to serve up non-wiki resources from geronimo.apache.org. Should have no impact. --jason
[jira] Assigned: (SM-537) Define several endpoint implementations instead of having only one
[ https://issues.apache.org/activemq/browse/SM-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SM-537: -- Assignee: Guillaume Nodet Define several endpoint implementations instead of having only one -- Key: SM-537 URL: https://issues.apache.org/activemq/browse/SM-537 Project: ServiceMix Issue Type: Improvement Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Guillaume Nodet It would be much more easy to know which kind of endpoint is it and which attributes are mandatory. Having more specialized classes will also be easier to maintain. http:consumer ... http:provider ... jms:consumer .. jms:provider jms:jca-consumer ... jms:jca-provider .. jms:amq-consumer jms:amq-provider .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (SM-537) Define several endpoint implementations instead of having only one
[ https://issues.apache.org/activemq/browse/SM-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SM-537 started by Guillaume Nodet. Define several endpoint implementations instead of having only one -- Key: SM-537 URL: https://issues.apache.org/activemq/browse/SM-537 Project: ServiceMix Issue Type: Improvement Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Guillaume Nodet It would be much more easy to know which kind of endpoint is it and which attributes are mandatory. Having more specialized classes will also be easier to maintain. http:consumer ... http:provider ... jms:consumer .. jms:provider jms:jca-consumer ... jms:jca-provider .. jms:amq-consumer jms:amq-provider .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-510) The servicemix-jms component should support the ability to set jms message properties
[ https://issues.apache.org/activemq/browse/SM-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38531 ] Guillaume Nodet commented on SM-510: Done, as part of endpoint refactoring. Author: gnodet Date: Thu Feb 15 08:37:20 2007 New Revision: 507994 URL: http://svn.apache.org/viewvc?view=revrev=507994 Log: SM-537, SM-724, SM-510: add several new jms endpoints that use marshalers The servicemix-jms component should support the ability to set jms message properties - Key: SM-510 URL: https://issues.apache.org/activemq/browse/SM-510 Project: ServiceMix Issue Type: Improvement Components: servicemix-jms Affects Versions: 3.0.1 Reporter: Bruce Snyder Assigned To: Guillaume Nodet The servicemix-jms component should offer the ability to set JMS message properties. This will allow a normalized message to be created that includes an expiration, a CorrelationID, a priority, etc. or even any of the JMSX properties, all of which will be marshalled to the actual JMS message that's sent by the servicemix-jms component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SM-724) able to write marshaller for JBI components
[ https://issues.apache.org/activemq/browse/SM-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SM-724: -- Assignee: Guillaume Nodet able to write marshaller for JBI components --- Key: SM-724 URL: https://issues.apache.org/activemq/browse/SM-724 Project: ServiceMix Issue Type: New Feature Components: servicemix-http, servicemix-jms Reporter: Alper Sogukpinar Assigned To: Guillaume Nodet Fix For: 3.2 I think it would be nice if we could write marshaller for JBI components like it is written lightweight components. If marshaller can be written for JBI components it may keep us from writing custom endpoints or JBI components to make small improvements on the available components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (SM-724) able to write marshaller for JBI components
[ https://issues.apache.org/activemq/browse/SM-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SM-724 started by Guillaume Nodet. able to write marshaller for JBI components --- Key: SM-724 URL: https://issues.apache.org/activemq/browse/SM-724 Project: ServiceMix Issue Type: New Feature Components: servicemix-http, servicemix-jms Reporter: Alper Sogukpinar Assigned To: Guillaume Nodet Fix For: 3.2 I think it would be nice if we could write marshaller for JBI components like it is written lightweight components. If marshaller can be written for JBI components it may keep us from writing custom endpoints or JBI components to make small improvements on the available components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-724) able to write marshaller for JBI components
[ https://issues.apache.org/activemq/browse/SM-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38532 ] Guillaume Nodet commented on SM-724: Done for jms as part of the endpoint refactoring. Author: gnodet Date: Thu Feb 15 08:37:20 2007 New Revision: 507994 URL: http://svn.apache.org/viewvc?view=revrev=507994 Log: SM-537, SM-724, SM-510: add several new jms endpoints that use marshalers able to write marshaller for JBI components --- Key: SM-724 URL: https://issues.apache.org/activemq/browse/SM-724 Project: ServiceMix Issue Type: New Feature Components: servicemix-http, servicemix-jms Reporter: Alper Sogukpinar Assigned To: Guillaume Nodet Fix For: 3.2 I think it would be nice if we could write marshaller for JBI components like it is written lightweight components. If marshaller can be written for JBI components it may keep us from writing custom endpoints or JBI components to make small improvements on the available components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Default constructor for JBIContainer changes log level?
Hi Philipp ! Can you point where this happen ? I don't recall any log4j direct calls in servicemix but the reconfiguration that happen in org.apache.servicemix.jbi.logging.LoggingService. On 2/15/07, Rossmanith, Philipp [EMAIL PROTECTED] wrote: Hi, I'm currently working on a DefaultBroker subclass (see http://www.nabble.com/Security-and-authorization-requirements-on-Request Broker-tf3135938s12049.html) in which I can add handlers processing MessageExchange instances within the sendExchangePacket method. One of them is a log4j-based logger with which I can log MessageExchange properties etc. I did a unit test based on the test cases for the SecuredBroker. After some investigations I found out that the call to the default constructor of the JBIContainer changes the level of the root logger to ERROR.*) Is this a desired behaviour, and how can I turn it off? Thanks in advance, Ciao, Philipp Rossmanith *) I observed the same behaviour in the original test case after adding a log4j Logger. This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Re: Handling Large JBI message attachmen
You should be able to keep streams all the way, so it is not a real problem. On 2/15/07, Atul Gupta [EMAIL PROTECTED] wrote: Hi, I use File Binding component to read a xml file from a specific directory and then create a normalized message using this file's content and send the Message to another http Binding component . This http binding component calls a external web service, which basically reads the document and parse it and save its content into database. I am a bit worried in terms of size that can be supported by JBI messages because in my case , XML file could be upto 3 GB. Please advice Thanks. Atul -- View this message in context: http://www.nabble.com/Handling-Large-JBI-message---attachment-tf3230926s12049.html#a8976948 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
RE: Default constructor for JBIContainer changes log level?
Hi Guillaume, org.apache.servicemix.jbi.security.SecuredBrokerTest, line 63: jbi = new JBIContainer(); I created a Logger before this call and did a watch on it. Ciao, Philipp Rossmanith ITC Analyst Systems Integration T-Systems ITC Iberia S.A.U. Edifici 22@ Sancho d'Àvila 110-130 08018 Barcelona Office: + 34 93 501 56 22 Main: + 34 93 501 50 00 Fax:+ 34 93 501 52 41 Email: [EMAIL PROTECTED] Internet: www.t-systems.com -Mensaje original- De: Guillaume Nodet [mailto:[EMAIL PROTECTED] Enviado el: jueves, 15 de febrero de 2007 19:38 Para: servicemix-dev@geronimo.apache.org Asunto: Re: Default constructor for JBIContainer changes log level? Hi Philipp ! Can you point where this happen ? I don't recall any log4j direct calls in servicemix but the reconfiguration that happen in org.apache.servicemix.jbi.logging.LoggingService. On 2/15/07, Rossmanith, Philipp [EMAIL PROTECTED] wrote: Hi, I'm currently working on a DefaultBroker subclass (see http://www.nabble.com/Security-and-authorization-requirements-on-Request Broker-tf3135938s12049.html) in which I can add handlers processing MessageExchange instances within the sendExchangePacket method. One of them is a log4j-based logger with which I can log MessageExchange properties etc. I did a unit test based on the test cases for the SecuredBroker. After some investigations I found out that the call to the default constructor of the JBIContainer changes the level of the root logger to ERROR.*) Is this a desired behaviour, and how can I turn it off? Thanks in advance, Ciao, Philipp Rossmanith *) I observed the same behaviour in the original test case after adding a log4j Logger. This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/ This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
RE: Default constructor for JBIContainer changes log level?
P.s. JBIContainer doesn't seem to use org.apache.log4j, but makes calls to org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory: private static final Log log = LogFactory.getLog(JBIContainer.class); ... as well as to java.util.logging.Logger: public Logger getLogger(String suffix, String resourceBundleName) throws MissingResourceException, JBIException Ciao, Philipp Rossmanith This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
Re: Default constructor for JBIContainer changes log level?
I recall some geronimo jars to do some weird things with the loggers. Make sure you don't have geronimo-kernel in your classpath. AFAIK, nothing change the log level in servicemix code. On 2/15/07, Rossmanith, Philipp [EMAIL PROTECTED] wrote: Hi Guillaume, org.apache.servicemix.jbi.security.SecuredBrokerTest, line 63: jbi = new JBIContainer(); I created a Logger before this call and did a watch on it. Ciao, Philipp Rossmanith ITC Analyst Systems Integration T-Systems ITC Iberia S.A.U. Edifici 22@ Sancho d'Àvila 110-130 08018 Barcelona Office: + 34 93 501 56 22 Main: + 34 93 501 50 00 Fax:+ 34 93 501 52 41 Email: [EMAIL PROTECTED] Internet: www.t-systems.com -Mensaje original- De: Guillaume Nodet [mailto:[EMAIL PROTECTED] Enviado el: jueves, 15 de febrero de 2007 19:38 Para: servicemix-dev@geronimo.apache.org Asunto: Re: Default constructor for JBIContainer changes log level? Hi Philipp ! Can you point where this happen ? I don't recall any log4j direct calls in servicemix but the reconfiguration that happen in org.apache.servicemix.jbi.logging.LoggingService. On 2/15/07, Rossmanith, Philipp [EMAIL PROTECTED] wrote: Hi, I'm currently working on a DefaultBroker subclass (see http://www.nabble.com/Security-and-authorization-requirements-on-Request Broker-tf3135938s12049.html) in which I can add handlers processing MessageExchange instances within the sendExchangePacket method. One of them is a log4j-based logger with which I can log MessageExchange properties etc. I did a unit test based on the test cases for the SecuredBroker. After some investigations I found out that the call to the default constructor of the JBIContainer changes the level of the root logger to ERROR.*) Is this a desired behaviour, and how can I turn it off? Thanks in advance, Ciao, Philipp Rossmanith *) I observed the same behaviour in the original test case after adding a log4j Logger. This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/ This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Re: Default constructor for JBIContainer changes log level?
Sure, commons-logging is configured. Which in turns, starts log4j if included in the classpath. By default, log4j will load a log4j.properties file ... And you're right. It seems that o.a.s.id.IdGenerator calls the java.util.logging package. This is the only call afaik and it should be removed. Can you raise a JIRA for that ? On 2/15/07, Rossmanith, Philipp [EMAIL PROTECTED] wrote: P.s. JBIContainer doesn't seem to use org.apache.log4j, but makes calls to org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory: private static final Log log = LogFactory.getLog(JBIContainer.class); ... as well as to java.util.logging.Logger: public Logger getLogger(String suffix, String resourceBundleName) throws MissingResourceException, JBIException Ciao, Philipp Rossmanith This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
[jira] Created: (GERONIMO-2839) 1.2 and 2.0 geronimo naming schemas differ in what to call a persistence-unit-ref
1.2 and 2.0 geronimo naming schemas differ in what to call a persistence-unit-ref - Key: GERONIMO-2839 URL: https://issues.apache.org/jira/browse/GERONIMO-2839 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 the 1.2 geronimo-naming-1.2.xsd schema still has a mistaken entity-manager-factor-ref element that should be persistence-unit-ref. It's already fixed in trunk but not in 1.2. Since 1.2 isn't released yet it's not too late to fix in 1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GERONIMO-2816 patch
On Feb 15, 2007, at 7:34 AM, Tim McConnell wrote:
Yep, I'm still failing here as well. Did the patch for ClassFinder
not make it into a new snapshot yet ??
Oops, doing it now.
-David
Thanks,
Tim McConnell
David Blevins wrote:
On Feb 14, 2007, at 1:07 PM, Tim McConnell wrote:
... and not too surprising--it runs much faster now as well
I bet :)
Hey, so I'm running into an issue with the Jetty JSP Examples
config that seems to be realted to your patch. Did you see this
or know what it's about?
[INFO]
-
--- [INFO] Building Geronimo Configs :: JSP Examples Jetty
[INFO]task-segment: [clean, install]
[INFO]
-
--- [INFO] [clean:clean]
[INFO] Deleting directory /Users/dblevins/work/geronimo-trunk/
configs/jsp-examples-jetty/target
[INFO] Deleting directory /Users/dblevins/work/geronimo-trunk/
configs/jsp-examples-jetty/target/classes [INFO] Deleting
directory /Users/dblevins/work/geronimo-trunk/configs/jsp-examples-
jetty/target/test-classes [INFO] [tools:require-java-version
{execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /Users/dblevins/work/geronimo-trunk/configs/
jsp-examples-jetty/target/classes/META-INF [INFO] Copying 2 files
to /Users/dblevins/work/geronimo-trunk/configs/jsp-examples-jetty/
target/classes/META-INF [INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /Users/dblevins/work/geronimo-trunk/configs/jsp-
examples-jetty/target/plan/plan.xml [INFO] [car:package]
[INFO] Packaging module configuration: /Users/dblevins/work/
geronimo-trunk/configs/jsp-examples-jetty/target/plan/plan.xml
[INFO]
-
---
[ERROR] BUILD ERROR
[INFO]
-
---
[INFO] Exception encountered processing annotations for module:
org.apache.geronimo.configs/jsp-examples-jetty/2.0-SNAPSHOT/car
-David
Thanks,
Tim McConnell
David Blevins wrote:
On Feb 12, 2007, at 5:14 AM, Tim McConnell wrote:
Great, I'll work on these changes today. Thanks much
Reviewing the new patch! There are a few spec things that need
to be fixed but it looks pretty great overall.
-David
Re: [DISCUSS] February Code drop (M3?)
M3, alpha, beta, stable... What's in a name ? Let's continue to keep working in it diligently as we have been doing and keep releasing it with an assured regularity. M3 is fine. Cheers Prasad On 2/15/07, Matt Hogstrom [EMAIL PROTECTED] wrote: We're getting to the end of February so its time to discuss what will drop and what we call it. On the original set of goals this next drop would be beta-1 but based on recent e-mail discussions as well as IRC and some experimentation I think the soup needs a few more items before we turn the flame to simmer. That said, I think that translates the February drop to be M3 rather than beta-1. We've improved deployment, made a lot of plumbing changes, etc so I'll solicit people's input for the highlights of this next Milestone (and if we al concur this is the right designation). If we're all tracking on this then I'd plan to follow the previous plan of branching at around 1700 next Wednesday (ET) of course not disrupting trunk and the progress that is being made. This would mean that we are settling into a monthly release in tune with release early and often (even if its not soup yet ;-) BEA recently announced that they have a developer release of WebLogic that has passed CTS so we're not alone out there in the world. I have to admit it feels pretty good to be on the forming wave rather than paddling to catch one that has already left. As far as assemblies are concerned I recommend using the same assemblies we did for last month as I don't think Axis or Cayenne are really integrated enough yet for people to try out. correct me if my understanding is not correct. Comments, and feedback welcome. Thanks Matt
Re: [DISCUSS] February Code drop (M3?)
I agree it would be great to get another release out. I also agree we should stick with milestone or alpha releases until there's more goodies in the gumbo. Best wishes, Paul On 2/15/07, Matt Hogstrom [EMAIL PROTECTED] wrote: We're getting to the end of February so its time to discuss what will drop and what we call it. On the original set of goals this next drop would be beta-1 but based on recent e-mail discussions as well as IRC and some experimentation I think the soup needs a few more items before we turn the flame to simmer. That said, I think that translates the February drop to be M3 rather than beta-1. We've improved deployment, made a lot of plumbing changes, etc so I'll solicit people's input for the highlights of this next Milestone (and if we al concur this is the right designation). If we're all tracking on this then I'd plan to follow the previous plan of branching at around 1700 next Wednesday (ET) of course not disrupting trunk and the progress that is being made. This would mean that we are settling into a monthly release in tune with release early and often (even if its not soup yet ;-) BEA recently announced that they have a developer release of WebLogic that has passed CTS so we're not alone out there in the world. I have to admit it feels pretty good to be on the forming wave rather than paddling to catch one that has already left. As far as assemblies are concerned I recommend using the same assemblies we did for last month as I don't think Axis or Cayenne are really integrated enough yet for people to try out. correct me if my understanding is not correct. Comments, and feedback welcome. Thanks Matt
[jira] Closed: (GERONIMO-2839) 1.2 and 2.0 geronimo naming schemas differ in what to call a persistence-unit-ref
[ https://issues.apache.org/jira/browse/GERONIMO-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2839. -- Resolution: Fixed Fixed in rev 508188. Reopen and bug me if there are any problems. I tested it with a suitably back-ported copy of the jpa integration test app from trunk. 1.2 and 2.0 geronimo naming schemas differ in what to call a persistence-unit-ref - Key: GERONIMO-2839 URL: https://issues.apache.org/jira/browse/GERONIMO-2839 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 the 1.2 geronimo-naming-1.2.xsd schema still has a mistaken entity-manager-factor-ref element that should be persistence-unit-ref. It's already fixed in trunk but not in 1.2. Since 1.2 isn't released yet it's not too late to fix in 1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] February Code drop (M3?)
M3 sounds better to me than Beta-1. I also like the idea of release early release, let's keep up the drum beat from the prev milestones releasing once a month. Cheers! Hernan Matt Hogstrom wrote: We're getting to the end of February so its time to discuss what will drop and what we call it. On the original set of goals this next drop would be beta-1 but based on recent e-mail discussions as well as IRC and some experimentation I think the soup needs a few more items before we turn the flame to simmer. That said, I think that translates the February drop to be M3 rather than beta-1. We've improved deployment, made a lot of plumbing changes, etc so I'll solicit people's input for the highlights of this next Milestone (and if we al concur this is the right designation). If we're all tracking on this then I'd plan to follow the previous plan of branching at around 1700 next Wednesday (ET) of course not disrupting trunk and the progress that is being made. This would mean that we are settling into a monthly release in tune with release early and often (even if its not soup yet ;-) BEA recently announced that they have a developer release of WebLogic that has passed CTS so we're not alone out there in the world. I have to admit it feels pretty good to be on the forming wave rather than paddling to catch one that has already left. As far as assemblies are concerned I recommend using the same assemblies we did for last month as I don't think Axis or Cayenne are really integrated enough yet for people to try out. correct me if my understanding is not correct. Comments, and feedback welcome. Thanks Matt
Trunk build hanging
When building trunk I'm getting a hang in the configs. I've run this
on two different computers (both macs), and both hang here
[INFO]
[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /Users/dain/work/geronimo/server/trunk/configs/
persistence-jpa10-deployer/target/classes/META-INF
[INFO] Copying 2 files to /Users/dain/work/geronimo/server/trunk/
configs/persistence-jpa10-deployer/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /Users/dain/work/geronimo/server/trunk/configs/
persistence-jpa10-deployer/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration: /Users/dain/work/geronimo/
server/trunk/configs/persistence-jpa10-deployer/target/plan/plan.xml
And when I send SIG_QUIT, it is hung here:
main prio=5 tid=0x00501430 nid=0x1804a00 runnable
[0xb07fe000..0xb08000dc]
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2365)
at java.lang.Class.getDeclaredMethod(Class.java:1907)
at java.io.ObjectStreamClass.getPrivateMethod
(ObjectStreamClass.java:1327)
at java.io.ObjectStreamClass.access$1600
(ObjectStreamClass.java:47)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:394)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.init(ObjectStreamClass.java:373)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:268)
at java.io.ObjectStreamClass.initNonProxy
(ObjectStreamClass.java:504)
at java.io.ObjectInputStream.readNonProxyDesc
(ObjectInputStream.java:1546)
at java.io.ObjectInputStream.readClassDesc
(ObjectInputStream.java:1460)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1693)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.defaultReadFields
(ObjectInputStream.java:1912)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1836)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1713)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readObject
(ObjectInputStream.java:339)
at org.apache.geronimo.gbean.GBeanData
$V0Externalizable.readExternal(GBeanData.java:285)
at org.apache.geronimo.gbean.GBeanData.readExternal
(GBeanData.java:252)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans
(SerializedGBeanState.java:111)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans
(SerializedGBeanState.java:65)
at
org.apache.geronimo.kernel.config.ConfigurationData.getGBeans
(ConfigurationData.java:171)
at org.apache.geronimo.kernel.config.Configuration.init
(Configuration.java:279)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance
(Constructor.java:494)
Is anyone else having this problem?
-dain
Re: Trunk build hanging
Did you increase your memory allocation as per Jenck's note ?
Cheers
Prasad
On 2/15/07, Dain Sundstrom [EMAIL PROTECTED] wrote:
When building trunk I'm getting a hang in the configs. I've run this
on two different computers (both macs), and both hang here
[INFO]
[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /Users/dain/work/geronimo/server/trunk/configs/
persistence-jpa10-deployer/target/classes/META-INF
[INFO] Copying 2 files to /Users/dain/work/geronimo/server/trunk/
configs/persistence-jpa10-deployer/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /Users/dain/work/geronimo/server/trunk/configs/
persistence-jpa10-deployer/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration: /Users/dain/work/geronimo/
server/trunk/configs/persistence-jpa10-deployer/target/plan/plan.xml
And when I send SIG_QUIT, it is hung here:
main prio=5 tid=0x00501430 nid=0x1804a00 runnable
[0xb07fe000..0xb08000dc]
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2365)
at java.lang.Class.getDeclaredMethod(Class.java:1907)
at java.io.ObjectStreamClass.getPrivateMethod
(ObjectStreamClass.java:1327)
at java.io.ObjectStreamClass.access$1600
(ObjectStreamClass.java:47)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:394)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.init(ObjectStreamClass.java:373)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:268)
at java.io.ObjectStreamClass.initNonProxy
(ObjectStreamClass.java:504)
at java.io.ObjectInputStream.readNonProxyDesc
(ObjectInputStream.java:1546)
at java.io.ObjectInputStream.readClassDesc
(ObjectInputStream.java:1460)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1693)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.defaultReadFields
(ObjectInputStream.java:1912)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1836)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1713)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readObject
(ObjectInputStream.java:339)
at org.apache.geronimo.gbean.GBeanData
$V0Externalizable.readExternal(GBeanData.java:285)
at org.apache.geronimo.gbean.GBeanData.readExternal
(GBeanData.java:252)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans
(SerializedGBeanState.java:111)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans
(SerializedGBeanState.java:65)
at
org.apache.geronimo.kernel.config.ConfigurationData.getGBeans
(ConfigurationData.java:171)
at org.apache.geronimo.kernel.config.Configuration.init
(Configuration.java:279)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance
(Constructor.java:494)
Is anyone else having this problem?
-dain
Re: Trunk build hanging
http://www.nabble.com/Building-will-probably-require--XX%3AMaxPermSize%3D128m-tf3219541.html#a8943995
On 2/15/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
Did you increase your memory allocation as per Jenck's note ?
Cheers
Prasad
On 2/15/07, Dain Sundstrom [EMAIL PROTECTED] wrote:
When building trunk I'm getting a hang in the configs. I've run this
on two different computers (both macs), and both hang here
[INFO]
[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /Users/dain/work/geronimo/server/trunk/configs/
persistence-jpa10-deployer/target/classes/META-INF
[INFO] Copying 2 files to /Users/dain/work/geronimo/server/trunk/
configs/persistence-jpa10-deployer/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /Users/dain/work/geronimo/server/trunk/configs/
persistence-jpa10-deployer/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration: /Users/dain/work/geronimo/
server/trunk/configs/persistence-jpa10-deployer/target/plan/plan.xml
And when I send SIG_QUIT, it is hung here:
main prio=5 tid=0x00501430 nid=0x1804a00 runnable
[0xb07fe000..0xb08000dc]
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2365)
at java.lang.Class.getDeclaredMethod(Class.java:1907)
at java.io.ObjectStreamClass.getPrivateMethod
(ObjectStreamClass.java:1327)
at java.io.ObjectStreamClass.access$1600
(ObjectStreamClass.java:47)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:394)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.init(ObjectStreamClass.java:373)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:268)
at java.io.ObjectStreamClass.initNonProxy
(ObjectStreamClass.java:504)
at java.io.ObjectInputStream.readNonProxyDesc
(ObjectInputStream.java:1546)
at java.io.ObjectInputStream.readClassDesc
(ObjectInputStream.java:1460)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1693)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.defaultReadFields
(ObjectInputStream.java:1912)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1836)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1713)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readObject
(ObjectInputStream.java:339)
at org.apache.geronimo.gbean.GBeanData
$V0Externalizable.readExternal(GBeanData.java:285)
at org.apache.geronimo.gbean.GBeanData.readExternal
(GBeanData.java:252)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans
(SerializedGBeanState.java:111)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans
(SerializedGBeanState.java:65)
at
org.apache.geronimo.kernel.config.ConfigurationData.getGBeans
(ConfigurationData.java:171)
at org.apache.geronimo.kernel.config.Configuration.init
(Configuration.java:279)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance
(Constructor.java:494)
Is anyone else having this problem?
-dain
You do the hokeypokey...
And you turn yourself around. That's what it's all about! * * * I tossed together a stupid little groovy script which is a command- line interface to confluence, currently only supports adding a page, but more could be easily added. You should be able to: svn co https://svn.apache.org/repos/asf/geronimo/sandbox/hokeypokey/ trunk/ hokeypokey cd hokeypokey mvn gunzip target/hokeypokey-0.1-SNAPSHOT-bin.tar.gz | tar xf - And then: cd hokeypokey-0.1-SNAPSHOT ./bin/hokeypokey -u USERNAME -p PASSWORD addpage -s SPACE -t TITLE ./some-file-with-wiki.txt * * * It might blow up, if so... You put your left foot in, You put your left foot out; ... --jason
Re: Trunk build hanging
That did the trick.
Thanks,
-dain
On Feb 15, 2007, at 3:43 PM, Prasad Kashyap wrote:
http://www.nabble.com/Building-will-probably-require--XX%
3AMaxPermSize%3D128m-tf3219541.html#a8943995
On 2/15/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
Did you increase your memory allocation as per Jenck's note ?
Cheers
Prasad
On 2/15/07, Dain Sundstrom [EMAIL PROTECTED] wrote:
When building trunk I'm getting a hang in the configs. I've run
this
on two different computers (both macs), and both hang here
[INFO]
-
---
[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [tools:require-java-version {execution: validate-java-
version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /Users/dain/work/geronimo/server/trunk/configs/
persistence-jpa10-deployer/target/classes/META-INF
[INFO] Copying 2 files to /Users/dain/work/geronimo/server/trunk/
configs/persistence-jpa10-deployer/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /Users/dain/work/geronimo/server/trunk/configs/
persistence-jpa10-deployer/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration: /Users/dain/work/geronimo/
server/trunk/configs/persistence-jpa10-deployer/target/plan/
plan.xml
And when I send SIG_QUIT, it is hung here:
main prio=5 tid=0x00501430 nid=0x1804a00 runnable
[0xb07fe000..0xb08000dc]
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:
2365)
at java.lang.Class.getDeclaredMethod(Class.java:1907)
at java.io.ObjectStreamClass.getPrivateMethod
(ObjectStreamClass.java:1327)
at java.io.ObjectStreamClass.access$1600
(ObjectStreamClass.java:47)
at java.io.ObjectStreamClass$2.run
(ObjectStreamClass.java:394)
at java.security.AccessController.doPrivileged(Native
Method)
at java.io.ObjectStreamClass.init
(ObjectStreamClass.java:373)
at java.io.ObjectStreamClass.lookup
(ObjectStreamClass.java:268)
at java.io.ObjectStreamClass.initNonProxy
(ObjectStreamClass.java:504)
at java.io.ObjectInputStream.readNonProxyDesc
(ObjectInputStream.java:1546)
at java.io.ObjectInputStream.readClassDesc
(ObjectInputStream.java:1460)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1693)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.defaultReadFields
(ObjectInputStream.java:1912)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1836)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1713)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readObject
(ObjectInputStream.java:339)
at org.apache.geronimo.gbean.GBeanData
$V0Externalizable.readExternal(GBeanData.java:285)
at org.apache.geronimo.gbean.GBeanData.readExternal
(GBeanData.java:252)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans
(SerializedGBeanState.java:111)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans
(SerializedGBeanState.java:65)
at
org.apache.geronimo.kernel.config.ConfigurationData.getGBeans
(ConfigurationData.java:171)
at org.apache.geronimo.kernel.config.Configuration.init
(Configuration.java:279)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance
(Constructor.java:494)
Is anyone else having this problem?
-dain
[jira] Updated: (SM-420) Setting maximum memory
[ https://issues.apache.org/activemq/browse/SM-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie Goodyear updated SM-420: -- Attachment: smx420_java_mem.patch This patch will bring the Windows based ServiceMix start script more in line with the *nix script with regards to VM tuning switches. Note: Current behavior on Windows did not include setting for initial heap size. Modification to revision 508254 Setting maximum memory -- Key: SM-420 URL: https://issues.apache.org/activemq/browse/SM-420 Project: ServiceMix Issue Type: New Feature Reporter: Mike Gerdes Priority: Minor Attachments: smx420_java_mem.patch It should be possible to set the maximum memory that is available for ServiceMix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2840) Minor fixes
Minor fixes --- Key: GERONIMO-2840 URL: https://issues.apache.org/jira/browse/GERONIMO-2840 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Jarek Gawor The attached patch contains the following minor fixes: 1) Fix for JettyEJBWebServiceContext.Request.getURI(). It was returning client's host/port information instead of server's. Also, ?wsdl request would result in an exception thrown without jettyRequest.setHandled(true); call. 2) Fix in EjbModuleBuilder.java. It was passing invalid environment to module builder extensions. 3) Added empty constructor to EjbDeployment.java. It is required when a type is used as a reference for a gbean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2840) Minor fixes
[ https://issues.apache.org/jira/browse/GERONIMO-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-2840: -- Attachment: GERONIMO-2840.patch Minor fixes --- Key: GERONIMO-2840 URL: https://issues.apache.org/jira/browse/GERONIMO-2840 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Jarek Gawor Attachments: GERONIMO-2840.patch The attached patch contains the following minor fixes: 1) Fix for JettyEJBWebServiceContext.Request.getURI(). It was returning client's host/port information instead of server's. Also, ?wsdl request would result in an exception thrown without jettyRequest.setHandled(true); call. 2) Fix in EjbModuleBuilder.java. It was passing invalid environment to module builder extensions. 3) Added empty constructor to EjbDeployment.java. It is required when a type is used as a reference for a gbean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
outstanding patches
Hi, I was wondering if somebody could review/commit the following patches I submitted: 1) https://issues.apache.org/jira/browse/GERONIMO-2825 2) https://issues.apache.org/jira/browse/GERONIMO-2826 3) https://issues.apache.org/jira/browse/GERONIMO-2830 4) https://issues.apache.org/jira/browse/GERONIMO-2836 5) https://issues.apache.org/jira/browse/GERONIMO-2840 Most of them are pretty small so should be easy to review. Thanks, Jarek
Re: outstanding patches
Am on it! sorry for the delay. -- dims On 2/15/07, Jarek Gawor [EMAIL PROTECTED] wrote: Hi, I was wondering if somebody could review/commit the following patches I submitted: 1) https://issues.apache.org/jira/browse/GERONIMO-2825 2) https://issues.apache.org/jira/browse/GERONIMO-2826 3) https://issues.apache.org/jira/browse/GERONIMO-2830 4) https://issues.apache.org/jira/browse/GERONIMO-2836 5) https://issues.apache.org/jira/browse/GERONIMO-2840 Most of them are pretty small so should be easy to review. Thanks, Jarek -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
[jira] Resolved: (GERONIMO-2825) CXF and spring version update
[ https://issues.apache.org/jira/browse/GERONIMO-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davanum Srinivas resolved GERONIMO-2825. Resolution: Fixed Fixed in 508298 thanks, dims CXF and spring version update - Key: GERONIMO-2825 URL: https://issues.apache.org/jira/browse/GERONIMO-2825 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Reporter: Jarek Gawor Attachments: GERONIMO-2825.patch Geronimo currently uses outdated versions of CXF and Spring. The attached patch upgrades the version of CXF and Spring and fixes minor package name change in CXF code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-2826) Test case to test invocations using service-ref
[ https://issues.apache.org/jira/browse/GERONIMO-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davanum Srinivas resolved GERONIMO-2826. Resolution: Fixed Fixed in 508298 Test case to test invocations using service-ref --- Key: GERONIMO-2826 URL: https://issues.apache.org/jira/browse/GERONIMO-2826 Project: Geronimo Issue Type: Test Security Level: public(Regular issues) Components: webservices Reporter: Jarek Gawor Attachments: GERONIMO-2826.patch The attached patch includes a new test case that invokes a web services from within a JSP page. The JSP page obtains the looks up the service-ref in JNDI. Currently, the test case will pass with CXF even though the service invocation returns incorrect value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-2830) Updated dependencies for ejb-based tests
[ https://issues.apache.org/jira/browse/GERONIMO-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davanum Srinivas resolved GERONIMO-2830. Resolution: Fixed Fixed in 508298 Updated dependencies for ejb-based tests Key: GERONIMO-2830 URL: https://issues.apache.org/jira/browse/GERONIMO-2830 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: Jarek Gawor Attachments: GERONIMO-2830.patch Standalone test clients require a new openejb-client dependency after the openejb2 to openejb3 switch. The patch adds these dependencies. These tests still fail because of some JNDI lookup issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-2836) Improvements for CXF integration
[ https://issues.apache.org/jira/browse/GERONIMO-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davanum Srinivas resolved GERONIMO-2836. Resolution: Fixed Fixed in 508298 Improvements for CXF integration Key: GERONIMO-2836 URL: https://issues.apache.org/jira/browse/GERONIMO-2836 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Reporter: Jarek Gawor Attachments: GERONIMO-2836.patch The following patch includes a number of small improvements to CXF integration: 1) SOAP bindings are now show up in the dynamically generated WSDL. 2) The soap:address location URL of the service is now properly returned (without ?wsdl) 3) Improved HandlerChains support to handle protocol bindings specified either as an URI or a token. 4) HandlerChains should be properly filtered (based on service qname, port qname, and protocol binding) now on the server-side (namespace checking is not done) 5) HTTP GET on a service now returns 'Hi, I'm a web service' type of thing instead of an error. 6) Basic app client support (service-ref) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-2840) Minor fixes
[ https://issues.apache.org/jira/browse/GERONIMO-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davanum Srinivas resolved GERONIMO-2840. Resolution: Fixed Fixed in 508298 Minor fixes --- Key: GERONIMO-2840 URL: https://issues.apache.org/jira/browse/GERONIMO-2840 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Jarek Gawor Attachments: GERONIMO-2840.patch The attached patch contains the following minor fixes: 1) Fix for JettyEJBWebServiceContext.Request.getURI(). It was returning client's host/port information instead of server's. Also, ?wsdl request would result in an exception thrown without jettyRequest.setHandled(true); call. 2) Fix in EjbModuleBuilder.java. It was passing invalid environment to module builder extensions. 3) Added empty constructor to EjbDeployment.java. It is required when a type is used as a reference for a gbean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Simple Web Service with JAX-WS sample on AG wiki
Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Lin [1]http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
[jira] Created: (GERONIMO-2841) Valve reports request method as GET even though POST request was made
Valve reports request method as GET even though POST request was made - Key: GERONIMO-2841 URL: https://issues.apache.org/jira/browse/GERONIMO-2841 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Reporter: Jarek Gawor The Request of EJBWebServiceValve in Tomcat return the request method as GET even though POST request was sent. In similar class in Jetty the request method is reported correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Simple Web Service with JAX-WS sample on AG wiki
Great. A few comments inline: On 2/15/07, Lin Sun [EMAIL PROTECTED] wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. Hmm... is that different from the javax.xml.ws.Service API? Why couldn't you use the Axis2 implementation of the Service API? I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Right, there should be only one page. And eventually (and hopefully) those differences should disappear, so we should stress that these differences are temporary. Jarek
Context level clustering not supported in Tomcat it seems
As part of https://issues.apache.org/jira/browse/GERONIMO-2577 I had opened the following bug in Tomcat: Context level clustering on 3 or more nodes fails in Tomcat 5.5.20 http://issues.apache.org/bugzilla/show_bug.cgi?id=41620; They have closed the bug as Resolved Invalid with the following comments: --- *Additional Comment #7http://issues.apache.org/bugzilla/show_bug.cgi?id=41620#c7From Mark Thomas [EMAIL PROTECTED] 2007-02-15 18:54 * [replyhttp://issues.apache.org/bugzilla/show_bug.cgi?id=41620#add_comment] --- It is not possible to configure clustering in context.xml. It must be done at the Host level (with the jvmRoute defined at the Engine level) within server.xml That makes our default clustering article http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.htmlinvalid. Should we now remove it saying that Geronimo (Tomcat version) supports clustering at the Host/Engine level only? Dave Colasurdo and myself have already created a new article illustrating how to setup Geronimo (Tomcat version) clustering at the host/engine level: http://cwiki.apache.org/GMOxDOC11/clustering-sample-application-tomcat-host-level.html. Please suggest if we should retain only this and delete the other article on context level clustering? -- Shiva
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ https://issues.apache.org/jira/browse/GERONIMO-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473605 ] Shiva Kumar H R commented on GERONIMO-2577: --- Tomcat bug http://issues.apache.org/bugzilla/show_bug.cgi?id=41620 closed as Resolved Invalid with the following comments: --- Additional Comment #7 From Mark Thomas 2007-02-15 18:54 [reply] --- It is not possible to configure clustering in context.xml. It must be done at the Host level (with the jvmRoute defined at the Engine level) within server.xml No discussing on AG dev list as to whether we should claim that Geronimo (Tomcat version) supports Clustering at the Host or Engine level only. Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down. --- Key: GERONIMO-2577 URL: https://issues.apache.org/jira/browse/GERONIMO-2577 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering, Tomcat Affects Versions: 1.1, 1.1.1 Environment: JDK - Sun java version 1_5_0_09(32bit) OS- Red Hat Enterprise Linux ES4 update4(32bit) Http Server - Apache 2.0.59 +mod_jk 1.2.19 Reporter: Kaoru Matsumura Attachments: appClustering_context.xml, appClustering_server.xml, config.xml, context.xml, geronimo-new.log, geronimo-web-hostlevel.xml, geronimo-web-new.xml, geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, geronimo-web.xml, new-config.xml, server-nodeA.xml, server-nodeB.xml, server-nodeC.xml We run Geronimo cluster with three nodes. In our environment, with DeltaManager set for replication module, we found that the last node cound not continue the processes when the other nodes is intentionally halted in order. We recognize Tomcat 5.5.15 is OK with the same configuration and operations. Test Application The Web application program, which was used for the test, simply reads the number of access count, and then write the count to HttpSession object. Configuration?Files == We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html * config.xml We add the following parameters to the standard configuration. gbean name=TomcatEngine attribute name=initParamsname=Geronimo jvmRoute=nodeA/attribute /gbean Operations === 1 Have browser access to Test Application , and reload several times.(*1) HttpSession object is created on the nodeA. 2 And then, We kill the process of geronimo on the nodeA with $kill -9 Process ID.(*2) 3 Reload the browser at one time. The node changes to nodeB.(*3) 4 Reload the browser several times.(*4) 5 And then, We kill the process of geronimo on the nodeB with $kill -9 Process ID.(*5) 6 Reload the browser at one time.(And then, We expect that the process continues at the nodeC.) But the HttpSessionID of the HttpSession object is changed to another ID and the counter value is back to 1.(*6) As a result, the geronimo cluster cannot continue the process. For avoidance === When replication module is SimpleTcpReplicationManager, the geronimo cluster can continue the process. Debug levels logs == (*1) nodeA -- 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is 7160C8614D20687D3548E8488AB65AC3.nodeA 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL PROTECTED] at /ClusterCheck 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec 20:06:17,737 DEBUG [MsgContext] COMMIT 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] === MimeHeaders === 20:06:17,737 DEBUG [MsgContext] CLOSE 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on /ClusterCheck/counter 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. 20:06:17,757 DEBUG [McastService] Mcast receive ping from member org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, alive=58960] --- nodeC --- 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 ms. 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received SessionMessage of type=(SESSION-DELTA) from [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, alive=130441]] 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. --- (*2) nodeB
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ https://issues.apache.org/jira/browse/GERONIMO-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473609 ] Shiva Kumar H R commented on GERONIMO-2577: --- Read the last line in above comment as Now discussing on AG dev list ... Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down. --- Key: GERONIMO-2577 URL: https://issues.apache.org/jira/browse/GERONIMO-2577 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering, Tomcat Affects Versions: 1.1, 1.1.1 Environment: JDK - Sun java version 1_5_0_09(32bit) OS- Red Hat Enterprise Linux ES4 update4(32bit) Http Server - Apache 2.0.59 +mod_jk 1.2.19 Reporter: Kaoru Matsumura Attachments: appClustering_context.xml, appClustering_server.xml, config.xml, context.xml, geronimo-new.log, geronimo-web-hostlevel.xml, geronimo-web-new.xml, geronimo-web-nodeB.xml, geronimo-web-nodeC.xml, geronimo-web.xml, new-config.xml, server-nodeA.xml, server-nodeB.xml, server-nodeC.xml We run Geronimo cluster with three nodes. In our environment, with DeltaManager set for replication module, we found that the last node cound not continue the processes when the other nodes is intentionally halted in order. We recognize Tomcat 5.5.15 is OK with the same configuration and operations. Test Application The Web application program, which was used for the test, simply reads the number of access count, and then write the count to HttpSession object. Configuration?Files == We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html * config.xml We add the following parameters to the standard configuration. gbean name=TomcatEngine attribute name=initParamsname=Geronimo jvmRoute=nodeA/attribute /gbean Operations === 1 Have browser access to Test Application , and reload several times.(*1) HttpSession object is created on the nodeA. 2 And then, We kill the process of geronimo on the nodeA with $kill -9 Process ID.(*2) 3 Reload the browser at one time. The node changes to nodeB.(*3) 4 Reload the browser several times.(*4) 5 And then, We kill the process of geronimo on the nodeB with $kill -9 Process ID.(*5) 6 Reload the browser at one time.(And then, We expect that the process continues at the nodeC.) But the HttpSessionID of the HttpSession object is changed to another ID and the counter value is back to 1.(*6) As a result, the geronimo cluster cannot continue the process. For avoidance === When replication module is SimpleTcpReplicationManager, the geronimo cluster can continue the process. Debug levels logs == (*1) nodeA -- 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is 7160C8614D20687D3548E8488AB65AC3.nodeA 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL PROTECTED] at /ClusterCheck 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec 20:06:17,737 DEBUG [MsgContext] COMMIT 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] === MimeHeaders === 20:06:17,737 DEBUG [MsgContext] CLOSE 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on /ClusterCheck/counter 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. 20:06:17,757 DEBUG [McastService] Mcast receive ping from member org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, alive=58960] --- nodeC --- 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 ms. 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received SessionMessage of type=(SESSION-DELTA) from [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, alive=130441]] 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. --- (*2) nodeB (same as nodeC) --- 20:06:39,817 INFO [SimpleTcpCluster] Received member disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, alive=149288] 20:06:39,818 DEBUG [MapperListener] Handle geronimo:type=IDataSender,senderAddress=192.168.1.1,senderPort=4001 type : JMX.mbean.unregistered 20:06:39,818 DEBUG [MapperListener] Handle
Re: Simple Web Service with JAX-WS sample on AG wiki
Hi Lin, Great work... We are getting closer closer to finish Axis2 with POJO support ... Dims do you any idea to add what are we missing right now ? Are you using latest version of trunk to build Geronimo? IMO in Axis2 there is a bug and I am submitting a patch for that too ;). Please see my in line comments too. Thanks, Lasantha Lin Sun wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... It wasn't necessary to generate these files in CXF for WSDL provided situation before. I though it is only for Axis2 to necessary to do this step. Jarek do you have any idea ? :-) 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Lin [1]http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
Re: Simple Web Service with JAX-WS sample on AG wiki
Hi All, Great work... We are getting closer closer to finish Axis2 with POJO support ... Dims do you any idea what are we missing right now ? Are you using latest version of trunk to build Geronimo? IMO in Axis2 there is a bug and I am submitting a patch for that too ;). Please see my in line comments too. Thanks, Lasantha Lin Sun wrote: Hi there, After making some changes to the sample[1], I am able to get it (slightly different versions of it for CXF and Axis2) working with this week's trunk. Here are some observations: 1) I have to use the generated classes (package-info, objectFactory, RequestWrapper and ResponseWrapper classes) for CXF to get the war file deployed. This was not required before... It wasn't necessary to generate these files in CXF for WSDL provided situation before. I though it is only for Axis2 to necessary to do this step. Jarek do you have any idea ? :-) 2) I developed an Axiom based web services client for Axis2 so that it doesn't require CXF specific jars at the runtime of the client. I'll begin updating the docs and send out another update. Initial thought is to use the same wiki page for both CXF and Axis2 (instead of creating a new page for Axis2) and highlight the differences. Lin [1]http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
[jira] Created: (GERONIMO-2842) Geronimo Axis2 - JAXWS Web Services are not working for WSDL provided situation
Geronimo Axis2 - JAXWS Web Services are not working for WSDL provided situation --- Key: GERONIMO-2842 URL: https://issues.apache.org/jira/browse/GERONIMO-2842 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Lasantha Ranaweera JAXWS webservices are not working in WSDL provided situation. This has been working for a previous release missing right now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2842) Geronimo Axis2 - JAXWS Web Services are not working for WSDL provided situation
[ https://issues.apache.org/jira/browse/GERONIMO-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lasantha Ranaweera updated GERONIMO-2842: - Attachment: GERONIMO-2842.patch Read the WSDL file from archive create a Definition object. Geronimo Axis2 - JAXWS Web Services are not working for WSDL provided situation --- Key: GERONIMO-2842 URL: https://issues.apache.org/jira/browse/GERONIMO-2842 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Lasantha Ranaweera Attachments: GERONIMO-2842.patch JAXWS webservices are not working in WSDL provided situation. This has been working for a previous release missing right now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ClassFinder questions/problems -- annotation processing
Hi David/Dain, I finally see what's going on here now--and it really makes a lot of sense. I'm not so sure it's a bug with the classloading process so much as it's just the way the current code functions. I can't easily show a sequence diagram here but can briefly explain. It appears the the EarContext for a deployed EAR file is aggregated across successive calls from EARConfigBuilder.buildConfiguration() to the installModule() method on first the WebModuleBuilder class, and then second on the EjbModuleBuilder class. This explains why ClassFinder was working correctly in EjbRefBuilder (i.e. the deployed module's EarContext had been fully aggregated) but failed for me in AbstractWebModuleBuilder (i.e., the deployed module's EarContext had not yet been fully aggregated). So, rather than fixing something that's not really broken in AbstractWebModuleBuilder, the best solution in my view is to push the Annotation processing out of the installModule processing of the module builder(s) up into the configuration builder. This would allow us to encapsulate the Annotation processing for deployed EJB applications, Web applications, App Client applications, and Connectors (not sure these would be annotated though) into a single class: EARConfigBuilder. Additionally, it would guarantee that we always have access to a fully aggregated EarContext, and thus a fully populated classloader to pass to ClassFinder. And finally, I think it would encapsulate most of the Geronimo annotation processing except for Web Services. This approach is somewhat in line with my original proposed plan for Annotation Processing for Geronimo, it's just the conduit has changed somewhat. Do either of you (or anyone else) have any thoughts, comments and/or concerns ?? Thanks, Tim McConnell Tim McConnell wrote: Hi Dain, What you suggest does make a lot of sense. But for the stateless-calculator ear file (i.e., calculator-stateless-ear-2[1].0-M2.ear) I would then expect to find the calculator-stateless-ear-2[1].0-M2.jar file on one of the parent classloaders for the WAR classloader in AbstractWebModuleBuilder. It's not, so I suspect there is a bug somewhere as you suggest. I shall investigate further tomorrow. Thanks for the pointer Dain Sundstrom wrote: On Feb 6, 2007, at 12:49 PM, David Blevins wrote: On Feb 4, 2007, at 7:19 PM, Tim McConnell wrote: Hi again Dave, after your recommendation below to do all the annotation discovery during the installModule phase of deployment ClassFinder is working much better for me. I do still have another scenario I'd appreciate some advice on. It seems that when an EJB EAR file (with embedded JAR and WAR files) gets deployed in Geronimo, there are two builders invoked: e.g., TomcatModuleBuilder/AbstractWebModuleBuilder and EJBModuleBuilder such that the embedded JAR file is not added to the ClassPath/ClassLoader when the WAR is deployed (I assume this is the way it should work since I haven't changed it--yet). So, if there are annotations in the WAR class files pointing to classes in the JAR file, we'll still encounter NoClassDefException(s). I can just add the JAR files in the EAR to the classpath of the WAR, which is what I've done to get around the problem, but I'm not sure this is the best alternative. Do you have any thoughts?? Thanks much Those should be added automatically via the deployment system. Very puzzling. Dain, did you see anything like this when you did that hack for @EJB annotation support in Servlets? Nope. The WAR class loader is a child of the EAR class loader so the WAR should see all of the jars in the ear. If that is not the case, then there is a bug. -dain
[jira] Created: (GERONIMO-2843) Error when configuring JMS through Geronimo console
Error when configuring JMS through Geronimo console --- Key: GERONIMO-2843 URL: https://issues.apache.org/jira/browse/GERONIMO-2843 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.2 Environment: Ubuntu Windows Reporter: Karthiga Rajeevani Ratnam I noticed an error when I try to deploy the JMS Resources or when I try to view its deployment plan. The error below : - 16:01:24,343 ERROR [AbstractHandler] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.create Configuration(JMXDeploymentManager.java:299) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(Ab stractHandler.java:471) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBef oreView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPageP ortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java :690) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java :170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java :68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java :82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java :617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java :170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 68) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication Context.java:633) at org.apache.geronimo.jetty.JettyWebAppContext.handle (JettyWebAppContex t.java:329) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.apache.geronimo.jetty.JettyWebAppContext.handle(JettyWebAppContex t.java:313) at org.mortbay.http.HttpServer.service (HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:820) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986) at org.mortbay.http.HttpConnection.handle (HttpConnection.java:837) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java: 245) at org.mortbay.util.ThreadedServer.handle( ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run (ThreadPool.java:534) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to
Re: Error when configuring JMS through Geronimo console
Hi Hernan, I created a JIRA Issue ( GERONIMO-2843). Regards Karthiga On 2/15/07, Hernan Cunico [EMAIL PROTECTED] wrote: Pls create a JIRA detailing the error. Cheers! Hernan Lasantha Ranaweera wrote: Hi Karthiga, I observed the same problem in the 1.2 beta release of Geronimo. But it works correctly in 2.x releases. I am not sure either what can we do for this kind of issue. Can somebody in the list please let us know whether we need to create a JIRA or not? It would be ideal if someone explain the future of 1.2 release. Thanks, Lasantha Karthiga Ratnam wrote: Hi All, I'm working on Configuring JMS document for v1.2 of Geronimo. I noticed an error when I try to deploy the JMS Resources or when I try to view its deployment plan. I tried on both Linux and Windows environments. Please find the error below: - 16:01:24,343 ERROR [AbstractHandler] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.create Configuration(JMXDeploymentManager.java:299) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(Ab stractHandler.java:471) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBef oreView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPageP ortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java :170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java :68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java :82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java :170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 68) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication Context.java:633) at org.apache.geronimo.jetty.JettyWebAppContext.handle (JettyWebAppContex t.java:329) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.apache.geronimo.jetty.JettyWebAppContext.handle(JettyWebAppContex t.java:313) at org.mortbay.http.HttpServer.service (HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:820) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986) at org.mortbay.http.HttpConnection.handle
[jira] Updated: (GERONIMO-2843) Error when configuring JMS through Geronimo console
[ https://issues.apache.org/jira/browse/GERONIMO-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthiga Rajeevani Ratnam updated GERONIMO-2843: Environment: Linux Windows (was: Ubuntu Windows) Error when configuring JMS through Geronimo console --- Key: GERONIMO-2843 URL: https://issues.apache.org/jira/browse/GERONIMO-2843 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Environment: Linux Windows Reporter: Karthiga Rajeevani Ratnam I noticed an error when I try to deploy the JMS Resources or when I try to view its deployment plan. The error below : - 16:01:24,343 ERROR [AbstractHandler] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.create Configuration(JMXDeploymentManager.java:299) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(Ab stractHandler.java:471) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBef oreView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPageP ortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java :690) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java :170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java:163) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java :68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java :82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java :617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428 ) at org.apache.geronimo.jetty.JettyServletHolder.handle (JettyServletHolde r.java:103) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java :170 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java :471) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWe bApplicationHandler.java:58) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 68) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication Context.java:633) at org.apache.geronimo.jetty.JettyWebAppContext.handle (JettyWebAppContex t.java:329) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.apache.geronimo.jetty.JettyWebAppContext.handle(JettyWebAppContex t.java:313) at org.mortbay.http.HttpServer.service (HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:820) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986) at
[jira] Commented: (GERONIMO-2842) Geronimo Axis2 - JAXWS Web Services are not working for WSDL provided situation
[
https://issues.apache.org/jira/browse/GERONIMO-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473617
]
Jarek Gawor commented on GERONIMO-2842:
---
Btw, notice that there is a loop:
for (WebserviceDescriptionType desc : wst.getWebserviceDescription()) { .. }
So there could be more then 1 WebserviceDescriptionType elements in the
descriptor file and each could have a different wsdl file. Therefore, you can't
pass wsdlDefinition as an instance variable. Only last wsdl definition read
would be used. So if you need to pass wsdl definition around you have to stick
it into the PortInfo object (e.g. create Axis2 specific PortInfo object by
extending the JAXWS one).
Geronimo Axis2 - JAXWS Web Services are not working for WSDL provided
situation
---
Key: GERONIMO-2842
URL: https://issues.apache.org/jira/browse/GERONIMO-2842
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Reporter: Lasantha Ranaweera
Attachments: GERONIMO-2842.patch
JAXWS webservices are not working in WSDL provided situation. This has been
working for a previous release missing right now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
