[jira] Created: (SM-904) The jmx url is wrong if there are spaces at the end of the properties
The jmx url is wrong if there are spaces at the end of the properties - Key: SM-904 URL: https://issues.apache.org/activemq/browse/SM-904 Project: ServiceMix Issue Type: Bug Components: servicemix-core Reporter: Thomas Termin Assigned To: Thomas Termin The jmx.url string is wrong if the properties in servicemix.properties have spaces at the end. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SOAP binding/serialization
Hi,
I had some issues with soap messages not being serialized properly,
header/body handling (binding) etc. I'm using the wsdl11-wrapping and
I don't know if it has something to do with this. Anyways, at least it
looks like the binding stuff is being discarded at
org.apache.servicemix.http.HttpEndpoint:228, but I don't know if the
part handling (soap binding) was occurring before that; although, the
end-results weren't suggesting so. (All parts were serialized to the
soap body, or something.) So I hacked up this little patch which does
the part handling. Diffs attached. Best effort -kind of stuff, works
for me. Just if anyone else is interested.. Though, I didn't quite get
what HttpEndpoint#overrideDefinition was trying to do so that hack may
be a little conflicting.. (see the httpendpoint-patch.)
I'd also like to know if this would somehow work without the patch as
patches are a bit annoying. :)
(There also appears to be some major stuff coming in the soap2-module,
but it seemed a little incomplete so I didn't take a closer look.)
Btw., I guess the soap-headers of the reply message are being
forwarded correctly?
-janne
Index:
servicemix-soap/src/main/java/org/apache/servicemix/soap/marshalers/JBIMarshaler.java
===
---
servicemix-soap/src/main/java/org/apache/servicemix/soap/marshalers/JBIMarshaler.java
(revision 523275)
+++
servicemix-soap/src/main/java/org/apache/servicemix/soap/marshalers/JBIMarshaler.java
(working copy)
@@ -17,6 +17,8 @@
package org.apache.servicemix.soap.marshalers;
import java.net.URI;
+import java.util.Collection;
+import java.util.HashSet;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
@@ -24,11 +26,26 @@
import javax.activation.DataHandler;
import javax.jbi.messaging.Fault;
import javax.jbi.messaging.NormalizedMessage;
+import javax.wsdl.Message;
+import javax.wsdl.Part;
+import javax.wsdl.WSDLElement;
+import javax.wsdl.extensions.soap.SOAPHeader;
import javax.xml.namespace.QName;
+import javax.xml.parsers.DocumentBuilder;
+import javax.xml.parsers.ParserConfigurationException;
+import javax.xml.transform.Transformer;
+import javax.xml.transform.TransformerException;
+import javax.xml.transform.TransformerFactory;
+import javax.xml.transform.dom.DOMResult;
+import javax.xml.transform.dom.DOMSource;
import org.apache.servicemix.JbiConstants;
+import org.apache.servicemix.jbi.util.DOMUtil;
import org.apache.servicemix.soap.SoapFault;
+import org.w3c.dom.Document;
import org.w3c.dom.DocumentFragment;
+import org.w3c.dom.Node;
+import org.w3c.dom.NodeList;
/**
*
@@ -73,7 +90,8 @@
}
}
- public void fromNMS(SoapMessage soapMessage, NormalizedMessage
normalizedMessage) {
+ public void fromNMS(SoapMessage soapMessage, NormalizedMessage
normalizedMessage,
+ Message msg, WSDLElement bindingElem) {
if (normalizedMessage.getProperty(JbiConstants.SOAP_HEADERS) !=
null) {
Map headers = (Map)
normalizedMessage.getProperty(JbiConstants.SOAP_HEADERS);
for (Iterator it = headers.entrySet().iterator();
it.hasNext();) {
@@ -95,6 +113,55 @@
URI role = (URI) normalizedMessage.getProperty(SOAP_FAULT_ROLE);
SoapFault fault = new SoapFault(code, subcode, reason, node, role,
normalizedMessage.getContent());
soapMessage.setFault(fault);
+} else if (bindingElem != null) {
+ boolean success = false;
+ DocumentBuilder docBuilder = null;
+ try {
+ // QName#hashCode() is implemented suitably
+ CollectionQName headerElems = new HashSetQName();
+ for (Object ext :
bindingElem.getExtensibilityElements()) {
+ if (ext instanceof SOAPHeader) {
+ Part p = msg.getPart(((SOAPHeader)
ext).getPart());
+ if (p != null p.getElementName() !=
null)
+
headerElems.add(p.getElementName());
+ }
+ }
+ docBuilder = DOMUtil.getBuilder();
+ Transformer tr =
TransformerFactory.newInstance().newTransformer();
+ Document jbiContent = docBuilder.newDocument();
+ Document soapBody = docBuilder.newDocument();
+ tr.transform(normalizedMessage.getContent(), new
DOMResult(jbiContent));
+ NodeList wrapperMsg = jbiContent.getElementsByTagNameNS(
+
http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper;, message);
+ if (wrapperMsg.getLength() == 1) {
+ Node part = wrapperMsg.item(0).getFirstChild();
+
[jira] Commented: (SM-905) message filter registers predicates as mbean as well as a new predicate for on/off filtering
[ https://issues.apache.org/activemq/browse/SM-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38925 ] Guillaume Nodet commented on SM-905: A few thoughts: * the mbean related stuff should be put upper in the class hierachy (in the Endpoint class i'd say) * the endpoint could define one helper method: public void registerMBean(Object implementation, Class interfaceClass, String name) or public void registerMBean(Object implementation, Class interfaceClass) where the name could be defaulted to the interface name, minus the MBean. Actually the interface could be also auto detected by checking all the interfaces implemented by the object that ends with MBean, so the method could just be public void registerMBean(Object implementation) Well, maybe the three methods can be implemented ... That way, the endpoint could register an interface for a sub component (like the filter predicate), or for itself. Again, this behavior could also be turned on by default (auto-discovery of interfaces implemented by the endpoint ending with Mbean) ... message filter registers predicates as mbean as well as a new predicate for on/off filtering Key: SM-905 URL: https://issues.apache.org/activemq/browse/SM-905 Project: ServiceMix Issue Type: New Feature Components: servicemix-eip Reporter: Thomas Termin Priority: Minor Attachments: eip-message-filter.patch Predicat MBeans are registered exactly as the endpoint just with the extension Predicate Interessting is the message filter which do all with reflection and just register predicates if an MBean interface is implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-906) extend ComponentSupport with methods to propagate the correlation id
extend ComponentSupport with methods to propagate the correlation id Key: SM-906 URL: https://issues.apache.org/activemq/browse/SM-906 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Reporter: Thomas Termin Assigned To: Thomas Termin Priority: Minor extends ComponentSupport that it has methods for creating exchanges with propagating the correlation id -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-907) Update to the latest version of the 1.3 spec
Update to the latest version of the 1.3 spec Key: SM-907 URL: https://issues.apache.org/activemq/browse/SM-907 Project: ServiceMix Issue Type: Improvement Components: servicemix-wsn2005 Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-907) Update to the latest version of the WS-Notification 1.3 spec
[ https://issues.apache.org/activemq/browse/SM-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-907. Resolution: Fixed URL: http://svn.apache.org/viewvc?view=revrev=523728 Update to the latest version of the WS-Notification 1.3 spec Key: SM-907 URL: https://issues.apache.org/activemq/browse/SM-907 Project: ServiceMix Issue Type: Improvement Components: servicemix-wsn2005 Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-907) Update to the latest version of the WS-Notification 1.3 spec
[ https://issues.apache.org/activemq/browse/SM-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SM-907: --- Priority: Minor (was: Major) Summary: Update to the latest version of the WS-Notification 1.3 spec (was: Update to the latest version of the 1.3 spec) Update to the latest version of the WS-Notification 1.3 spec Key: SM-907 URL: https://issues.apache.org/activemq/browse/SM-907 Project: ServiceMix Issue Type: Improvement Components: servicemix-wsn2005 Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-908) Upgrade to ActiveMQ 5.0
Upgrade to ActiveMQ 5.0 --- Key: SM-908 URL: https://issues.apache.org/activemq/browse/SM-908 Project: ServiceMix Issue Type: Improvement Reporter: Guillaume Nodet Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-909) Upgrade to Geronimo 2.0
Upgrade to Geronimo 2.0 --- Key: SM-909 URL: https://issues.apache.org/activemq/browse/SM-909 Project: ServiceMix Issue Type: Improvement Reporter: Guillaume Nodet Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-903) ServiceMix now requires java 5
[ https://issues.apache.org/activemq/browse/SM-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-903. Resolution: Fixed Assignee: Guillaume Nodet URL: http://svn.apache.org/viewvc?view=revrev=523712 To be able to fully remove backport-util-concurrent from the distribution, we need to switch to AMQ 5.0 and Geronimo 2.0 ServiceMix now requires java 5 -- Key: SM-903 URL: https://issues.apache.org/activemq/browse/SM-903 Project: ServiceMix Issue Type: Improvement Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-910) better handling of unavailable external http services
better handling of unavailable external http services - Key: SM-910 URL: https://issues.apache.org/activemq/browse/SM-910 Project: ServiceMix Issue Type: Improvement Components: servicemix-http Affects Versions: 3.1 Reporter: Dominique De Vito Fix For: 3.1.1 Attachments: patchfile.txt The org.apache.servicemix.http.processors.ProviderProcessor calls an external http service. When calling an unavailable external http service, the following stack trace appears after an exception rise: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:516) at java.net.Socket.connect(Socket.java:466) at java.net.Socket.init(Socket.java:366) at java.net.Socket.init(Socket.java:239) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:79) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:121) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1321) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346) at org.apache.servicemix.http.processors.ProviderProcessor.process(ProviderProcessor.java:168) at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:489) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:441) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) I think handling could be improved in case of (exchange instanceof InOnly == false), so that a response could be returned. See the attached patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-906) extend ComponentSupport with methods to propagate the correlation id
[ https://issues.apache.org/activemq/browse/SM-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Termin resolved SM-906. -- Resolution: Fixed Author: tterm Date: Thu Mar 29 07:43:43 2007 New Revision: 523729 URL: http://svn.apache.org/viewvc?view=revrev=523729 Log: SM-906 extend ComponentSupport with methods to propagate the correlation id Modified: incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/components/util/ComponentSupport.java extend ComponentSupport with methods to propagate the correlation id Key: SM-906 URL: https://issues.apache.org/activemq/browse/SM-906 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Reporter: Thomas Termin Assigned To: Thomas Termin Priority: Minor extends ComponentSupport that it has methods for creating exchanges with propagating the correlation id -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
What is the alternate proposal? On Mar 28, 2007, at 5:02 PM, Jason Dillon wrote: I really hate that we have version information in artifactIds... this is a huge PITA when the version needs to be changed. This is a *very* bad practice. Can we please stop this madness? --jason
[jira] Closed: (GERONIMO-3020) Unable to deploy a web app to current trunk build of geronimo (rev 522077)
[ https://issues.apache.org/jira/browse/GERONIMO-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3020. --- Assignee: David Jencks (was: Gianny Damour) Regression: [Regression] Thanks for having fixed this issue David! I was not able to get time before today and M4. Frank, Rakesh, thanks for your investigations and patches. The commit log was not so clear with respect to the problem of the previous implementation: DeployTool, i.e. the deployer, depends on a DeploymentFactory, which is actually a DFwK. The static registration of a DFImpl instance by DFwK was an issue as two DF implementations were able to handle URIs starting with deployer:geronimo:: DFImpl and DFwK (DFwK is registered in ServerConnection.tryToConnect). DFwK is the implementation we want to use, and not DFimpl, as it has access to ModuleConfigurers. Hence, the refactoring. So, we want to register DFwK in DFwK. Unable to deploy a web app to current trunk build of geronimo (rev 522077) -- Key: GERONIMO-3020 URL: https://issues.apache.org/jira/browse/GERONIMO-3020 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M5 Environment: Linux - Java 1.5.0_08 Reporter: Jay D. McHugh Assigned To: David Jencks Priority: Blocker Fix For: 2.0-M4 Attachments: GERONIMO-3020-3.patch, J3020.patch, J3020_opt.patch, JIRA3020_useDFWithKernel.patch Trying to deploy a web app from the web based admin console causes a servlet exception. Deploying the same web app from the command line is successful. (ie: java -jar bin/deployer.jar --user system --password manager deploy simple.war) You should be able to duplicate by trying to deploy the simple.war file from geronimo-2786. Here is the stack trace: 15:12:20,342 ERROR [[Deployment]] Servlet.service() for servlet Deployment threw exception javax.servlet.ServletException at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:260) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(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:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:324) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at
Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
Matt Hogstrom wrote: What is the alternate proposal? I suspect it should follow the more normal convention of name of what it is followed by the version identifier. For specs, the name of the spec artifact frequently contains a version identifier for the level of the spec. For example the javamail specs have names such as this: geronimo-javamail_1.3.1_spec-1.3 This indicates that this is an implementation of the javamail 1.3.1 specification, and the Geronimo version level is 1.3. So, what's the version level vs. specification level of the above artifact? Is this an implementation of the 1.1MR3 leve of the javaee deployment spec? Then it is missing its version identifier all together. It should be something like geronimo-javaee-deployment_1.1MR3_spec-1.0 Or is this the MR3 version of the javaee deployment spec version 1.1? Then this should be geronimo-javaee-deployment_1.1_spec-MR3 Or, is the version identifier actually the full 1.1_MR3, in which case it should be geronimo-javaee-deployment_spec-1.1MR3 In all cases, the version level of the artifact is the last element of the artifact name. Rick On Mar 28, 2007, at 5:02 PM, Jason Dillon wrote: I really hate that we have version information in artifactIds... this is a huge PITA when the version needs to be changed. This is a *very* bad practice. Can we please stop this madness? --jason
Re: I'm now a dad !
Congratulations John! I wish you and your family nothing but happiness. Gianny On 28/03/2007, at 1:58 PM, John Sisson wrote: On Tuesday 27th of March at 11am I became the proud father of our first child, a baby girl, Jasmine Mae Sisson, weighing 3.6 kilos ( 7.92 pounds). Lisa and Jasmine are doing well, although now very tired. http://www.youtube.com/watch?v=T_F14GWYzZs Regards, John
Re: [ANNOUNCE] Please welcome Donald Woods as a new Geronimo committer
Congratulations Donald! Gianny On 28/03/2007, at 4:25 AM, Kevan Miller wrote: All, The Geronimo PMC is pleased to announce that Donald Woods has recently accepted our invitation to become an Apache Geronimo committer. Donald has been a long-term contributor to the Geronimo project and has provided valuable fixes and enhancements in a number of areas. We're looking forward to Donald joining our project. Congratulations and welcome to Donald! --kevan
Re: [ANNOUNCE] Please welcome Rakesh Midha as a new Geronimo committer
Congratulations Rakesh! Gianny On 28/03/2007, at 4:30 AM, Kevan Miller wrote: All, The Geronimo PMC is pleased to announce that Rakesh Midha has recently accepted our invitation to become an Apache Geronimo committer. Rakesh has contributed a number of significant enhancements to our Admin Console and deployment code. We're looking forward to Rakesh joining our project. Congratulations and welcome to Rakesh! --kevan
[jira] Closed: (GERONIMO-3031) Install New Applications
[ https://issues.apache.org/jira/browse/GERONIMO-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3031. --- Resolution: Fixed Fix Version/s: 2.0-M4 Assignee: David Jencks Regression: [Regression] Fixed by David J. Install New Applications Key: GERONIMO-3031 URL: https://issues.apache.org/jira/browse/GERONIMO-3031 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M4 Environment: Revision: 523021 Reporter: Hernan Cunico Assigned To: David Jencks Fix For: 2.0-M4 Attachments: jetty_error.txt, tomcat_error.txt Both Jetty and Tomcat fail to install web applications via the Console, deploying the same app from the command line works OK -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-905) message filter registers predicates as mbean as well as a new predicate for on/off filtering
message filter registers predicates as mbean as well as a new predicate for on/off filtering Key: SM-905 URL: https://issues.apache.org/activemq/browse/SM-905 Project: ServiceMix Issue Type: New Feature Components: servicemix-eip Reporter: Thomas Termin Priority: Minor Attachments: eip-message-filter.patch Predicat MBeans are registered exactly as the endpoint just with the extension Predicate Interessting is the message filter which do all with reflection and just register predicates if an MBean interface is implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: I'm now a dad !
Congratulations John!!! I wish you and your family the very best. Anita --- John Sisson [EMAIL PROTECTED] wrote: On Tuesday 27th of March at 11am I became the proud father of our first child, a baby girl, Jasmine Mae Sisson, weighing 3.6 kilos ( 7.92 pounds). Lisa and Jasmine are doing well, although now very tired. http://www.youtube.com/watch?v=T_F14GWYzZs Regards, John Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097
Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
That's my understanding ... you are so much more articulate than I :) On Mar 29, 2007, at 7:30 AM, Rick McGuire wrote: Matt Hogstrom wrote: What is the alternate proposal? I suspect it should follow the more normal convention of name of what it is followed by the version identifier. For specs, the name of the spec artifact frequently contains a version identifier for the level of the spec. For example the javamail specs have names such as this: geronimo-javamail_1.3.1_spec-1.3 This indicates that this is an implementation of the javamail 1.3.1 specification, and the Geronimo version level is 1.3. So, what's the version level vs. specification level of the above artifact? Is this an implementation of the 1.1MR3 leve of the javaee deployment spec? Then it is missing its version identifier all together. It should be something like geronimo-javaee-deployment_1.1MR3_spec-1.0 Or is this the MR3 version of the javaee deployment spec version 1.1? Then this should be geronimo-javaee-deployment_1.1_spec-MR3 Or, is the version identifier actually the full 1.1_MR3, in which case it should be geronimo-javaee-deployment_spec-1.1MR3 In all cases, the version level of the artifact is the last element of the artifact name. Rick On Mar 28, 2007, at 5:02 PM, Jason Dillon wrote: I really hate that we have version information in artifactIds... this is a huge PITA when the version needs to be changed. This is a *very* bad practice. Can we please stop this madness? --jason
Re: Tomcat m2 repo?
Jason Dillon wrote: On Mar 27, 2007, at 4:50 PM, Filip Hanik - Dev Lists wrote: I don't expect that Tomcat will switch to m2, though if they are gonna be publishing m2 repos they should use the m2 antlib for that. But, looks like the m2 antlib is not up to snuff wrt the new? apache requirements to publish .asc files for releases. I think the antlib tasks probably need to be updated to allow extra files to be attached when install/deploying and then ant folks should be sorted... well, that and if they implement a task or macro to sign stuff. we're note even using the antlibs, they were not really working out. It was easier to just exec the mvn script directly. If Maven has the command line option to do what we want, then we can do it. Just curious, what wasn't working out with the antlibs? They should prolly be fixed if they are not usable by ant projects. So if you show me the $MAVEN_HOME/bin/mvn command to publish a single JAR(with a POM) and being able to make sure the signature goes with it, then we are fine. GPG signing is a no brainer, we can do that any day. Hrm... I'm not sure there exists such a command at the moment, though its probably easy enough to craft a simple goal to implement what you need. yeah, I might just implement this in ANT all together, and skip maven, if it is a simple SCP copy. The reason it doesn't work asis, is that the gpg .asc stuff is attached to the current projects artifact and the install/deploy will handle the primary artifact and then any attached artifacts separately. The install-file/deploy-file goals don't have a project to work on so there is nothing to attach to. I suppose that either install-file/deploy-file need to take an additional csv list of other files to attach or perhaps simply craft a pom.xml which uses build-helper:attach-artifact ( http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html ) and dance around mvn a little to make `mvn deploy` work. But, it would really be better IMO, to use the deploy task and update the task to have a nested set of attached-file elements which can be used to effectively behave the same as mvn would normally by deploying the primary artifact, and then any attached artifacts. Thats *much* less of a hack. Can you tell me why the antlib tasks aren't working for you? there were a few things 1. documentation or my inability to work with it 2. learning curve, I'm trying to do something really simple 3. SCP with maven on windows simply didn't work, turns out that it still doesn't work when using the command line arguments, so I am still running from linux. since all I wanna do is SCP a .jar .pom .md5 and .asc, why does this have to be so complicated :) if I can reverse engineer what it is Maven is doing when publishing a file to a repo, it will be easier for me to implement it in pure ant. Filip --jason --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007 2:31 PM
Re: svn commit: r518426 - in /geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel: classloader/ config/
David, the below change to IOUtil.java -
-return Collections.singleton(match.toURL());
+return Collections.singleton(match.toURI().normalize().toURL());
looks like it is causing the G3016 reported failure, that the server
will no longer start on Windows when there is a white space in the
GERONIMO_HOME path.
Was there some reason we need to normalize the URI before its converted
to a URL?
-Donald
[EMAIL PROTECTED] wrote:
Author: djencks
Date: Wed Mar 14 18:22:56 2007
New Revision: 518426
URL: http://svn.apache.org/viewvc?view=revrev=518426
Log:
GERONIMO-2693 eliminate most duplicate entries from getResources. This should
also produce only normailized urls. This should make jetty start quickly
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/JarFileClassLoader.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/UnionEnumeration.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/UrlResourceFinder.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/IOUtil.java
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/MultiParentClassLoader.java
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/JarFileClassLoader.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/JarFileClassLoader.java?view=diffrev=518426r1=518425r2=518426
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/JarFileClassLoader.java
(original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/JarFileClassLoader.java
Wed Mar 14 18:22:56 2007
@@ -184,6 +184,7 @@
/**
* [EMAIL PROTECTED]
*/
+/*
public Enumeration findResources(final String resourceName) throws
IOException {
// todo this is not right
// first get the resources from the parent classloaders
@@ -199,6 +200,15 @@
// join the two together
Enumeration resources = new UnionEnumeration(parentResources,
myResources);
return resources;
+}
+*/
+
+protected EnumerationURL internalfindResources(final String name) throws
IOException {
+return AccessController.doPrivileged(new
PrivilegedActionEnumerationURL() {
+public EnumerationURL run() {
+return resourceFinder.findResources(name);
+}
+}, acc);
}
/**
Modified:
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/UnionEnumeration.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/UnionEnumeration.java?view=diffrev=518426r1=518425r2=518426
==
---
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/UnionEnumeration.java
(original)
+++
geronimo/server/trunk/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/UnionEnumeration.java
Wed Mar 14 18:22:56 2007
@@ -24,14 +24,14 @@
/**
* @version $Rev$ $Date$
*/
-public final class UnionEnumeration implements Enumeration {
-private final LinkedList enumerations = new LinkedList();
+public final class UnionEnumerationT implements EnumerationT {
+private final LinkedListEnumerationT enumerations = new
LinkedListEnumerationT();
-public UnionEnumeration(List enumerations) {
+public UnionEnumeration(ListEnumerationT enumerations) {
this.enumerations.addAll(enumerations);
}
-public UnionEnumeration(Enumeration first, Enumeration second) {
+public UnionEnumeration(EnumerationT first, EnumerationT second) {
if (first == null) throw new NullPointerException(first is null);
if (second == null) throw new NullPointerException(second is null);
@@ -41,7 +41,7 @@
public boolean hasMoreElements() {
while (!enumerations.isEmpty()) {
-Enumeration enumeration = (Enumeration) enumerations.getFirst();
+Enumeration enumeration = enumerations.getFirst();
if (enumeration.hasMoreElements()) {
return true;
}
@@ -50,9 +50,9 @@
return false;
}
-public Object nextElement() {
+public T nextElement() {
while (!enumerations.isEmpty()) {
-Enumeration enumeration = (Enumeration) enumerations.getFirst();
+EnumerationT enumeration = enumerations.getFirst();
if
DB Viewer portlet error
Hi All, Just wondering if somebody else is seeing this problem. I create a new DB with the DB manager and the DB is created successfully but when I try to view that DB from the DB Viewer I get a portlet error. When I check the logs I get this: 09:57:02,421 ERROR [listTables_jsp]] Servlet.service() for servlet jsp.WEB_002dINF.view.internaldb.listTables_jsp threw exception javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Error getting connection: java.sql.SQLException: No suitable driver ... 09:57:02,421 ERROR [[DBViewer]] Servlet.service() for servlet DBViewer threw exception javax.servlet.ServletException ... 09:57:02,453 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... One interesting this is that I can still create a pool connection and test it (at creation time). But when I try to access that DB from an app I also get a connection error ResourceAllocationException: Unable to obtain physical connection to jdbc:derby:TestDB This is on the M4 branch, any ideas? Cheers! Hernan
[jira] Created: (GERONIMO-3042) Port of openejb corba classes was based on out-of-date original classes.
Port of openejb corba classes was based on out-of-date original classes. Key: GERONIMO-3042 URL: https://issues.apache.org/jira/browse/GERONIMO-3042 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: CORBA Affects Versions: 2.0-M5 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 2.0-M5 The snapshot used for the port of the openejb CORBA clases was a bit out of date, so some critical fixes are missing. The SocketFactory class is particularly back level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: I'm now a dad !
Congrats John!!! Best wishes and may the force be with you! ;-) Chris On 3/29/07, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Congratulations John!!! I wish you and your family the very best. Anita --- John Sisson [EMAIL PROTECTED] wrote: On Tuesday 27th of March at 11am I became the proud father of our first child, a baby girl, Jasmine Mae Sisson, weighing 3.6 kilos ( 7.92 pounds). Lisa and Jasmine are doing well, although now very tired. http://www.youtube.com/watch?v=T_F14GWYzZs Regards, John Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
This is not our version, its the version of the spec. IIRC we had a big discussion about the best spec naming convention and decided this was it. Despite our best intentions, we often end up releasing corrections to spec jars we've published. Can you suggest a different naming convention that will clearly and unambiguously show both the spec version and the geronimo version of a spec jar? Or do you think one of these is unnecessary? As you can probably tell, I think this is a very good practice. I hate it when someone says they depend on servlet.jar and I have to open the spec jar up and try to figure out if whoever generated it bothered to include any information at all about which spec version they implemented. thanks david jencks On Mar 28, 2007, at 2:02 PM, Jason Dillon wrote: I really hate that we have version information in artifactIds... this is a huge PITA when the version needs to be changed. This is a *very* bad practice. Can we please stop this madness? --jason
Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
artfifactId=geronimo-javaee-deployment_1.1MR3_spec version=1.0-SNAPSHOT (IIRC, but its' value is irrelevant) groupId=org.apache.geronimo.specs the spec version is 1.1MR3 It follows the agreed upon conventions for geronimo spec naming. thanks david jencks On Mar 29, 2007, at 4:30 AM, Rick McGuire wrote: Matt Hogstrom wrote: What is the alternate proposal? I suspect it should follow the more normal convention of name of what it is followed by the version identifier. For specs, the name of the spec artifact frequently contains a version identifier for the level of the spec. For example the javamail specs have names such as this: geronimo-javamail_1.3.1_spec-1.3 This indicates that this is an implementation of the javamail 1.3.1 specification, and the Geronimo version level is 1.3. So, what's the version level vs. specification level of the above artifact? Is this an implementation of the 1.1MR3 leve of the javaee deployment spec? Then it is missing its version identifier all together. It should be something like geronimo-javaee-deployment_1.1MR3_spec-1.0 Or is this the MR3 version of the javaee deployment spec version 1.1? Then this should be geronimo-javaee-deployment_1.1_spec-MR3 Or, is the version identifier actually the full 1.1_MR3, in which case it should be geronimo-javaee-deployment_spec-1.1MR3 In all cases, the version level of the artifact is the last element of the artifact name. Rick On Mar 28, 2007, at 5:02 PM, Jason Dillon wrote: I really hate that we have version information in artifactIds... this is a huge PITA when the version needs to be changed. This is a *very* bad practice. Can we please stop this madness? --jason
[jira] Closed: (GERONIMO-3042) Port of openejb corba classes was based on out-of-date original classes.
[ https://issues.apache.org/jira/browse/GERONIMO-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3042. -- Resolution: Fixed Committed revision 523732. Port of openejb corba classes was based on out-of-date original classes. Key: GERONIMO-3042 URL: https://issues.apache.org/jira/browse/GERONIMO-3042 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.0-M5 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 2.0-M5 The snapshot used for the port of the openejb CORBA clases was a bit out of date, so some critical fixes are missing. The SocketFactory class is particularly back level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: DB Viewer portlet error
Did you specify to include the appropriate derby jars as dependencies when you created the module? The tranql connectors don't include the derby jars you need, you have to depend on them for each db pool you set up. thanks david jencks On Mar 29, 2007, at 7:22 AM, Hernan Cunico wrote: Hi All, Just wondering if somebody else is seeing this problem. I create a new DB with the DB manager and the DB is created successfully but when I try to view that DB from the DB Viewer I get a portlet error. When I check the logs I get this: 09:57:02,421 ERROR [listTables_jsp]] Servlet.service() for servlet jsp.WEB_002dINF.view.internaldb.listTables_jsp threw exception javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Error getting connection: java.sql.SQLException: No suitable driver ... 09:57:02,421 ERROR [[DBViewer]] Servlet.service() for servlet DBViewer threw exception javax.servlet.ServletException ... 09:57:02,453 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... One interesting this is that I can still create a pool connection and test it (at creation time). But when I try to access that DB from an app I also get a connection error ResourceAllocationException: Unable to obtain physical connection to jdbc:derby:TestDB This is on the M4 branch, any ideas? Cheers! Hernan
Re: DayTrader 1.2 (J2EE 1.4) on Glassfish
Haven't gotten any feed back and just wanted to double check and see if there were any objections or concerns about applying these changes to the current Daytrader releases (1.2 and 2.0). Overall, there were 3 patches proposed... - Clean-up of deployment descriptors to remove zombies - Revision of Exceptions thrown by TradeServices interface and impl classes to adhere to spec - Addition of SunServer 9 vendor-specific DDs Chris On 3/23/07, Christopher Blythe [EMAIL PROTECTED] wrote: Since I've been working with Glassfish (Sun Server 9) and NetBeans a lot lately, I wanted to see if I could get DayTrader 1.2 running with minimal changes. To my chagrin, I was able to pull it off with only a few minor changes... - Added vendor specific DDs - Disabled web services components One of the cool features I found in NetBeans is a validation utility that combs through the ear to find spec violations. This utility pointed out some spec violations in the exception handling associated with the EJBs and some remnants of the one phase methods (that were removed) still in the ejb-jar.xml. Based on all of these, I have put together and attached three patch files. I have also attached the README (included in the patch) with details on how to build the ear and deploy the app on Sun Server 9. Just a small warning... the EJBs are based on defaults and do not have any type of locking characteristics configured (haven't had a chance to dig into their doc to figure out how to do this). I haven't had a chance to run this bad boy under load yet, so I have not idea how it will respond. Enjoy... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
Re: DayTrader 1.2 (J2EE 1.4) on Glassfish
On 3/29/07, Christopher Blythe [EMAIL PROTECTED] wrote: Haven't gotten any feed back and just wanted to double check and see if there were any objections or concerns about applying these changes to the current Daytrader releases (1.2 and 2.0). Overall, there were 3 patches proposed... If it doesn't break DT go ahead and commit the changes. If someone had objected you'd surely have heard it ;-) No complaints, the green light for the changes. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: DB Viewer portlet error
If it helps, I just tried with an external DB and it works. I can create and test a connection pool (just like before) and also access it via an application. This seems to be just around the embedded Derby. Cheers! Hernan Hernan Cunico wrote: I can deploy the pool just fine but it is the DB creation process the one I have no control. I use the DB manager to create a new DB, that DB is listed in the DB Viewer portlet, when I click that DB I get this error. At this point I only entered the name of a new DB I wanted to create, the rest is just mouse clicks ;-) So, when I get the portlet error (still in the DB Manager) I check the logs and see the ...java.sql.SQLException: No suitable driver ... If I create a connection pool, I will still be able to test the connection (at creation time) and deploy the pool via console (have not tried via command line yet). The pool gets successfully deployed but when I try to access that DB I get a weird error, like the DB does not exist. So this is kind of a second test to see if I can still access the DB (which I can't) but the main issue is that the DB Viewer portlet cannot display any DB content for other than the SystemDatabase. Cheers! Hernan David Jencks wrote: Did you specify to include the appropriate derby jars as dependencies when you created the module? The tranql connectors don't include the derby jars you need, you have to depend on them for each db pool you set up. thanks david jencks On Mar 29, 2007, at 7:22 AM, Hernan Cunico wrote: Hi All, Just wondering if somebody else is seeing this problem. I create a new DB with the DB manager and the DB is created successfully but when I try to view that DB from the DB Viewer I get a portlet error. When I check the logs I get this: 09:57:02,421 ERROR [listTables_jsp]] Servlet.service() for servlet jsp.WEB_002dINF.view.internaldb.listTables_jsp threw exception javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Error getting connection: java.sql.SQLException: No suitable driver ... 09:57:02,421 ERROR [[DBViewer]] Servlet.service() for servlet DBViewer threw exception javax.servlet.ServletException ... 09:57:02,453 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... One interesting this is that I can still create a pool connection and test it (at creation time). But when I try to access that DB from an app I also get a connection error ResourceAllocationException: Unable to obtain physical connection to jdbc:derby:TestDB This is on the M4 branch, any ideas? Cheers! Hernan
[BUILD] TRUNK: Failed for Revision: 523781
Building with Maven version: 2.0.5 Revision: 523781 built with tests skipped See the full build-1400.log file at http://people.apache.org/~prasad/binaries/20070329/build-1400.log [WARNING] Unable to get resource 'org.mortbay.jetty:jetty-sslengine:pom:6.1.2rc0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/mortbay/jetty/jetty-sslengine/6.1.2rc0/jetty-sslengine-6.1.2rc0.pom [WARNING] Unable to get resource 'org.mortbay.jetty:jetty-sslengine:pom:6.1.2rc0' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://repository.codehaus.org/org/mortbay/jetty/jetty-sslengine/6.1.2rc0/jetty-sslengine-6.1.2rc0.pom 2K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository//aopalliance/aopalliance/1.0/aopalliance-1.0.jar [WARNING] Unable to get resource 'aopalliance:aopalliance:jar:1.0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository//aopalliance/aopalliance/1.0/aopalliance-1.0.jar [WARNING] Unable to get resource 'aopalliance:aopalliance:jar:1.0' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://repository.codehaus.org/aopalliance/aopalliance/1.0/aopalliance-1.0.jar [WARNING] Unable to get resource 'aopalliance:aopalliance:jar:1.0' from repository codehaus (http://repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/aopalliance/aopalliance/1.0/aopalliance-1.0.jar 4K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-tools-common/2.0-incubator-RC-SNAPSHOT/cxf-tools-common-2.0-incubator-RC-20070326.204012-23.jar 166K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository//org/springframework/spring-beans/2.0/spring-beans-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-beans:jar:2.0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/springframework/spring-beans/2.0/spring-beans-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-beans:jar:2.0' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://repository.codehaus.org/org/springframework/spring-beans/2.0/spring-beans-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-beans:jar:2.0' from repository codehaus (http://repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/springframework/spring-beans/2.0/spring-beans-2.0.jar 357K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-rt-transports-http/2.0-incubator-RC-SNAPSHOT/cxf-rt-transports-http-2.0-incubator-RC-20070326.204012-18.jar 103K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-common-schemas/2.0-incubator-RC-SNAPSHOT/cxf-common-schemas-2.0-incubator-RC-20070326.204012-27.jar 45K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-rt-frontend-jaxws/2.0-incubator-RC-SNAPSHOT/cxf-rt-frontend-jaxws-2.0-incubator-RC-20070326.204012-18.jar 192K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository//org/apache/ws/commons/neethi/neethi/2.0/neethi-2.0.jar [WARNING] Unable to get resource 'org.apache.ws.commons.neethi:neethi:jar:2.0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/ws/commons/neethi/neethi/2.0/neethi-2.0.jar [WARNING] Unable to get resource 'org.apache.ws.commons.neethi:neethi:jar:2.0' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://repository.codehaus.org/org/apache/ws/commons/neethi/neethi/2.0/neethi-2.0.jar [WARNING] Unable to get resource 'org.apache.ws.commons.neethi:neethi:jar:2.0' from repository codehaus (http://repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/apache/ws/commons/neethi/neethi/2.0/neethi-2.0.jar 28K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-api/2.0-incubator-RC-SNAPSHOT/cxf-api-2.0-incubator-RC-20070326.204012-19.jar 193K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-rt-bindings-soap/2.0-incubator-RC-SNAPSHOT/cxf-rt-bindings-soap-2.0-incubator-RC-20070326.204012-18.jar 75K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository//org/springframework/spring-web/2.0/spring-web-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-web:jar:2.0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository
[jira] Created: (GERONIMO-3043) Default assembly CORBABeans cannot change listener port.
Default assembly CORBABeans cannot change listener port. Key: GERONIMO-3043 URL: https://issues.apache.org/jira/browse/GERONIMO-3043 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: CORBA Affects Versions: 2.0-M5 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 2.0-M5 It is not possible to simply change the listener port on the default CORBABean instance because is specifies an TLLConfig port and host value. The CORBABean should set the transport config values to whatever is configured on the bean so that the values match up correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3043) Default assembly CORBABeans cannot change listener port.
[ https://issues.apache.org/jira/browse/GERONIMO-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-3043. -- Resolution: Fixed Committed revision 523792. Default assembly CORBABeans cannot change listener port. Key: GERONIMO-3043 URL: https://issues.apache.org/jira/browse/GERONIMO-3043 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.0-M5 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 2.0-M5 It is not possible to simply change the listener port on the default CORBABean instance because is specifies an TLLConfig port and host value. The CORBABean should set the transport config values to whatever is configured on the bean so that the values match up correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
This is not our version, its the version of the spec. Its still a version number in an artifactId... regardless of who's version it is. The problem with this is that when you go to change versions you have to go update a bunch of poms to fix their artifactId instead of simply updating one dependency in a dependencyManagement section. Because we put version numbers in artifactIds we've given ourselves a lot more maintenance work when it comes time to rev specs and because of this we have made it far to easy to missing them and get modules out of sync. IIRC we had a big discussion about the best spec naming convention and decided this was it. So because of that its not something that can be changed? I really disagree with this practice. It really only make *more* maintenance work and increases the chances of something getting out of sync. Its far to easy to end up with several different versions of the same spec in a project because the normal maven version resolution can't figure out which one to use because of the version information encoded in artifact ids. Despite our best intentions, we often end up releasing corrections to spec jars we've published. Can you suggest a different naming convention that will clearly and unambiguously show both the spec version and the geronimo version of a spec jar? Or do you think one of these is unnecessary? I think that all relevant information can be encoded in the artifacts version. And I think that the geronimo version is mostly irrelevant, its basically a revision of the sun version, so I would just put a counter on the end of the sun version: specVersion-geroniomRev 1.0-1 This helps do away with inconsistencies which we have now, with picking 1.1 or 2.0 or 1.0m2 or whatever... just keep incrementing the revision when there are changes. Some real examples: current --- suggest (w/o version in artifactId): geronimo-j2ee-management_1.1_spec-1.0-M1.jar - geronimo-j2ee- management-spec-1.1-1.jar geronimo-j2ee-management_1.0_spec-1.0.jar - geronimo-j2ee-management- spec-1.0-1.jar geronimo-j2ee-management_1.0_spec-1.0.1.jar - geronimo-j2ee- management-spec-1.0-2.jar geronimo-j2ee-management_1.0_spec-1.1.jar - geronimo-j2ee-management- spec-1.0-3.jar As you can probably tell, I think this is a very good practice. I hate it when someone says they depend on servlet.jar and I have to open the spec jar up and try to figure out if whoever generated it bothered to include any information at all about which spec version they implemented. Well, lucky for you w/maven the version information is encoded in the jar file names by default. So its quite easy to just use the version of an artifact to contain all of the versioning details and you will end up with an artifact with that information in the filename. --jason
[jira] Commented: (GERONIMO-3011) Adjust port configuration for running multiple instances of geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485310 ] Anita Kulshreshtha commented on GERONIMO-3011: -- Openejb is using a hard coded value of 4200 for a port in ServiceDaemon: Name: service.admin [EMAIL PROTECTED] State: RUNNABLE Total blocked: 0 Total waited: 0 Stack trace: java.net.PlainSocketImpl.socketAccept(Native Method) java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) java.net.ServerSocket.implAccept(ServerSocket.java:450) java.net.ServerSocket.accept(ServerSocket.java:421) org.apache.openejb.server.ServiceDaemon.run(ServiceDaemon.java:155) java.lang.Thread.run(Thread.java:595) Could someone familiar with this code please explain how to make it configurable? Adjust port configuration for running multiple instances of geronimo Key: GERONIMO-3011 URL: https://issues.apache.org/jira/browse/GERONIMO-3011 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ, naming, OpenEJB Affects Versions: 2.0-M4 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Priority: Minor Fix For: 2.0-M4 Make the following changes to facilitate running multiple instances of geronimo on the same machine. 1. The port number for these GBeans should be configurable via config.xml: - EJBNetworkService - ActiveMQ.stomp.default 2. Change default RMI Naming port 3. Fix : Module 5/27 org.apache.geronimo.configs/openejb/2.0-SNAPSHOT/car 13:25:08,046 FATAL [remote] Service Start Failed: admin thread 127.0.0.1 420 0: Service failed to start.: Address already in use: JVM_Bind -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
On Mar 29, 2007, at 8:06 AM, David Jencks wrote: artfifactId=geronimo-javaee-deployment_1.1MR3_spec version=1.0-SNAPSHOT (IIRC, but its' value is irrelevant) groupId=org.apache.geronimo.specs the spec version is 1.1MR3 It follows the agreed upon conventions for geronimo spec naming. I think we should reconsider the convention. And use the artifacts version to contain *all* of the version information. Since the current convention's version is mostly irrelevant anyways, I suggest that we use the spec's version + revision number (counter) as the version. That makes the above look like: artfifactId=geronimo-javaee-deployment-spec groupId=org.apache.geronimo.specs version=1.1MR3-1-SNAPSHOT And when released the version would be: version=1.1MR3-1 This indicates the spec version and a revision count for how many update/iterations we have applied to it. When its time to make a new revision then we'd have: version=1.1MR3-2 And when the spec version changes to say 1.2, then we'd have: version=1.2-1 IMO this is *much* more natural and allows us to use the Maven dependencyManagement section to manage all version information effectively for child modules. --jason
Re: Fisheye for Apache Geronimo?
Cool! Many thanks. Please let us know what the URL is once it has been setup. AFAIK Infra is cool with this, I've not heard any objections as of yet. --jason On Mar 28, 2007, at 5:15 PM, Conor MacNeill wrote: Hi Jason, Sorry for the delay. I'll add this this weekend if it is cool with infra. Cheers Conor Jason Dillon wrote: Hi, I was wondering if it would be possible to get Fisheye setup for the Apache Geronimo tree? http://svn.apache.org/repos/asf/geronimo/ Fisheye is a wonderful tool and I believe that the Geronimo community would benefit greatly by having it available to us to grok our svn repository better. Is it possible to get this setup, similar to the openejb and servicemix folks? I, and most certainly the rest of the G community, would really appreciate it. :-) Thanks, --jason PS. Joe mentioned in #infra that I should just ping you and cc infra. If there is another channel I should use to get this done please let me know.
Re: Fisheye for Apache Geronimo?
Jason Dillon [EMAIL PROTECTED] writes: Cool! Many thanks. Please let us know what the URL is once it has been setup. AFAIK Infra is cool with this, I've not heard any objections as of yet. Actually I'd prefer it if Conor started with http://svn.apache.org/repos/asf/geronimo/server/ because /geronimo itself contains multiple projects, and we may need to go back to disallowing checkouts of /geronimo. -- Joe Schaefer
Re: Fisheye for Apache Geronimo?
On Mar 29, 2007, at 1:13 PM, Joe Schaefer wrote: Jason Dillon [EMAIL PROTECTED] writes: Cool! Many thanks. Please let us know what the URL is once it has been setup. AFAIK Infra is cool with this, I've not heard any objections as of yet. Actually I'd prefer it if Conor started with http://svn.apache.org/repos/asf/geronimo/server/ because /geronimo itself contains multiple projects, and we may need to go back to disallowing checkouts of /geronimo. That is fine with me for the initial setup... though really it would be good to get fisheye to give us a view over the entire project repo. * * * Aside from the first scan of the repo... is there much overhead after it has been setup? I mean after the first sync, would it matter so much that its http://svn.apache.org/repos/asf/geronimo/server or http://svn.apache.org/repos/asf/geronimo ? --jason
Re: Tomcat m2 repo?
On Mar 29, 2007, at 6:39 AM, Filip Hanik - Dev Lists wrote: Hrm... I'm not sure there exists such a command at the moment, though its probably easy enough to craft a simple goal to implement what you need. yeah, I might just implement this in ANT all together, and skip maven, if it is a simple SCP copy. You could do that, though IMO it would be a little better to just get the Maven antlib tasks fixed to allow you to attach artifacts... which I believe other projects will also need. The reason it doesn't work asis, is that the gpg .asc stuff is attached to the current projects artifact and the install/deploy will handle the primary artifact and then any attached artifacts separately. The install-file/deploy-file goals don't have a project to work on so there is nothing to attach to. I suppose that either install-file/deploy-file need to take an additional csv list of other files to attach or perhaps simply craft a pom.xml which uses build-helper:attach-artifact ( http:// mojo.codehaus.org/build-helper-maven-plugin/attach-artifact- mojo.html ) and dance around mvn a little to make `mvn deploy` work. But, it would really be better IMO, to use the deploy task and update the task to have a nested set of attached-file elements which can be used to effectively behave the same as mvn would normally by deploying the primary artifact, and then any attached artifacts. Thats *much* less of a hack. Can you tell me why the antlib tasks aren't working for you? there were a few things 1. documentation or my inability to work with it I understand what you mean... the docs are a bit hard to grok. Would have been nice to see docs in the same style as the Ant manual. 2. learning curve, I'm trying to do something really simple Its relatively simply, though there are a few wrinkles. First you need to make sure that the wagon provider that you are using is installed. For example, the Codehaus uses webdav, so for projects there they need to: artifact:install-provider artifactId=wagon-webdav version=1.0-beta-2/ But, for ASF projects you probably just want the ssh impl: artifact:install-provider artifactId=wagon-ssh version=1.0- beta-2/ Or perhaps the ssh-external version: artifact:install-provider artifactId=wagon-ssh-external version=1.0-beta-2/ I would recommend using wagon-ssh if you can so you don't have to worry about having any specific native executables on your path/etc. Then you need to configure the authentication in ~/.m2/settings.xml, which is the same which is used by Maven. If you follow the same server id's as the ASF pom does then somehing like: 8 ?xml version=1.0? settings servers server idapache.snapshots/id usernameYOUR_USERNAME/username directoryPermissions775/directoryPermissions filePermissions664/filePermissions /server server idapache.releases/id usernameYOUR_USERNAME/username directoryPermissions775/directoryPermissions filePermissions664/filePermissions /server /servers /settings 8 Obviously changing YOUR_USERNAME with what is appropriate for your account on people.apache.org. You will probably need to configure either a password or a passphrase for each of the server's depending on how you have configured access via SSH. And then you need pom's for each of your artifacts, and in those poms you should include a distributionManagement section to configure where to deploy to, like: 8 distributionManagement repository idapache.releases/id nameApache Release Distribution Repository/name urlscp://people.apache.org/www/people.apache.org/repo/ m2-ibiblio-rsync-repository/url /repository snapshotRepository idapache.snapshots/id nameApache Development Snapshot Repository/name urlscp://people.apache.org/www/people.apache.org/repo/ m2-snapshot-repository/url /snapshotRepository /distributionManagement 8 I'm not 100% sure, but the Maven antlib tasks _might_ use the normal parent pom inclusion bits, in which case all you need to do is make sure that your top-level pom uses the ASF pom as its parent: 8 parent groupIdorg.apache/groupId artifactIdapache/artifactId version4/version /parent 8 This should get the default distributionManagement configuration into your poms. And then you just need to artifact:deploy with a reference to the artifact's file and its pom. The artifact will be deployed with the version information in the referenced pom and will be deployed to either the repository or snapshotRepository as configured in the poms distributionManagement. 3. SCP with maven on windows simply didn't work, turns out that it still doesn't work when
Re: Tomcat m2 repo?
FYI the issue + patch to the tasks is here: http://jira.codehaus.org/browse/MANTTASKS-42 --jason On Mar 29, 2007, at 6:39 AM, Filip Hanik - Dev Lists wrote: Jason Dillon wrote: On Mar 27, 2007, at 4:50 PM, Filip Hanik - Dev Lists wrote: I don't expect that Tomcat will switch to m2, though if they are gonna be publishing m2 repos they should use the m2 antlib for that. But, looks like the m2 antlib is not up to snuff wrt the new? apache requirements to publish .asc files for releases. I think the antlib tasks probably need to be updated to allow extra files to be attached when install/deploying and then ant folks should be sorted... well, that and if they implement a task or macro to sign stuff. we're note even using the antlibs, they were not really working out. It was easier to just exec the mvn script directly. If Maven has the command line option to do what we want, then we can do it. Just curious, what wasn't working out with the antlibs? They should prolly be fixed if they are not usable by ant projects. So if you show me the $MAVEN_HOME/bin/mvn command to publish a single JAR(with a POM) and being able to make sure the signature goes with it, then we are fine. GPG signing is a no brainer, we can do that any day. Hrm... I'm not sure there exists such a command at the moment, though its probably easy enough to craft a simple goal to implement what you need. yeah, I might just implement this in ANT all together, and skip maven, if it is a simple SCP copy. The reason it doesn't work asis, is that the gpg .asc stuff is attached to the current projects artifact and the install/deploy will handle the primary artifact and then any attached artifacts separately. The install-file/deploy-file goals don't have a project to work on so there is nothing to attach to. I suppose that either install-file/deploy-file need to take an additional csv list of other files to attach or perhaps simply craft a pom.xml which uses build-helper:attach-artifact ( http:// mojo.codehaus.org/build-helper-maven-plugin/attach-artifact- mojo.html ) and dance around mvn a little to make `mvn deploy` work. But, it would really be better IMO, to use the deploy task and update the task to have a nested set of attached-file elements which can be used to effectively behave the same as mvn would normally by deploying the primary artifact, and then any attached artifacts. Thats *much* less of a hack. Can you tell me why the antlib tasks aren't working for you? there were a few things 1. documentation or my inability to work with it 2. learning curve, I'm trying to do something really simple 3. SCP with maven on windows simply didn't work, turns out that it still doesn't work when using the command line arguments, so I am still running from linux. since all I wanna do is SCP a .jar .pom .md5 and .asc, why does this have to be so complicated :) if I can reverse engineer what it is Maven is doing when publishing a file to a repo, it will be easier for me to implement it in pure ant. Filip --jason --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.18/734 - Release Date: 3/26/2007 2:31 PM
[jira] Closed: (GERONIMO-3021) Annotated field/method does not get injected when overwrite specified in DD
[ https://issues.apache.org/jira/browse/GERONIMO-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3021. -- Resolution: Invalid Fix Version/s: 2.0-M4 Looking deeper into the code, we already are overriding injections. The problem Jarek was seeing turned out to be caused by the app client injection code not complaining when an injection failed. Annotated field/method does not get injected when overwrite specified in DD --- Key: GERONIMO-3021 URL: https://issues.apache.org/jira/browse/GERONIMO-3021 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Jarek Gawor Assigned To: David Jencks Fix For: 2.0-M4 When DD contains an overwrite for an annotated field, the field value does not get injected. The DD does _not_ specify the injection-target element, which is needed for the value to be injected. I'm not sure what's the right behavior should be in this case: should the injection-target element be added to the DD overwrite? or should the DD overwrite be left as is (and therefore the field would not get injected)? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
For what it's worth, Jason's proposal sounds reasonable to me*. But I don't really fancy changing all the current names either. :) Thanks, Aaron * Well, I can't say that 1.1MR3-1-SNAPSHOT made sense at first glance, but the 1.1MR3-1 followed by 1.1MR3-2 seems clear. On 3/29/07, Jason Dillon [EMAIL PROTECTED] wrote: On Mar 29, 2007, at 8:06 AM, David Jencks wrote: artfifactId=geronimo-javaee-deployment_1.1MR3_spec version=1.0-SNAPSHOT (IIRC, but its' value is irrelevant) groupId=org.apache.geronimo.specs the spec version is 1.1MR3 It follows the agreed upon conventions for geronimo spec naming. I think we should reconsider the convention. And use the artifacts version to contain *all* of the version information. Since the current convention's version is mostly irrelevant anyways, I suggest that we use the spec's version + revision number (counter) as the version. That makes the above look like: artfifactId=geronimo-javaee-deployment-spec groupId=org.apache.geronimo.specs version=1.1MR3-1-SNAPSHOT And when released the version would be: version=1.1MR3-1 This indicates the spec version and a revision count for how many update/iterations we have applied to it. When its time to make a new revision then we'd have: version=1.1MR3-2 And when the spec version changes to say 1.2, then we'd have: version=1.2-1 IMO this is *much* more natural and allows us to use the Maven dependencyManagement section to manage all version information effectively for child modules. --jason
Re: [jira] Commented: (GERONIMO-3011) Adjust port configuration for running multiple instances of geronimo
These are the contents of META-INF/o.a.openejb.server.ServerService/admin in openejb-server...jar: server = org.apache.openejb.server.admin.AdminDaemon bind= 127.0.0.1 port= 4200 disabled= false threads = 1 only_from = localhost Is this being used in Geronimo? Thanks Anita --- Anita Kulshreshtha (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/GERONIMO-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485310 ] Anita Kulshreshtha commented on GERONIMO-3011: -- Openejb is using a hard coded value of 4200 for a port in ServiceDaemon: Name: service.admin [EMAIL PROTECTED] State: RUNNABLE Total blocked: 0 Total waited: 0 Stack trace: java.net.PlainSocketImpl.socketAccept(Native Method) java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) java.net.ServerSocket.implAccept(ServerSocket.java:450) java.net.ServerSocket.accept(ServerSocket.java:421) org.apache.openejb.server.ServiceDaemon.run(ServiceDaemon.java:155) java.lang.Thread.run(Thread.java:595) Could someone familiar with this code please explain how to make it configurable? Adjust port configuration for running multiple instances of geronimo Key: GERONIMO-3011 URL: https://issues.apache.org/jira/browse/GERONIMO-3011 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ, naming, OpenEJB Affects Versions: 2.0-M4 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Priority: Minor Fix For: 2.0-M4 Make the following changes to facilitate running multiple instances of geronimo on the same machine. 1. The port number for these GBeans should be configurable via config.xml: - EJBNetworkService - ActiveMQ.stomp.default 2. Change default RMI Naming port 3. Fix : Module 5/27 org.apache.geronimo.configs/openejb/2.0-SNAPSHOT/car 13:25:08,046 FATAL [remote] Service Start Failed: admin thread 127.0.0.1 420 0: Service failed to start.: Address already in use: JVM_Bind -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265
Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
On Mar 29, 2007, at 6:35 PM, Aaron Mulder wrote: For what it's worth, Jason's proposal sounds reasonable to me*. But I don't really fancy changing all the current names either. :) I don't really want to change them (ie the work)... but I feel very strong about getting rid of that version muck in the artifactId. * Well, I can't say that 1.1MR3-1-SNAPSHOT made sense at first glance, but the 1.1MR3-1 followed by 1.1MR3-2 seems clear. Ya, seems weird at first, but I was just mapping David's example, which was for a SNAPSHOT ;-) --jason On 3/29/07, Jason Dillon [EMAIL PROTECTED] wrote: On Mar 29, 2007, at 8:06 AM, David Jencks wrote: artfifactId=geronimo-javaee-deployment_1.1MR3_spec version=1.0-SNAPSHOT (IIRC, but its' value is irrelevant) groupId=org.apache.geronimo.specs the spec version is 1.1MR3 It follows the agreed upon conventions for geronimo spec naming. I think we should reconsider the convention. And use the artifacts version to contain *all* of the version information. Since the current convention's version is mostly irrelevant anyways, I suggest that we use the spec's version + revision number (counter) as the version. That makes the above look like: artfifactId=geronimo-javaee-deployment-spec groupId=org.apache.geronimo.specs version=1.1MR3-1-SNAPSHOT And when released the version would be: version=1.1MR3-1 This indicates the spec version and a revision count for how many update/iterations we have applied to it. When its time to make a new revision then we'd have: version=1.1MR3-2 And when the spec version changes to say 1.2, then we'd have: version=1.2-1 IMO this is *much* more natural and allows us to use the Maven dependencyManagement section to manage all version information effectively for child modules. --jason
Re: Fisheye for Apache Geronimo?
Thank you very much :-) --jason On Mar 29, 2007, at 7:22 PM, Conor MacNeill wrote: I'll start with the Server project and see how we go from there. I'll start on the weekend. At the throttled rate, I assume it will take more than the weekend to index. Let me know if you are happy to let it run on at the throttled rate or you want me to restrict it to weekends. All Apache FishEye instances are now on a dedicated FishEye instance http://fisheye6.cenqua.com/ I've set up the project definition just now but it is not enabled yet. We set the refresh period to 2 hours for Apache repos, keep the restrictive throttle in place and prohibit all robots so the load after initial scan should be quite small - Joe can give a better picture. Conor On 30/03/07, Jason Dillon [EMAIL PROTECTED] wrote: On Mar 29, 2007, at 1:13 PM, Joe Schaefer wrote: Jason Dillon [EMAIL PROTECTED] writes: Cool! Many thanks. Please let us know what the URL is once it has been setup. AFAIK Infra is cool with this, I've not heard any objections as of yet. Actually I'd prefer it if Conor started with http://svn.apache.org/repos/asf/geronimo/server/ because /geronimo itself contains multiple projects, and we may need to go back to disallowing checkouts of /geronimo. That is fine with me for the initial setup... though really it would be good to get fisheye to give us a view over the entire project repo. * * * Aside from the first scan of the repo... is there much overhead after it has been setup? I mean after the first sync, would it matter so much that its http://svn.apache.org/repos/asf/geronimo/server or http://svn.apache.org/repos/asf/geronimo ? --jason
[jira] Commented: (GERONIMO-2988) Axis2: needs to support optional wsdl file
[ https://issues.apache.org/jira/browse/GERONIMO-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485403 ] Lin Sun commented on GERONIMO-2988: --- Initial code to hook up the wsgen tool for POJO.Used sun's private API WSToolsObjectFactory.wsgen to invoke the tool. The wsgen tool runs inside of the kernel during axis2 web service deployment time so I have to upgrade the geronimo-axis2-builder's pom.xml and axis2 config's pom.xml for the additional dependencies that wsgen needs. And I had to pass the classpath parameter to the WSToolsObjectFactory.wsgen call as well in order to run the tool successfully inside of Axis2Builder. (spent big time on CNF, CDNF issues...:-( ) I have performed the test (regular and hot deployment) and able to see the .wsdl and .xsd generated upon deployment of jaxws-war. The generated files are removed when undeployment command is issued. One remaining issue is the tool needs jdk_home\lib\tools.jar at runtime otherwise classdefnotfound error will be thrown. One workaround I have is to put the jar in my .m2 repo and update the axis2 config's pom.xml to pick it up. This is a temp solution before I find a better way thus I have commented this in the pom.xml to avoid any build break. Also need to update the code for EJB - didn't expect much extra work there but since EJB is completely broken (G3030) I didn't attempt to do it. Can someone please review it? Thanks a lot Lin Axis2: needs to support optional wsdl file -- Key: GERONIMO-2988 URL: https://issues.apache.org/jira/browse/GERONIMO-2988 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Reporter: Lin Sun Fix For: 2.0-M5 When wsdl file is not created, the axis2 currently uses WSDL2Java tool to generate the schema but the tool doesn't process annotation yet! The alternative is to use the wsgen tool provided by sun before Axis2 provides a tool to generate the schema from annotation. There is code that writes out a web.xml to disk when web.xml is not there and we may be able to use some of the code there. The idea is to write a generated wsdl file on disk based on java classes and remove the wsdl file when the app is undeployed. 3 deployment scenarios need to be supported - 1) regular deployment 2) in place deployment 3) hot deployment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2988) Axis2: needs to support optional wsdl file
[ https://issues.apache.org/jira/browse/GERONIMO-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-2988: -- Attachment: G2988.patch Axis2: needs to support optional wsdl file -- Key: GERONIMO-2988 URL: https://issues.apache.org/jira/browse/GERONIMO-2988 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Reporter: Lin Sun Fix For: 2.0-M5 Attachments: G2988.patch When wsdl file is not created, the axis2 currently uses WSDL2Java tool to generate the schema but the tool doesn't process annotation yet! The alternative is to use the wsgen tool provided by sun before Axis2 provides a tool to generate the schema from annotation. There is code that writes out a web.xml to disk when web.xml is not there and we may be able to use some of the code there. The idea is to write a generated wsdl file on disk based on java classes and remove the wsdl file when the app is undeployed. 3 deployment scenarios need to be supported - 1) regular deployment 2) in place deployment 3) hot deployment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: how to get the geronimo server path and find a few jars from repo?
Hi Dims, I just submitted a patch to G2988. Please let me know if you have any questions. P.S thanks a bunch for reviewing and committing my patch for G2977. Hi David, thanks for your suggestion. I used the Repository to find the path of the artifacts I need. Lin Davanum Srinivas wrote: Lin, Can you please upload your diff to the JIRA issue? and the url to where you picked up the jaxws ri jar thanks, dims On 3/28/07, Lin Sun [EMAIL PROTECTED] wrote: A bit update here... So I put the tools.jar from JDK_home\lib to my .m2 repo and updated the axis2 config pom.xml file to have that as a dependency. I am able to pass this error and run the wsgen tools now inside of Axis2Builder(with some hardcoded values). I don't think that is the right way to do things so could someone suggest a better way to load a jar that is not in the repo? Thanks, Lin Lin Sun wrote: Hi David, Thanks for your reply! Yes I am basically invoking the WSToolsObjectFactory.wsgen from Axis2Builder, which will be invoked during deployment of the module when .wsdl isn't provided for the service endpoint impl class. I've build my classpath String (hardcoded values for now) as I need it to pass into the WSToolsObjectFactory.wsgen call, and I think it is running in geronimo kernel (see exception below). But the kernel still needs to load the jar files. For instance, the wsgen tool needs the JDK_home\lib\tools.jar from SUN's JDK, and the kernel doesn't seem to have it loaded so I kept getting a CNF error from the AnnotationProcessorFactory class in the tools.jar. How do I load a jar from JDK in the kernel? 09:50:45,484 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: com/sun/mirror/apt/AnnotationProcessorFactory at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200( JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFi leClassLoader.java:308) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(J arFileClassLoader.java:260) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:299) Thanks again, Lin David Jencks wrote: On Mar 22, 2007, at 2:06 PM, Lin Sun wrote: Hi there, I am trying to build a classpath string for the wsgen tools. Basically, I need to use a few sun jars, a few geronimo spec jars and a few axis2 jars and the module from the repository to build the classpath string. And I am trying to do this from Axis2Builder. Jarek mentioned to me that I might be able to use configuration manager that can help me find the jars automatically if I just give it the group and actifact id. Could someone shed some light on how to use that? If there isn't such a manager avail, what is the best way to get the geronimo server path so that I can find the jars from the path myself? ServerInfo can get you the server locations, but if there are lots of repositories installed that won't do you much good. If you have a Repository and an artifactId you can get the File location You might be able to travel through the ConfigurationManager to various ConfigurationStores and eventually end up with a classpath, but I wonder if it would be possible and/or simpler to run the tool in a geronimo kernel and use our classloaders? thanks david jencks Thanks a lot Lin
[jira] Created: (GERONIMO-3044) Common Libs portlet does not split the file name correctly on linux
Common Libs portlet does not split the file name correctly on linux --- Key: GERONIMO-3044 URL: https://issues.apache.org/jira/browse/GERONIMO-3044 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.2, 2.0-M4, 2.0-M5 Reporter: Jay D. McHugh Priority: Minor Determining the appropriate path delimiter doesn't work - so every path is split as though it is on windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3044) Common Libs portlet does not split the file name correctly on linux
[ https://issues.apache.org/jira/browse/GERONIMO-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3044: Attachment: geronimo-3044.patch Common Libs portlet does not split the file name correctly on linux --- Key: GERONIMO-3044 URL: https://issues.apache.org/jira/browse/GERONIMO-3044 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 2.0-M4, 2.0-M5 Reporter: Jay D. McHugh Priority: Minor Attachments: geronimo-3044.patch Determining the appropriate path delimiter doesn't work - so every path is split as though it is on windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
Unable to run jax-rpc war test with Axis2 - Key: GERONIMO-3045 URL: https://issues.apache.org/jira/browse/GERONIMO-3045 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: 1.5 SUN SDK + WIN XP Reporter: Lin Sun Fix For: 2.0-M5 When running the jax-rpc war test with axis2, both test failed due to an exception thrown when parseWebServiceDescriptor is called. from reading the code, if webservices.xml doesn't exist, we call discoverwebservices, which will check if the class has annotation. if webservices.xml exists, we 'll just call parseWebServiceDescriptor, which caused the error for axis2 because axis2 moved to xbeans. The fix is to check if annotation exists when webservices.xml exists also. Tested the fix and able to pass the 2 jax-rpc war test test with them. Will attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-3045: -- Attachment: G3045.patch Jarek, Could you please review and (possibly) commit this? Thanks, Lin Unable to run jax-rpc war test with Axis2 - Key: GERONIMO-3045 URL: https://issues.apache.org/jira/browse/GERONIMO-3045 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: 1.5 SUN SDK + WIN XP Reporter: Lin Sun Fix For: 2.0-M5 Attachments: G3045.patch When running the jax-rpc war test with axis2, both test failed due to an exception thrown when parseWebServiceDescriptor is called. from reading the code, if webservices.xml doesn't exist, we call discoverwebservices, which will check if the class has annotation. if webservices.xml exists, we 'll just call parseWebServiceDescriptor, which caused the error for axis2 because axis2 moved to xbeans. The fix is to check if annotation exists when webservices.xml exists also. Tested the fix and able to pass the 2 jax-rpc war test test with them. Will attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3046) When starting Daytrader after deploy on 2.0-SNAPSHOT ejb-jar is started before its dependencies have been started
When starting Daytrader after deploy on 2.0-SNAPSHOT ejb-jar is started before its dependencies have been started - Key: GERONIMO-3046 URL: https://issues.apache.org/jira/browse/GERONIMO-3046 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M4, 2.0-M5 Reporter: Matt Hogstrom Assigned To: Dain Sundstrom Fix For: 2.0-M4 Testing deployment of Daytrader on Geronimo 2.0 - M4 (as well as trunk) the dt-ejb.jar is started before the messaging component it depends on. As a consequence, startup of the application fails as a dependent resource (a messaging queue) is not found. Talked to Dain about this and he thinks he knows where this needs to be addressed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JPA Usability in Geronimo
Jacek Laskowski wrote: On 3/29/07, Jay D. McHugh [EMAIL PROTECTED] wrote: 1) View of loaded persistence units (tree format with persistable classes under each unit) 2) View of loaded persistence units detailing their properties (back-end database, transaction mode, ...) ... Anyone else have wishlists for JPA? If both were available in Geronimo, I'd be the happiest man in the world! Are you going to give them a shot? Great! Looking forward to presenting them at one of the upcoming conferences. I can imagine how furious the audience is going to be when they're showcased. Still we are not yet there with Cayenne work and hoping to have a go in this week end (GERONIMO-2898). If somebody is willing to contribute it more than welcome :-) . Thanks, Lasantha Jacek
What is the Java Version for building source code?
Hi, What is the recommended Java version to be used with building G from source code? At the moment I am having a problem of building G from source code (maven build fails with complaining incompatible Java version). Following is my JDK information. java version 1.5.0_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode) Anyway I managed to build the source code after commenting out one line in the pom.xml :-) . Thanks, Lasantha
Re: What is the Java Version for building source code?
On 3/30/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote: Hi, What is the recommended Java version to be used with building G from source code? At the moment I am having a problem of building G from source code (maven build fails with complaining incompatible Java version). Following is my JDK information. java version 1.5.0_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode) $ java -version java version 1.5.0_11 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing) That's what I'm using with no issues. I don't think it's the version of Java you're using. Make sure that M2 doesn't grab other version available on your system. 1.5.* should be fine (I haven't looked at the plugin's code, though. It's been a while when I did). Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Fisheye for Apache Geronimo?
I'll start with the Server project and see how we go from there. I'll start on the weekend. At the throttled rate, I assume it will take more than the weekend to index. Let me know if you are happy to let it run on at the throttled rate or you want me to restrict it to weekends. All Apache FishEye instances are now on a dedicated FishEye instance http://fisheye6.cenqua.com/ I've set up the project definition just now but it is not enabled yet. We set the refresh period to 2 hours for Apache repos, keep the restrictive throttle in place and prohibit all robots so the load after initial scan should be quite small - Joe can give a better picture. Conor On 30/03/07, Jason Dillon [EMAIL PROTECTED] wrote: On Mar 29, 2007, at 1:13 PM, Joe Schaefer wrote: Jason Dillon [EMAIL PROTECTED] writes: Cool! Many thanks. Please let us know what the URL is once it has been setup. AFAIK Infra is cool with this, I've not heard any objections as of yet. Actually I'd prefer it if Conor started with http://svn.apache.org/repos/asf/geronimo/server/ because /geronimo itself contains multiple projects, and we may need to go back to disallowing checkouts of /geronimo. That is fine with me for the initial setup... though really it would be good to get fisheye to give us a view over the entire project repo. * * * Aside from the first scan of the repo... is there much overhead after it has been setup? I mean after the first sync, would it matter so much that its http://svn.apache.org/repos/asf/geronimo/server or http://svn.apache.org/repos/asf/geronimo ? --jason
geronimo-web-builder geronimo-web-2.5-builder
Why do we still have both of these modules? Looks like geronimo-web- builder is commented out of the build. Can we remove it? --jason
[jira] Created: (SM-911) JDBCComponent: The first column index is 1 in a result from sql query (non zero)
JDBCComponent: The first column index is 1 in a result from sql query (non zero)
Key: SM-911
URL: https://issues.apache.org/activemq/browse/SM-911
Project: ServiceMix
Issue Type: Bug
Components: servicemix-components
Affects Versions: 3.1
Environment: apache-servicemix-3.1-incubating
database: mysql (with mysql-connector-java-5.0.3 driver)
Reporter: Jorge RodrÃguez Pedrianes
Fix For: 3.1.1
The first column index in a result from a sql query to database is 1, non 0.
So,
1) in 'getUniqueColumnNames()' method, when we want to get column names from
'metaData' result, we must to start the count in i = 1
[ * metaData.getColumnName(i ); --- the first column is 1, the second
column is 2...] :
BUG:
{noformat}
for (int i = 0; i metaData.getColumnCount(); i++)
{noformat}
IT SHOULD BE:
{noformat}
for (int i = 1; i = metaData.getColumnCount(); i++) {
{noformat}
2) in 'toXmlSource()' method:
BUG:
{noformat}
for (int i=1; i=colCount; i++) {
buff.append(colNames[i].toLowerCase() + =' + rs.getString(i) + ' );
{noformat}
IT SHOULD BE:
{noformat}
for (int i=0; icolCount; i++) {
buff.append(colNames[i].toLowerCase() + =' + rs.getString(i + 1) + '
);
-- index in 'colNames' starts in 0 and index in
'rs' starts in 1
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
