[jira] Reopened: (SM-871) Optimize EndpointSupport.getKey, EndpointSupport.getUniqueKey, MessageExchange.setMessage, and DeliveryChannel.getKeyForExchange
[ https://issues.apache.org/activemq/browse/SM-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened SM-871: Optimize EndpointSupport.getKey, EndpointSupport.getUniqueKey, MessageExchange.setMessage, and DeliveryChannel.getKeyForExchange Key: SM-871 URL: https://issues.apache.org/activemq/browse/SM-871 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-871) Optimize wsdl-first example
[ https://issues.apache.org/activemq/browse/SM-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SM-871: --- Component/s: (was: servicemix-core) Summary: Optimize wsdl-first example (was: Optimize EndpointSupport.getKey, EndpointSupport.getUniqueKey, MessageExchange.setMessage, and DeliveryChannel.getKeyForExchange) Optimize wsdl-first example --- Key: SM-871 URL: https://issues.apache.org/activemq/browse/SM-871 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-871) Optimize wsdl-first example
[ https://issues.apache.org/activemq/browse/SM-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-871. Resolution: Fixed URL: http://svn.apache.org/viewvc?view=revrev=515740 URL: http://svn.apache.org/viewvc?view=revrev=515741 URL: http://svn.apache.org/viewvc?view=revrev=515748 Optimize wsdl-first example --- Key: SM-871 URL: https://issues.apache.org/activemq/browse/SM-871 Project: ServiceMix Issue Type: Improvement Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Questions for Axis2 folks re: JAXWS
Please read my in line comments.
Thanks,
Lasantha
Lin Sun wrote:
I have been giving some thoughts on this prob yesterday. By looking
at the java comments for AxisService.createService, it seems this
method is only for RPCMessageReceiver, but we are using
JAXWSMessageReceiver here. Maybe dims or Lasantha can comment on this.
I don't think using JAXWSMessageReciever is a problem here (according to
the way JAXWS samples works with Axis2). Do you have a better solution
for it?
seems there are 2 scenarios:
1) no webservices.xml, no .wsdl, just java files with annotation:
One solution I can think of is to create a temp wsdl file when
Axis2Builder is called based on the java files (seems this can be done
either using the Java2WSDLCodegenEngine from Axis2 or using Sun's
tools), and then set PortInfo properties there. When
Axis2WebServiceContainer is called, we'll treat it as wsdl file
already exists. Delete the temp wsdl file at the end.
Can't we directly let the Axis2 handle the problem rather than handling
it from G side (do we need to do some processing in G side) ?
2) no webservices.xml, just .wsdl and java files with annotation.
In this case, since there is no webservices.xml, should we scan the
module to see if .wsdl file is included in Axis2Builder? if so, set
the wsdl-file property in PortInfo.
I haven't implemented anything yet as I think we should all agree to a
solution first.
Lin
Jeff Genender wrote:
o.a.g.Axis2WebserviceContainer, line 99. A not-filled in PortInfo is
passed in since G is not processing a WebService annotation, and thus an
AxisService.create is called on line 104.
When Axis2WebserviceContainer.getWsdl() is ultimately called,
doService2() is called (line 212), then to processGetRequest (line 398),
leading us to line 435 where the PortInfo is checked as to whether a
wsdl file has been passed in or not. If it has, it spits out the wsdl.
If it has not, then the AxisService.printWsdl() is called and that call
spits out a generated wsdl.
The crux here is that the PortInfo object does not have all of the info
filled in such as seiClass, wsdl file, etc. That stuff would have been
gotten from examining the WebService annotation.
The question is, where does that examination or, should that
examination, take place? Geronimo or Axis2?
Jeff
Lasantha Ranaweera wrote:
Jeff,
Sorry for a late reply due to my time stamp difference and don't know
exactly you have solved this problem right now or not. Anyway here
is my
comment.
Since you haven't given me exact source code I won't be able to point
you in to the exact source code in the Axis2. May be remote debugging
... ;-) .
Thanks,
Lasantha
Jeff Genender wrote:
Ok...
I am pretty certain at this stage that the WebService annotation is
not
getting processed. Can you point me to the code that handles this in
Axis2?
Thanks,
Jeff
Jeff Genender wrote:
Thanks...this is very helpful.
Then by this, looking at the PortInfo, it appears as though it is not
stuffing in the WSDL file, which tells me it's a G thang ;-)
Jeff
Lasantha Ranaweera wrote:
Hi Jeff,
To my understanding if we have given a WSDL in an archive it
should get
the priority than the information in the annotations.
In Axis2 integration there are two parts of implementation with
one for
with WSDL which is mainly handling by G side while with annotations
from
Axis2. For me it is something missing in G side.
Somebody in the list please correct me if I am wrong here .
Thanks,
Lasantha
Jeff Genender wrote:
Hi,
I have noticed when I deploy a war file (with a WSDL), I have a
certain
target name specified both in the WSDL and in the code that uses a
WebService annotation.
However, when I go retrieve the WSDL, I notice the target name
seems to
be munged according to the package name (backwards) of the code
that
contains the WebService annotation.
Example...
I have include a WSDL called Hello.wsdl that is in the war file
in the
web-inf/wsdl directory and starts with:
wsdl:definitions targetNamespace=http://example.com/hello/xsd;
...
I have a HelloWorld.java that has this:
package test.mypackage;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService(name=HelloWorld, targetNamespace =
http://example.org/hello/xsd;)
public class HelloWorld {
@WebMethod
public String sayHello(String me){
return Hello +me;
}
}
However, when I request the wsdl...I get something like this:
wsdl:definitions targetNamespace=http://mypackage.test/xsd;
...
Notice the targetnamespace was munged and changed from it's
originally
declared namespace of http://example.com/hello/xsd;. I want
the one
that is both declared in the included wsdl (or the one declared
in the
annotation).
Is this a facet of Axis2 or is Geronimo not passing a proper
PortInfo
object with the necessary stuff filled in?
Any light on this subject would be greatly appreciated ;-)
Thanks,
Jeff
Error adding HTTPS Listener
Hi All, As part of my documentation work, I'm currently upgrading Certificate Properties File Realm as a part of adminstering certificates to v2.0 M3. I have a couple of issues right now. The following tasks have been done without any problem with the help of existing CA in Geronimo. Create keystore and certificate Create a Certificate Signing Request (CSR) and import CA reply Import trusted certificates But when it comes to Adding an HTTPS listener with client authentication I keep getting an error for both Jetty and Tomcat (two different errors). Thanks Karthiga Jetty error 10:48:09,363 INFO [ConfirmCAHandler] CA Setup is successful. 10:49:22,374 INFO [ConfirmClientCertHandler] Certificate with serial number '2' issued to CN=localhost,OU=Geronimo,O=Apache,L=LL,ST=ST,C=LK 10:57:13,253 ERROR [JettyManagerImpl] Unable to add GBean org.apache.geronimo.kernel.config.InvalidConfigException: Cound not add GBean org.apache.geronimo.configs/jetty6/2.0-M3/car?ServiceModule=org.apache.geronimo.configs/jetty6/2.0-M3/car,j2eeType=GBean,name=SSL_Client_Authentication to configuration org.apache.geronimo.configs/jetty6/2.0-M3/car at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.addGBeanToConfiguration(EditableKernelConfigurationManager.java:122) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.addGBeanToConfiguration(EditableKernelConfigurationManager.java:61) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager$$FastClassByCGLIB$$daeffab3.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$f2362049.addGBeanToConfiguration(generated) at org.apache.geronimo.jetty6.JettyManagerImpl.addConnector(JettyManagerImpl.java:98) at org.apache.geronimo.jetty6.JettyManagerImpl$$FastClassByCGLIB$$f2d5e245.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.management.geronimo.WebManager$$EnhancerByCGLIB$$f289d8f.addConnector(generated) at org.apache.geronimo.console.util.PortletManager.createWebConnector(PortletManager.java:254) at org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:107) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) at
[jira] Commented: (GERONIMO-2916) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478727 ] Gianny Damour commented on GERONIMO-2916: - Anita, this problem should now be fixed. PersistenceUnitBuilders were wrongly invoked by the EARConfigBuilder during the deployment of standalone modules. database creation pool wizzard fails to deploy -- Key: GERONIMO-2916 URL: https://issues.apache.org/jira/browse/GERONIMO-2916 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 2.0-M2, 2.0-M3 Environment: relates to GERONIMO-2686 Reporter: Hernan Cunico From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. Similar error conditions were reported in GERONIMO-2686 The terminal shows the following error: 15:07:55,562 ERROR [DatabasePoolPortlet] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: rar registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:343) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java: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:338) 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:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) 15:08:02,875 ERROR
[jira] Created: (GERONIMO-2938) javamail SMTPTransport has interpretation of mail.smtp.quitwait option wrong.
javamail SMTPTransport has interpretation of mail.smtp.quitwait option wrong. - Key: GERONIMO-2938 URL: https://issues.apache.org/jira/browse/GERONIMO-2938 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: mail Affects Versions: 1.1.1, 1.2, 2.0-beta1 Reporter: Rick McGuire Assigned To: Rick McGuire Priority: Minor Fix For: 1.2, 2.0-beta1 The SMTPTransport is interpreting the meaning of the session property mail.smtp.quitwait backwards, resulting in incorrect handling of the default value. The transport should NOT wait for a response from QUIT by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2938) javamail SMTPTransport has interpretation of mail.smtp.quitwait option wrong.
[ https://issues.apache.org/jira/browse/GERONIMO-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire closed GERONIMO-2938. -- Resolution: Fixed Committed revision 515522. javamail SMTPTransport has interpretation of mail.smtp.quitwait option wrong. - Key: GERONIMO-2938 URL: https://issues.apache.org/jira/browse/GERONIMO-2938 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Affects Versions: 1.1.1, 1.2, 2.0-beta1 Reporter: Rick McGuire Assigned To: Rick McGuire Priority: Minor Fix For: 1.2, 2.0-beta1 The SMTPTransport is interpreting the meaning of the session property mail.smtp.quitwait backwards, resulting in incorrect handling of the default value. The transport should NOT wait for a response from QUIT by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ClientCommandLine and Daemon - Changing boot approach?
Hi, Following the introduction of a potentially simpler bootstrapping mechanism (currently used by the deployers), we now have an opportunity to refactor ClientCommandLine and Daemon to leverage this same approach. The idea of the new bootstrapping mechanism is as follows: MainBootstrapper boots a configuration, gets from the Kernel a Main implementation and then delegates to it. As the Main implementation class can be loaded from the boot repository, rooted at repository/ by default, the executable jar instantiating MainBootstrapper can be pretty generic with respect to its Class-Path entries: only geronimo- kernel plus its dependencies are needed. ClientCommandLine and Daemon could be refactored to implement the Main interface MainBootstrapper is looking for. With these changes, we should be able to move some dependencies from lib/ to repository/ and also uniform the way CLIs are working. Any concerns if I do these changes? Thanks, Gianny
Re: Error adding HTTPS Listener
The portlet needs to be updated to work with the jetty6 gbean wrappers. Can you open a jira for this? If you would like to fix it too that would be even better :-) I don't see the tomcat error, but there's a good chance the portlet needs to be updated for tomcat 6 as well. thanks david jencks On Mar 7, 2007, at 4:46 AM, Karthiga Ratnam wrote: Hi All, As part of my documentation work, I'm currently upgrading Certificate Properties File Realm as a part of adminstering certificates to v2.0 M3. I have a couple of issues right now. The following tasks have been done without any problem with the help of existing CA in Geronimo. Create keystore and certificate Create a Certificate Signing Request (CSR) and import CA reply Import trusted certificates But when it comes to Adding an HTTPS listener with client authentication I keep getting an error for both Jetty and Tomcat (two different errors). Thanks Karthiga Jetty error 10:48:09,363 INFO [ConfirmCAHandler] CA Setup is successful. 10:49:22,374 INFO [ConfirmClientCertHandler] Certificate with serial number '2' issued to CN=localhost,OU=Geronimo,O=Apache,L=LL,ST=ST,C=LK 10:57:13,253 ERROR [JettyManagerImpl] Unable to add GBean org.apache.geronimo.kernel.config.InvalidConfigException: Cound not add GBean org.apache.geronimo.configs/jetty6/2.0-M3/car? ServiceModule=org.apache.geronimo.configs/jetty6/2.0-M3/ car,j2eeType=GBean,name=SSL_Client_Authentication to configuration org.apache.geronimo.configs/jetty6/2.0-M3/car at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.a ddGBeanToConfiguration(EditableKernelConfigurationManager.java:122) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.a ddGBeanToConfiguration(EditableKernelConfigurationManager.java:61) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager $$FastClassByCGLIB$$daeffab3.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$ $EnhancerByCGLIB$$f2362049.addGBeanToConfiguration(generated) at org.apache.geronimo.jetty6.JettyManagerImpl.addConnector (JettyManagerImpl.java:98) at org.apache.geronimo.jetty6.JettyManagerImpl$ $FastClassByCGLIB$$f2d5e245.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.management.geronimo.WebManager$ $EnhancerByCGLIB$$f289d8f.addConnector(generated) at org.apache.geronimo.console.util.PortletManager.createWebConnector (PortletManager.java:254) at org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction( ConnectorPortlet.java:107) at org.apache.pluto.core.PortletServlet.dispatch (PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet (PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service (PortletServlet.java:153) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:491) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle (InternalJettyServletHolder.java:62) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:367) at org.mortbay.jetty.security.SecurityHandler.handle (SecurityHandler.java:185) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle (JettySecurityHandler.java:133) at org.mortbay.jetty.servlet.SessionHandler.handle (SessionHandler.java:181) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle (ThreadClassloaderHandler.java:46) at
Re: Generic way to handle annotations for integrating projects
On Mar 7, 2007, at 2:46 AM, Lasantha Ranaweera wrote:
David,
May be a silly question. How about handling JPA related annotations?
I can think of 2 kinds of jpa related annotations. There are
PersistenceManagerRef and PersistenceUnitRef which are injection
related and that we already handle with our NamingBuilder framework,
and there are annotations on the entities to help make them
persistence capable, which the jpa framework we use deals with
without any help from us: informing the jpa framework about these is
done by the PersistenceUnitBuilder. As far as I know an entity
managed by jpa cannot have injections which would be the situation
relevant to this proposal. Does this make sense?
thanks
david jencks
Thanks,
Lasantha
David Jencks wrote:
I've been working on annotation handling for jetty using xbean-
reflect and have come up with a design for general annotation
processing that I would like to propose we urge our integrated
projects to allow or adopt.
This is appropriate when the injection only involves stuff looked
up in jndi and when the sequence of events is
- construct instance
- inject stuff
- call postConstruct
with no intervening container lifecycle calls.
So I'd like each project to define an interface
public interface ProjectLifecycleSupport {
Object newInstance(String className); //might need a classloader
too depending on whether the project has per-module instances
void destroyInstance(Object o);
}
and provide a way we can inject such an object into the projects
framework.
We can then implement the newInstance method to construct and
inject properties using xbean-reflect and call postConstruct, and
destroyInstance to call preDestroy.
Another style has been popularized by tomcat (?) which has 3 methods
inject(Object)
postConstruct(Object)
preDestroy(Object)
We can use this style but then we wont be able to use xbean-
reflect which hides all the hard part :-) and would let us go
beyond the spec and support constructor injection if we can figure
out how to get constructor metadata to it.
It's pretty trivial to implement an adapter between my proposal
and the tomcat style, but not vice versa.
So, where would this be used? The most likely bits are MyFaces,
CXF, and Axis2. I'm already doing something very similar for
jetty and haven't looked to see if tomcat can be adapted this way.
Thoughts?
thanks
david jencks
Re: why do we call the eclipse plugin devtools?
Devtools is the name of the subproject, to represent tools like, XDoc, the Eclipse-Plugin, J2G. Currently yes, there is only one tool that has been released under devtools, so it does look kind of weired. However, hopefully with J2G, and the Netbeans plugin will can start filling the Devtools subproject with more content. Thus I believe it should stay as is. -sachin On Mar 6, 2007, at 5:08 PM, Jason Dillon wrote: I agree its a development tool... but its seems really odd that we don't just call this eclipse-plugin... which seems to be the normal way other projects refer to their eclipse integration. For example, on the main page under sub-projects... I think the link should be Eclipse Plugin and that most users will kind of expect to see that instead of Development Tools, which happens to be a page all about the Eclipse Plugin anyways. --jason
Re: why do we call the eclipse plugin devtools?
I don't understand. What is currently named devtools besides the link on the site? I favor what we have currently, but if you feel strongly about this, I will not object any changes you make. -sachin On Mar 6, 2007, at 5:38 PM, Jacek Laskowski wrote: On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: I guess the thing I don't really like right now... is that we refer to the eclipse-plugin as devtools interchangeably. I believe that should change... and I think the way to make that change is to start renaming stuff that was previously devtools (which was solely for eclipse tooling support) to eclipse-plugin. I second that. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Questions for Axis2 folks re: JAXWS
Lasantha Ranaweera wrote:
Not exactly sure whether I am getting your problem exactly or not :-( .
Line 99 decides whether application archive contains WSDL file or not
(according to Axis2 builder). If it is there we are going to fill WSDL
information from G side. Otherwise it will be handed over to Axis2 side
(services with annotations). So looking at your problem regarding
annotations what I say is it should be handled by Axis2 (all the
validation execution stuff). The annotation processing will be handled
as a web service receives SOAP requests. Starting point for JAXWS based
SOAP messages is receive() method of JAXWSMessageReciever.
The problem is, Axis2 is generating a wsdl upon the client request for a
wsdl, and not looking at the WebService annotation to get the wsdl's
location. The code step through below shows the problem clearly.
HTH.
Lasantha
Jeff Genender wrote:
o.a.g.Axis2WebserviceContainer, line 99. A not-filled in PortInfo is
passed in since G is not processing a WebService annotation, and thus an
AxisService.create is called on line 104.
When Axis2WebserviceContainer.getWsdl() is ultimately called,
doService2() is called (line 212), then to processGetRequest (line 398),
leading us to line 435 where the PortInfo is checked as to whether a
wsdl file has been passed in or not. If it has, it spits out the wsdl.
If it has not, then the AxisService.printWsdl() is called and that call
spits out a generated wsdl.
The crux here is that the PortInfo object does not have all of the info
filled in such as seiClass, wsdl file, etc. That stuff would have been
gotten from examining the WebService annotation.
The question is, where does that examination or, should that
examination, take place? Geronimo or Axis2?
Jeff
Lasantha Ranaweera wrote:
Jeff,
Sorry for a late reply due to my time stamp difference and don't know
exactly you have solved this problem right now or not. Anyway here is my
comment.
Since you haven't given me exact source code I won't be able to point
you in to the exact source code in the Axis2. May be remote debugging
... ;-) .
Thanks,
Lasantha
Jeff Genender wrote:
Ok...
I am pretty certain at this stage that the WebService annotation is not
getting processed. Can you point me to the code that handles this in
Axis2?
Thanks,
Jeff
Jeff Genender wrote:
Thanks...this is very helpful.
Then by this, looking at the PortInfo, it appears as though it is not
stuffing in the WSDL file, which tells me it's a G thang ;-)
Jeff
Lasantha Ranaweera wrote:
Hi Jeff,
To my understanding if we have given a WSDL in an archive it
should get
the priority than the information in the annotations.
In Axis2 integration there are two parts of implementation with
one for
with WSDL which is mainly handling by G side while with annotations
from
Axis2. For me it is something missing in G side.
Somebody in the list please correct me if I am wrong here .
Thanks,
Lasantha
Jeff Genender wrote:
Hi,
I have noticed when I deploy a war file (with a WSDL), I have a
certain
target name specified both in the WSDL and in the code that uses a
WebService annotation.
However, when I go retrieve the WSDL, I notice the target name
seems to
be munged according to the package name (backwards) of the code that
contains the WebService annotation.
Example...
I have include a WSDL called Hello.wsdl that is in the war file
in the
web-inf/wsdl directory and starts with:
wsdl:definitions targetNamespace=http://example.com/hello/xsd;
...
I have a HelloWorld.java that has this:
package test.mypackage;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService(name=HelloWorld, targetNamespace =
http://example.org/hello/xsd;)
public class HelloWorld {
@WebMethod
public String sayHello(String me){
return Hello +me;
}
}
However, when I request the wsdl...I get something like this:
wsdl:definitions targetNamespace=http://mypackage.test/xsd;
...
Notice the targetnamespace was munged and changed from it's
originally
declared namespace of http://example.com/hello/xsd;. I want the
one
that is both declared in the included wsdl (or the one declared
in the
annotation).
Is this a facet of Axis2 or is Geronimo not passing a proper
PortInfo
object with the necessary stuff filled in?
Any light on this subject would be greatly appreciated ;-)
Thanks,
Jeff
Re: ClientCommandLine and Daemon - Changing boot approach?
On Mar 7, 2007, at 6:10 AM, Gianny Damour wrote: Hi, Following the introduction of a potentially simpler bootstrapping mechanism (currently used by the deployers), we now have an opportunity to refactor ClientCommandLine and Daemon to leverage this same approach. The idea of the new bootstrapping mechanism is as follows: MainBootstrapper boots a configuration, gets from the Kernel a Main implementation and then delegates to it. As the Main implementation class can be loaded from the boot repository, rooted at repository/ by default, the executable jar instantiating MainBootstrapper can be pretty generic with respect to its Class-Path entries: only geronimo-kernel plus its dependencies are needed. ClientCommandLine and Daemon could be refactored to implement the Main interface MainBootstrapper is looking for. With these changes, we should be able to move some dependencies from lib/ to repository/ and also uniform the way CLIs are working. Any concerns if I do these changes? I think this is a great idea! thanks david jencks Thanks, Gianny
Re: ClientCommandLine and Daemon - Changing boot approach?
Hello Gianny Question? What all dependency will you be able to move out of lib using this. Where will ClientCommandLine and Daemon implenting tje MainBootstrapper interface will reside. I am not sure what all advantages will you be able to get out of this redistribution. Also any thoughts on effect it may have on offline deployer. Thanks Rakesh On 3/7/07, Gianny Damour [EMAIL PROTECTED] wrote: Hi, Following the introduction of a potentially simpler bootstrapping mechanism (currently used by the deployers), we now have an opportunity to refactor ClientCommandLine and Daemon to leverage this same approach. The idea of the new bootstrapping mechanism is as follows: MainBootstrapper boots a configuration, gets from the Kernel a Main implementation and then delegates to it. As the Main implementation class can be loaded from the boot repository, rooted at repository/ by default, the executable jar instantiating MainBootstrapper can be pretty generic with respect to its Class-Path entries: only geronimo- kernel plus its dependencies are needed. ClientCommandLine and Daemon could be refactored to implement the Main interface MainBootstrapper is looking for. With these changes, we should be able to move some dependencies from lib/ to repository/ and also uniform the way CLIs are working. Any concerns if I do these changes? Thanks, Gianny
Re: Build Failure - Eclipse-Plugin trunk Rev513960
Fresh checkout and build worked for me also. Thanks. - Shiva On 3/6/07, Donald Woods [EMAIL PROTECTED] wrote: Worked for me. Thanks. -Donald Sachin Patel wrote: fixed -sachin On Mar 5, 2007, at 9:15 AM, Sachin Patel wrote: I can reproduce this now... will investigate. -sachin On Mar 5, 2007, at 7:03 AM, Shiva Kumar H R wrote: I too am getting a Build error as below: [INFO] Building org.apache.geronimo.runtime.common [INFO]task-segment: [install] [ERROR] BUILD ERROR [INFO] [INFO] Manifest Bundle-Classpath is missing the following entries: [lib/xstream- 1.1.3.jar] [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException : Manifest Bundle-Classpat h is missing the following entries: [lib/xstream-1.1.3.jar] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java :454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java :115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Manifest Bundle-Class path is missing the following entries: [lib/xstream- 1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute(Bundl eManifestMojo.java:72) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java :412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.MojoFailureException: Manifest Bundle-Classpa th is missing the following entries: [lib/xstream-1.1.3.jar] at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.validateBundl eClasspath(BundleManifestMojo.java:97) at org.apache.geronimo.eclipse.devtools.BundleManifestMojo.execute (Bundl eManifestMojo.java:69) ... 18 more [INFO] [INFO] Total time: 2 minutes 40 seconds [INFO] Finished at: Mon Mar 05 16:32:47 IST 2007 [INFO] Final Memory: 18M/89M [INFO] -- Thx, Shiva On 3/4/07, *Donald Woods* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Latest Eclipse-Plugin trunk at Rev513960 fails to build with the following error on WinXP, Maven 2.0.5 and Java 1.5.0_11 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar:2.0.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.devtools -Dartifact Id=org.apache.geronimo.st.v20.core \ -Dversion=2.0.0 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.devtools:assembly:pom:2.0.0 2) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar:2.0 . 0 -- 1 required artifact is missing. for artifact: org.apache.geronimo.devtools:assembly:pom:2.0.0 -Donald
Re: Database pools
I added connector-deployer as a 'import classes' dependency of
jsr88-rar-configurer as you had suggested. I could get it to start only
after adding gbean-deployer as a parent of jsr88-cli because of the
following error:
18:19:36,500 WARN [ConfigurationUtil] Could not load gbean
org.apache.geronimo.configs/jsr88-rar-configurer/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/jsr88-rar-configurer/2.0-SNAPSHOT/car,j2eeType=DeploymentConfigurer,name=RARConfigurer
org.apache.geronimo.gbean.InvalidConfigurationException: Getter return
type in wrong classloader: type: class
javax.enterprise.deploy.shared.ModuleType wanted in classloader:
[org.apache.geronimo.kernel.classloader.JarFileClassLoader
id=org.apache.geronimo.configs/jsr88-cli/2.0-SNAPSHOT/car] actual:
[org.apache.geronimo.kernel.classloader.JarFileClassLoader
id=org.apache.geronimo.configs/geronimo-gbean-deployer/2.0-SNAPSHOT/car]
at
org.apache.geronimo.gbean.runtime.GBeanAttribute.init(GBeanAttribute.java:241)
How does this fit with other things?
Thanks
Anita
--- David Jencks [EMAIL PROTECTED] wrote:
I agree that starting the existing jsr88-* configs is a better
solution than adding gbeans to the deployer configs. There might
possibly be classloading problems from duplicate copies of e.g.
geronimo-connector-builder.jar, but if that happens I think the
better solution is to move the jsr88 code into separate jars,
something I believe Aaron and I have been contemplating for years.
I'm glad to know that there is already a LocalDeploymentManager.
thanks
david jencks
On Mar 6, 2007, at 9:11 AM, Gianny Damour wrote:
Hello Anita,
I had a quick look to GERONIMO-2916 and, as per David J. comment,
it seems to me that if you simply start the pointed out modules
this bug will be fixed: DatabasePoolPortlet gets a
LocalDeploymentManager instance, which knows about all the running
ModuleConfigurer GBean implementations. If
org.apache.geronimo.configs/jsr88-rar-configurer//car is started,
then you will get a RARConfigurer running within the server. Then
when DatabasePoolPortlet obtains its LocalDeploymentManager, this
latter does know about RARConfigurer.
Thanks,
Gianny
On 07/03/2007, at 12:18 AM, Anita Kulshreshtha wrote:
Minor (? :)) Clarification
David, I meant to write connector-deployer config not
system-database to add the GBean to. Will that change your answer?
I
think having individual GBeans in the appropriate deployer config
will
work well for minimal and framework servers.
Thanks
Anita
--- Anita Kulshreshtha [EMAIL PROTECTED] wrote:
--- David Jencks [EMAIL PROTECTED] wrote:
On Mar 5, 2007, at 6:31 PM, Anita Kulshreshtha wrote:
I need to add RARConfigurer GBean to system-database config
to
fix
https://issues.apache.org/jira/browse/GERONIMO-2916 (see
excerpts
below)
Is this the correct place to add it?
No.
Instead of adding gbeans to anything, I think you want to start
all
the jsr88-*configurer modules gianny recently added. See
assemblies/
geronimo-jetty6-jee5/src/main/var/config/jsr88-configurer-config.xml
which contains
module
name=org.apache.geronimo.configs/jsr88-cli/${version}/car/
module
name=org.apache.geronimo.configs/jsr88-jar-configurer/$
{version}/car/
module
name=org.apache.geronimo.configs/jsr88-rar-configurer/$
{version}/car/
module
name=org.apache.geronimo.configs/jsr88-war-configurer/$
{version}/car/
module
name=org.apache.geronimo.configs/jsr88-ear-configurer/$
{version}/car/
I don't think you want to start the jsr88-cli in the server.
If
there isn't already an appropriate gbean for the
DeploymentManager
we'd need a gbean like
gbean name=ModuleConfigurerRegistry
class=org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentMana
ger
references name=ModuleConfigurers
pattern
nameClientConfigurer/name
/pattern
pattern
nameEARConfigurer/name
/pattern
pattern
nameRARConfigurer/name
/pattern
pattern
nameWARConfigurer/name
/pattern
/references
/gbean
somewhere appropriate but I don't think it should be the
jmxRemoteDeploymentManager. (but I'm not sure) It does need to
be
able to accept the *Configurers registering with it.
I found WARConfigurer GBean in tomcat6-deployer config. I
did
not
find any EarConfigurer. I am still mesmerized by this stuff...
The
ModuleConfigurerRegistry is a good choice. Where should this
GBean
go?
Thanks
Anita
thanks
david jencks
Thanks
Anita
5:07:55,562 ERROR [DatabasePoolPortlet] Unable to
[jira] Created: (SM-870) StaxSourceTransformer should reuse the XMLStreamReader when available
StaxSourceTransformer should reuse the XMLStreamReader when available - Key: SM-870 URL: https://issues.apache.org/activemq/browse/SM-870 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-869) Avoid creating xml factories in jsr181
Avoid creating xml factories in jsr181 -- Key: SM-869 URL: https://issues.apache.org/activemq/browse/SM-869 Project: ServiceMix Issue Type: Improvement Components: servicemix-jsr181 Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 Creating xml factories is a lengthy operation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-869) Avoid creating xml factories in jsr181
[ https://issues.apache.org/activemq/browse/SM-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-869. Resolution: Fixed Author: gnodet Date: Wed Mar 7 06:20:05 2007 New Revision: 515579 URL: http://svn.apache.org/viewvc?view=revrev=515579 Log: SM-869: Avoid creating xml factories in jsr181 Modified: incubator/servicemix/trunk/deployables/serviceengines/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/xfire/JbiChannel.java Author: gnodet Date: Wed Mar 7 06:23:01 2007 New Revision: 515581 URL: http://svn.apache.org/viewvc?view=revrev=515581 Log: SM-869: Avoid creating xml factories in jsr181 Avoid creating xml factories in jsr181 -- Key: SM-869 URL: https://issues.apache.org/activemq/browse/SM-869 Project: ServiceMix Issue Type: Improvement Components: servicemix-jsr181 Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 Creating xml factories is a lengthy operation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-870) StaxSourceTransformer should reuse the XMLStreamReader when available
[ https://issues.apache.org/activemq/browse/SM-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-870. Resolution: Fixed Author: gnodet Date: Wed Mar 7 06:23:33 2007 New Revision: 515582 URL: http://svn.apache.org/viewvc?view=revrev=515582 Log: SM-870: StAXSourceTransformer should reuse the XMLStreamReader when available Modified: incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/jaxp/FragmentStreamReader.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/jaxp/StAXSourceTransformer.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/jaxp/StaxSource.java Author: gnodet Date: Wed Mar 7 06:25:01 2007 New Revision: 515583 URL: http://svn.apache.org/viewvc?view=revrev=515583 Log: SM-870: StAXSourceTransformer should reuse the XMLStreamReader when available Modified: incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/jaxp/FragmentStreamReader.java incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/jaxp/StAXSourceTransformer.java incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/jaxp/StaxSource.java StaxSourceTransformer should reuse the XMLStreamReader when available - Key: SM-870 URL: https://issues.apache.org/activemq/browse/SM-870 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Questions for Axis2 folks re: JAXWS
Hi Lasantha, See my in line comments below.
Lasantha Ranaweera wrote:
Lin Sun wrote:
I have been giving some thoughts on this prob yesterday. By looking
at the java comments for AxisService.createService, it seems this
method is only for RPCMessageReceiver, but we are using
JAXWSMessageReceiver here. Maybe dims or Lasantha can comment on this.
I don't think using JAXWSMessageReciever is a problem here (according to
the way JAXWS samples works with Axis2). Do you have a better solution
for it?
No, I am not saying we should not use JAXWSMessageReciever. I am saying
there is a bug here when this message is used with JAXWSMessageReciever.
seems there are 2 scenarios:
1) no webservices.xml, no .wsdl, just java files with annotation:
One solution I can think of is to create a temp wsdl file when
Axis2Builder is called based on the java files (seems this can be done
either using the Java2WSDLCodegenEngine from Axis2 or using Sun's
tools), and then set PortInfo properties there. When
Axis2WebServiceContainer is called, we'll treat it as wsdl file
already exists. Delete the temp wsdl file at the end.
Can't we directly let the Axis2 handle the problem rather than handling
it from G side (do we need to do some processing in G side) ?
But the prob is Axis2 isn't handling this prob correctly. It is not
generating the wsdl correctly using java files when .wsdl isn't provided
or using the wsdl-file specified in annotation when .wsdl is provided.
Lin
Lin
Jeff Genender wrote:
o.a.g.Axis2WebserviceContainer, line 99. A not-filled in PortInfo is
passed in since G is not processing a WebService annotation, and thus an
AxisService.create is called on line 104.
When Axis2WebserviceContainer.getWsdl() is ultimately called,
doService2() is called (line 212), then to processGetRequest (line 398),
leading us to line 435 where the PortInfo is checked as to whether a
wsdl file has been passed in or not. If it has, it spits out the wsdl.
If it has not, then the AxisService.printWsdl() is called and that call
spits out a generated wsdl.
The crux here is that the PortInfo object does not have all of the info
filled in such as seiClass, wsdl file, etc. That stuff would have been
gotten from examining the WebService annotation.
The question is, where does that examination or, should that
examination, take place? Geronimo or Axis2?
Jeff
Lasantha Ranaweera wrote:
Jeff,
Sorry for a late reply due to my time stamp difference and don't know
exactly you have solved this problem right now or not. Anyway here
is my
comment.
Since you haven't given me exact source code I won't be able to point
you in to the exact source code in the Axis2. May be remote debugging
... ;-) .
Thanks,
Lasantha
Jeff Genender wrote:
Ok...
I am pretty certain at this stage that the WebService annotation is
not
getting processed. Can you point me to the code that handles this in
Axis2?
Thanks,
Jeff
Jeff Genender wrote:
Thanks...this is very helpful.
Then by this, looking at the PortInfo, it appears as though it is not
stuffing in the WSDL file, which tells me it's a G thang ;-)
Jeff
Lasantha Ranaweera wrote:
Hi Jeff,
To my understanding if we have given a WSDL in an archive it
should get
the priority than the information in the annotations.
In Axis2 integration there are two parts of implementation with
one for
with WSDL which is mainly handling by G side while with annotations
from
Axis2. For me it is something missing in G side.
Somebody in the list please correct me if I am wrong here .
Thanks,
Lasantha
Jeff Genender wrote:
Hi,
I have noticed when I deploy a war file (with a WSDL), I have a
certain
target name specified both in the WSDL and in the code that uses a
WebService annotation.
However, when I go retrieve the WSDL, I notice the target name
seems to
be munged according to the package name (backwards) of the code
that
contains the WebService annotation.
Example...
I have include a WSDL called Hello.wsdl that is in the war file
in the
web-inf/wsdl directory and starts with:
wsdl:definitions targetNamespace=http://example.com/hello/xsd;
...
I have a HelloWorld.java that has this:
package test.mypackage;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService(name=HelloWorld, targetNamespace =
http://example.org/hello/xsd;)
public class HelloWorld {
@WebMethod
public String sayHello(String me){
return Hello +me;
}
}
However, when I request the wsdl...I get something like this:
wsdl:definitions targetNamespace=http://mypackage.test/xsd;
...
Notice the targetnamespace was munged and changed from it's
originally
declared namespace of http://example.com/hello/xsd;. I want
the one
that is both declared in the included wsdl (or the one declared
in the
annotation).
Is this a facet of Axis2 or is Geronimo not passing a proper
PortInfo
object with the necessary stuff filled in?
Any light on this subject would be greatly
[BUILD] TRUNK: Failed for Revision: 515593
Building with Maven version: 2.0.5
Revision: 515593 built with tests skipped
See the full build-1000.log file at
http://people.apache.org/~prasad/binaries/20070307/build-1000.log
[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/plan/plan.xml
[INFO] snapshot
org.apache.geronimo.modules:geronimo-persistence-jpa10-builder:2.0-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-persistence-jpa10-builder:2.0-SNAPSHOT:
checking for updates from axis2-m2-repo
[INFO] snapshot
org.apache.geronimo.modules:geronimo-persistence-jpa10-builder:2.0-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-persistence-jpa10-builder:2.0-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] Building jar:
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/persistence-jpa10-deployer-2.0-SNAPSHOT.car
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: persistence-jpa10-deployer-2.0-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/persistence-jpa10-deployer-2.0-SNAPSHOT.car
to
/home/prasad/.m2/repository/org/apache/geronimo/configs/persistence-jpa10-deployer/2.0-SNAPSHOT/persistence-jpa10-deployer-2.0-SNAPSHOT.car
[INFO]
[INFO] Building Geronimo Configs :: OpenJPA with dependencies
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/configs/openjpa/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/configs/openjpa/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/prasad/geronimo/trunk/configs/openjpa/target/plan/plan.xml
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository//org/apache/openjpa/openjpa-all/0.9.6-incubating/openjpa-all-0.9.6-incubating.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-all:pom:0.9.6-incubating' from repository
tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/)
Downloading:
http://ws.zones.apache.org/repository2//org/apache/openjpa/openjpa-all/0.9.6-incubating/openjpa-all-0.9.6-incubating.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-all:pom:0.9.6-incubating' from repository
axis2-m2-repo (http://ws.zones.apache.org/repository2/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-all/0.9.6-incubating/openjpa-all-0.9.6-incubating.pom
3K downloaded
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository//org/apache/openjpa/openjpa-xmlstore/0.9.6-incubating/openjpa-xmlstore-0.9.6-incubating.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-xmlstore:pom:0.9.6-incubating' from repository
tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/)
Downloading:
http://ws.zones.apache.org/repository2//org/apache/openjpa/openjpa-xmlstore/0.9.6-incubating/openjpa-xmlstore-0.9.6-incubating.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-xmlstore:pom:0.9.6-incubating' from repository
axis2-m2-repo (http://ws.zones.apache.org/repository2/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-xmlstore/0.9.6-incubating/openjpa-xmlstore-0.9.6-incubating.pom
1K downloaded
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository//org/apache/openjpa/openjpa-xmlstore/0.9.6-incubating/openjpa-xmlstore-0.9.6-incubating.jar
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-xmlstore:jar:0.9.6-incubating' from repository
tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/)
Downloading:
http://ws.zones.apache.org/repository2//org/apache/openjpa/openjpa
Re: Document servicemix-common
I have started a wiki page on servicemix-common http://cwiki.apache.org/SM/jbi-component-framework.html This is obviously just a start ;-) but if you think about a point we need to document, please add a TODO or a comment so that we don't forget it ... I guess we will be able to leverage the tutorials Bruce is writing: http://cwiki.apache.org/SM/hello-world-bc.html http://cwiki.apache.org/SM/hello-world-se.html On 3/6/07, Guillaume Nodet [EMAIL PROTECTED] wrote: We need to document servicemix-common, which is our framework for building standard JBI components. But at the same time, servicemix-common does not sounds like a very good name. What about JBI Components Framework ? I'm not talking about changing the code, nor the jar, just to do a bit more advertising on the the web site about it ... -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Servicemix-Bean
I've been going over the servicemix-bean docs and as they are written at the moment, they seem to imply that most of the clever functionality can only be used in a static configuration. Is this actually the case or just an artifact of the way the documentation is structured? -- Terry
Re: Generic way to handle annotations for integrating projects
Due to my own limited knowledge of xbean and the nuances of deployment
I can't claim to totally understand all the benefits of allowing the
application server to handle instantiation for objects annotated for
dependency injection. I have a hunch that the main benefit is that
it allows the container to pick which constructor it uses and even in
some cases call various application server specific lifecycle methods
on the object. If that's true then I can see a tremendous benefit
if/when Geronimo extends annotation support outward towards GBeans.
Are there other benefits that should be pointed out as well?
I think that most integrating projects would support this approach.
In fact when I asked the MyFaces team about dependency injection their
initial response was something along the lines of -- why can't the
container intercept object instantiation and handle injection at the
classloader level? (but that's not, BTW, how MyFaces finally ended up
providing injection support). However, when discussing that approach
they were reluctant to relinquish control of @PostConstruct and
@PreDestroy because there is explicit language in the JSF spec about
how those annotations relate to the scope and lifecycle of managed
beans. So, playing the MyFaces advocate here, how would their
component be assured of spec compliance when running in a container
that doesn't necessarily support this new approach?
Something else to take into consideration, at least for MyFaces, is
that their current approach is mostly compatible with how the JSF RI
and Tomcat provide injection support, which makes it easier to replace
the JSF RI with MyFaces in Glassfish and other application server
environments. In order for MyFaces to implement behavior that is much
different than the RI I think they would need to see much stronger
language in the JSF spec around dependency injection. So it might be
worthwhile to pursue this as an addendum to the JSF and perhaps even
the JEE specs.
Best wishes,
Paul
On 3/6/07, David Jencks [EMAIL PROTECTED] wrote:
I've been working on annotation handling for jetty using xbean-
reflect and have come up with a design for general annotation
processing that I would like to propose we urge our integrated
projects to allow or adopt.
This is appropriate when the injection only involves stuff looked up
in jndi and when the sequence of events is
- construct instance
- inject stuff
- call postConstruct
with no intervening container lifecycle calls.
So I'd like each project to define an interface
public interface ProjectLifecycleSupport {
Object newInstance(String className); //might need a classloader too
depending on whether the project has per-module instances
void destroyInstance(Object o);
}
and provide a way we can inject such an object into the projects
framework.
We can then implement the newInstance method to construct and inject
properties using xbean-reflect and call postConstruct, and
destroyInstance to call preDestroy.
Another style has been popularized by tomcat (?) which has 3 methods
inject(Object)
postConstruct(Object)
preDestroy(Object)
We can use this style but then we wont be able to use xbean-reflect
which hides all the hard part :-) and would let us go beyond the spec
and support constructor injection if we can figure out how to get
constructor metadata to it.
It's pretty trivial to implement an adapter between my proposal and
the tomcat style, but not vice versa.
So, where would this be used? The most likely bits are MyFaces, CXF,
and Axis2. I'm already doing something very similar for jetty and
haven't looked to see if tomcat can be adapted this way.
Thoughts?
thanks
david jencks
Re: Servicemix-Bean
On 3/7/07, Terry Cox [EMAIL PROTECTED] wrote: I've been going over the servicemix-bean docs and as they are written at the moment, they seem to imply that most of the clever functionality can only be used in a static configuration. Is this actually the case or just an artifact of the way the documentation is structured? There's nothing to stop folks using things dynamically I guess. Though part of the beauty of servicemix-bean is being able to browse the classpath at deployment time and find the POJOs to be deployed - rather like EJB3. -- James --- http://radio.weblogs.com/0112098/
Re: Servicemix-Bean
I'm going to write some tests to see how well things interoperate within the types of deployment scenarios I would expect to deal with on a large project. I think there is scope for some streamlining in the way projects can be developed and deployed quickly. -- Terry Cox Meta-Concepts Ltd
Problem in generating SA'jbi.xml with the jbi plugin
This is a fragment of the pom.xml of my Service Assembly:
...
profiles
!-- Profile which creates an assembly for Service Mix --
profile
idServiceMix/id
dependencies
dependency
groupIdit.imolinfo.jbi4corba/groupId
artifactIdsu7Servicemix/artifactId
version${pom.version}/version
/dependency
dependency
groupIdit.imolinfo.jbi4corba/groupId
artifactIdsu8/artifactId
version${pom.version}/version
/dependency
/dependencies
activation
activeByDefaulttrue/activeByDefault
/activation
/profile
!-- Profile which creates an assembly for Open ESB --
profile
idOpenESB/id
dependencies
dependency
groupIdit.imolinfo.jbi4corba/groupId
artifactIdsu7Openesb/artifactId
version${pom.version}/version
/dependency
dependency
groupIdit.imolinfo.jbi4corba/groupId
artifactIdsu8/artifactId
version${pom.version}/version
/dependency
/dependencies
activation
property
nameOpenESB/name
/property
/activation
/profile
/profiles
...
The problem is that the jbi.xml produced by the jbi maven plugin for my
service assembly doesn't contain the service-unit elements.
If I don't use Maven profiles, I'm able to generate a jbi.xml with the
service-unit elements.
How I can generate with the plugin a correct jbi.xml if I would like to use
maven profiles in the pom file of my service assembly?
Thanks
Amedeo
--
View this message in context:
http://www.nabble.com/Problem-in-generating-SA%27jbi.xml-with-the-jbi-plugin-tf3363221s12049.html#a9356486
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Servicemix-Bean
On 3/7/07, Terry Cox [EMAIL PROTECTED] wrote: I'm going to write some tests to see how well things interoperate within the types of deployment scenarios I would expect to deal with on a large project. Great! I think there is scope for some streamlining in the way projects can be developed and deployed quickly. Agreed! -- James --- http://radio.weblogs.com/0112098/
Re: [VOTE] Release geronimo-javamail_2.4_spec-1.3
+1 -dain On Mar 5, 2007, at 5:08 AM, Rick McGuire wrote: All, the javamail 1.3 spec has been updated to fix a problem with Transport.send() that multiple 1.1.1 and 1.2 beta users have tripped over. We'd like to get this released in time for the Geronimo 1.2 final version so fewer people will be seeing this problem. I hereby propose we release this branch and it's binaries as final. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-javamail_1.3.1_spec-1.3 Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-javamail_1.3.1_spec/1.3/ Here's my +1 Rick
Re: [VOTE] Release geronimo-javamail_2.4_spec-1.3
+1 (not sure if i voted before :) On 3/7/07, Dain Sundstrom [EMAIL PROTECTED] wrote: +1 -dain On Mar 5, 2007, at 5:08 AM, Rick McGuire wrote: All, the javamail 1.3 spec has been updated to fix a problem with Transport.send() that multiple 1.1.1 and 1.2 beta users have tripped over. We'd like to get this released in time for the Geronimo 1.2 final version so fewer people will be seeing this problem. I hereby propose we release this branch and it's binaries as final. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-javamail_1.3.1_spec-1.3 Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-javamail_1.3.1_spec/1.3/ Here's my +1 Rick -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: why do we call the eclipse plugin devtools?
Primarily its the link on the site (in the side-nav) and the name of the page which is linked to, though I have read emails in the past too which talk about devtools when they meant eclipse-plugin. Anyways, when we get more devtools sub-projects I think each should have their own page and a separate link... and their own JIRA. I don't like the umbrella page. For example, I'd like to see: -- | Development Tools | -- | Eclipse Plugin | --- links to eclipse-plugin.html | Netbeans Plugin | --- links to netbeans-plugin.html | ... (sorry evil ascii art) the NB thing is an example, since AFAIK we don't have one of those yet. --jason On Mar 7, 2007, at 5:44 AM, Sachin Patel wrote: I don't understand. What is currently named devtools besides the link on the site? I favor what we have currently, but if you feel strongly about this, I will not object any changes you make. -sachin On Mar 6, 2007, at 5:38 PM, Jacek Laskowski wrote: On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: I guess the thing I don't really like right now... is that we refer to the eclipse-plugin as devtools interchangeably. I believe that should change... and I think the way to make that change is to start renaming stuff that was previously devtools (which was solely for eclipse tooling support) to eclipse-plugin. I second that. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: why do we call the eclipse plugin devtools?
On 3/7/07, Sachin Patel [EMAIL PROTECTED] wrote: I don't understand. What is currently named devtools besides the link on the site? I favor what we have currently, but if you feel strongly about this, I will not object any changes you make. I haven't removed what I had seconded as it clearly shows that I'm in favour of devtools != eclipse-plugin and that we should use the name - eclipse-plugin - where it deems appropriate. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: why do we call the eclipse plugin devtools?
On 3/7/07, Jacek Laskowski [EMAIL PROTECTED] wrote: On 3/7/07, Sachin Patel [EMAIL PROTECTED] wrote: I don't understand. What is currently named devtools besides the link on the site? I favor what we have currently, but if you feel strongly about this, I will not object any changes you make. I haven't removed what I had seconded as it clearly shows that I'm in favour of devtools != eclipse-plugin and that we should use the name - eclipse-plugin - where it deems appropriate. Once I had written it I removed the quote. See the thread for the reference. Sorry. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: why do we call the eclipse plugin devtools?
On 3/7/07, Jason Dillon [EMAIL PROTECTED] wrote: -- | Development Tools | -- | Eclipse Plugin | --- links to eclipse-plugin.html | Netbeans Plugin | --- links to netbeans-plugin.html | ... (sorry evil ascii art) I like it even if it's just an evil ascii art (I hope it won't end up on our site though ;-)) the NB thing is an example, since AFAIK we don't have one of those yet. Right. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [RESULT] VOTE J2G Conversion tool acceptance
fyi I pinged [EMAIL PROTECTED] for help on patching the IP clearnance form and resolving the last remaining item on the form. Best wishes, Paul On 3/5/07, Paul McMahan [EMAIL PROTECTED] wrote: Thanks for the feedback Kevan. Below is a patch for the ip-clearance form that marks three of the remaining four items as completed. The last remaining item on the form is: Check and make sure that the papers that transfer rights to the ASF been received. It is only necessary to transfer rights for the package, the core code, and any new code produced by the project. Can someone help complete this item or provide guidance on how to verify the transferal paperwork? Best wishes, Paul Index: site-author/ip-clearance/geronimo-2743-ibm-covalent-j2g.xml === --- site-author/ip-clearance/geronimo-2743-ibm-covalent-j2g.xml (revision 514856) +++ site-author/ip-clearance/geronimo-2743-ibm-covalent-j2g.xml (working copy) @@ -102,7 +102,7 @@ /td /tr tr - tdNot Yet Done. + tdMarch-5-2007 /td tdCheck and make sure that the files that have been donated have been updated to reflect the new ASF copyright. @@ -135,7 +135,7 @@ /td /tr tr - tdNot Yet Done. + tdMarch-5-2007 /td tdCheck and make sure that for all items included with the distribution that is not under the Apache license, we have the right to combine @@ -143,7 +143,7 @@ /td /tr tr - tdNot Yet Done. + tdMarch-5-2007 /td tdCheck and make sure that all items depended upon by the project is covered by one or more of the following approved licenses: Apache,
Re: why do we call the eclipse plugin devtools?
Ok, I see how this could clarrify things. I don't have a problem with this. -sachin On Mar 7, 2007, at 12:32 PM, Jason Dillon wrote: Primarily its the link on the site (in the side-nav) and the name of the page which is linked to, though I have read emails in the past too which talk about devtools when they meant eclipse- plugin. Anyways, when we get more devtools sub-projects I think each should have their own page and a separate link... and their own JIRA. I don't like the umbrella page. For example, I'd like to see: -- | Development Tools | -- | Eclipse Plugin | --- links to eclipse-plugin.html | Netbeans Plugin | --- links to netbeans-plugin.html | ... (sorry evil ascii art) the NB thing is an example, since AFAIK we don't have one of those yet. --jason On Mar 7, 2007, at 5:44 AM, Sachin Patel wrote: I don't understand. What is currently named devtools besides the link on the site? I favor what we have currently, but if you feel strongly about this, I will not object any changes you make. -sachin On Mar 6, 2007, at 5:38 PM, Jacek Laskowski wrote: On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: I guess the thing I don't really like right now... is that we refer to the eclipse-plugin as devtools interchangeably. I believe that should change... and I think the way to make that change is to start renaming stuff that was previously devtools (which was solely for eclipse tooling support) to eclipse-plugin. I second that. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: why do we call the eclipse plugin devtools?
This is more a organizational kind of question. How should we maintain the eclipse-plugin specific content (other than eclipse-plugin.html that could be in the root dir). There is currently a devtools directory that contains some eclipse-plugin related files. Should we create a new sub-dir under devtools for each subproject and move the content there? Cheers! Hernan Sachin Patel wrote: Ok, I see how this could clarrify things. I don't have a problem with this. -sachin On Mar 7, 2007, at 12:32 PM, Jason Dillon wrote: Primarily its the link on the site (in the side-nav) and the name of the page which is linked to, though I have read emails in the past too which talk about devtools when they meant eclipse-plugin. Anyways, when we get more devtools sub-projects I think each should have their own page and a separate link... and their own JIRA. I don't like the umbrella page. For example, I'd like to see: -- | Development Tools | -- | Eclipse Plugin | --- links to eclipse-plugin.html | Netbeans Plugin | --- links to netbeans-plugin.html | ... (sorry evil ascii art) the NB thing is an example, since AFAIK we don't have one of those yet. --jason On Mar 7, 2007, at 5:44 AM, Sachin Patel wrote: I don't understand. What is currently named devtools besides the link on the site? I favor what we have currently, but if you feel strongly about this, I will not object any changes you make. -sachin On Mar 6, 2007, at 5:38 PM, Jacek Laskowski wrote: On 3/6/07, Jason Dillon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I guess the thing I don't really like right now... is that we refer to the eclipse-plugin as devtools interchangeably. I believe that should change... and I think the way to make that change is to start renaming stuff that was previously devtools (which was solely for eclipse tooling support) to eclipse-plugin. I second that. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
Yes, looks really great! One comment however is that the font sizes look a little out of whack to me. Seems like the News section title should be a bigger font then each news entry. -sachin On Mar 7, 2007, at 12:59 PM, Jacek Laskowski wrote: Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: SPECjAppServer2004 v1.08 with research mode is released!
Been there...done thatno open source license. On Mar 6, 2007, at 11:15 PM, Jeff Genender wrote: Matt, Its worth a shot to see if they will offer an open source license to the project. That seems to be a good theme today ;-) ANyone want to voulteer to contact em? Jeff Zakharov, Vasily M wrote: Well, I'm not a SPEC representative, but you could probably ask this question to SPEC itself. Also, existing SPEC licensees may run SjAS on Geronimo and publish results here. Vasily -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 07, 2007 3:56 AM To: dev@geronimo.apache.org Subject: Re: SPECjAppServer2004 v1.08 with research mode is released! Interesting news Vasiliy. According to the press release we need to still buy the benchmark for $250? Does this mean that a one time purchase for Geronimo is possible and that the benchmark would be useable by all Geronimo committers? Thanks for the heads up. On Mar 6, 2007, at 2:44 PM, Zakharov, Vasily M wrote: Hi, all, I'm happy to announce that the new version of SPECjAppServer2004 (1.08) is released, and includes changes allowing publishing results in open source. SjAS2004 1.08 includes a special research mode workload called EAStress2004 that has a different metric but allows SjAS licensees to publish results for open source products having no J2EE certification and without the results being reviewed by SPEC. This allows for projects like Geronimo to effectively use that workload for testing and discovering performance issues. Here's the press-release: http://www.spec.org/jAppServer2004/jAppServer2004v108.html Vasily Zakharov Intel ESSD
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
I sent mail to the dev list before and after I implemented the conversion... did it not make it to the list? --jason On Mar 7, 2007, at 9:59 AM, Jacek Laskowski wrote: Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Site changing
Fantastic work Jason! This is a great improvement both in what the website offers as well as how easy it is to update. Best wishes, Paul On 3/6/07, Jason Dillon [EMAIL PROTECTED] wrote: Site is updated... using Confluence-driven content. I've implemented an automated sync, documented here ( https:// svn.apache.org/repos/asf/geronimo/site/trunk/README.txt ). This will sync content from cwiki and from SVN every hour, so no need to ssh into people anymore to update site stuff. This won't force the AE plugin to export everything though, so when something major changes on the site (like side-nav) or something using more dynamic macros, the site will need to be re-exported to get those changes picked up. When I have a few free moments (not spent in TCK build hell), I will implement a solution to this too. --jason On Mar 6, 2007, at 2:51 PM, Jason Dillon wrote: I'm going to implement the first step of using the Confluence- driven website for geronimo.apache.org. This includes cleaning up site/trunk. I've made a copy of the current bits here http://svn.apache.org/repos/asf/geronimo/site/ tags/pre-confluence incase I accidentally nuke something, though I think I've identified all of the underlay/boilerplate bits which still need to get served from this svn tree. For now we are just going to sync GMOxSITE from the AutoExport content, but I think that shortly afterwards we will sync all of the spaces (except for 'geronimo', the traditional wiki) so that all non-user driven content is served up from http:// geronimo.apache.org. To do this requires a little bit more content massaging which is gonna take a wee bit longer to whip up and get working for an automated push. Anyways, should be up in an hour or so... if someone notices something is missing please lemme know. --jason
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
Also with conference season arriving, what if we broke the news section into 2, News Events and the events sections could contain any BOF and Session Information? -sachin On Mar 7, 2007, at 1:05 PM, Sachin Patel wrote: Yes, looks really great! One comment however is that the font sizes look a little out of whack to me. Seems like the News section title should be a bigger font then each news entry. -sachin On Mar 7, 2007, at 12:59 PM, Jacek Laskowski wrote: Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
I saw the not from Jason (look for thread Site changing) There is not much change in the style yet. The big thing gain is for us when need to update the content. We did some minor touches here and there trying to leverage Confluence capabilities. Added the dynamic news to the front page and cleaned up a bit the LF. With the Add News feature everybody (committers) can easily add news and events that will get reflected automatically in the front page. I'm also working on a totally refreshed LF but it's not ready for review yet, you folks will have to wait ;-) Jacek Laskowski wrote: Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
On 3/7/07, Jason Dillon [EMAIL PROTECTED] wrote: I sent mail to the dev list before and after I implemented the conversion... did it not make it to the list? Doh! Site changing, isn't it? It didn't come to my attention. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
I have that already worked out in the new template but it's not ready yet, still needs some baking ;-) Cheers! Hernan Sachin Patel wrote: Yes, looks really great! One comment however is that the font sizes look a little out of whack to me. Seems like the News section title should be a bigger font then each news entry. -sachin On Mar 7, 2007, at 12:59 PM, Jacek Laskowski wrote: Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
we can easily do that by adding a label to the news we create. We need to come up with a standard set of labels tho Maybe just news and events will do it. Cheers! Hernan Sachin Patel wrote: Also with conference season arriving, what if we broke the news section into 2, News Events and the events sections could contain any BOF and Session Information? -sachin On Mar 7, 2007, at 1:05 PM, Sachin Patel wrote: Yes, looks really great! One comment however is that the font sizes look a little out of whack to me. Seems like the News section title should be a bigger font then each news entry. -sachin On Mar 7, 2007, at 12:59 PM, Jacek Laskowski wrote: Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: why do we call the eclipse plugin devtools?
If the URL changes for the site.xml changes it will break things from an update manager perspective. The URL to the eclipse related files need to stay the same. Please do not move these. -sachin On Mar 7, 2007, at 1:21 PM, Hernan Cunico wrote: This is more a organizational kind of question. How should we maintain the eclipse-plugin specific content (other than eclipse-plugin.html that could be in the root dir). There is currently a devtools directory that contains some eclipse- plugin related files. Should we create a new sub-dir under devtools for each subproject and move the content there? Cheers! Hernan Sachin Patel wrote: Ok, I see how this could clarrify things. I don't have a problem with this. -sachin On Mar 7, 2007, at 12:32 PM, Jason Dillon wrote: Primarily its the link on the site (in the side-nav) and the name of the page which is linked to, though I have read emails in the past too which talk about devtools when they meant eclipse- plugin. Anyways, when we get more devtools sub-projects I think each should have their own page and a separate link... and their own JIRA. I don't like the umbrella page. For example, I'd like to see: -- | Development Tools | -- | Eclipse Plugin | --- links to eclipse-plugin.html | Netbeans Plugin | --- links to netbeans-plugin.html | ... (sorry evil ascii art) the NB thing is an example, since AFAIK we don't have one of those yet. --jason On Mar 7, 2007, at 5:44 AM, Sachin Patel wrote: I don't understand. What is currently named devtools besides the link on the site? I favor what we have currently, but if you feel strongly about this, I will not object any changes you make. -sachin On Mar 6, 2007, at 5:38 PM, Jacek Laskowski wrote: On 3/6/07, Jason Dillon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I guess the thing I don't really like right now... is that we refer to the eclipse-plugin as devtools interchangeably. I believe that should change... and I think the way to make that change is to start renaming stuff that was previously devtools (which was solely for eclipse tooling support) to eclipse-plugin. I second that. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Whoa! The website is sooo beautiful and the logo astounded me much!
Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Created: (SM-871) Optimize EndpointSupport.getKey, EndpointSupport.getUniqueKey, MessageExchange.setMessage, and DeliveryChannel.getKeyForExchange
Optimize EndpointSupport.getKey, EndpointSupport.getUniqueKey, MessageExchange.setMessage, and DeliveryChannel.getKeyForExchange Key: SM-871 URL: https://issues.apache.org/activemq/browse/SM-871 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Web site schema links broken
So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Re: why do we call the eclipse plugin devtools?
Anyways... I wasn't referring to the devtools/site.xml bits, though that is another area where devtools means eclipse-plugin. Should eventually be tidy'd up, but the thing I wanted to chagne more was the html pages for the site. --jason On Mar 7, 2007, at 10:47 AM, Sachin Patel wrote: If the URL changes for the site.xml changes it will break things from an update manager perspective. The URL to the eclipse related files need to stay the same. Please do not move these. -sachin On Mar 7, 2007, at 1:21 PM, Hernan Cunico wrote: This is more a organizational kind of question. How should we maintain the eclipse-plugin specific content (other than eclipse-plugin.html that could be in the root dir). There is currently a devtools directory that contains some eclipse- plugin related files. Should we create a new sub-dir under devtools for each subproject and move the content there? Cheers! Hernan Sachin Patel wrote: Ok, I see how this could clarrify things. I don't have a problem with this. -sachin On Mar 7, 2007, at 12:32 PM, Jason Dillon wrote: Primarily its the link on the site (in the side-nav) and the name of the page which is linked to, though I have read emails in the past too which talk about devtools when they meant eclipse-plugin. Anyways, when we get more devtools sub- projects I think each should have their own page and a separate link... and their own JIRA. I don't like the umbrella page. For example, I'd like to see: -- | Development Tools | -- | Eclipse Plugin | --- links to eclipse-plugin.html | Netbeans Plugin | --- links to netbeans-plugin.html | ... (sorry evil ascii art) the NB thing is an example, since AFAIK we don't have one of those yet. --jason On Mar 7, 2007, at 5:44 AM, Sachin Patel wrote: I don't understand. What is currently named devtools besides the link on the site? I favor what we have currently, but if you feel strongly about this, I will not object any changes you make. -sachin On Mar 6, 2007, at 5:38 PM, Jacek Laskowski wrote: On 3/6/07, Jason Dillon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I guess the thing I don't really like right now... is that we refer to the eclipse-plugin as devtools interchangeably. I believe that should change... and I think the way to make that change is to start renaming stuff that was previously devtools (which was solely for eclipse tooling support) to eclipse-plugin. I second that. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Web site schema links broken
I wouldn't say they are broken... they are just plain missing. ;-) --jason On Mar 7, 2007, at 11:14 AM, Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
[jira] Resolved: (SM-871) Optimize EndpointSupport.getKey, EndpointSupport.getUniqueKey, MessageExchange.setMessage, and DeliveryChannel.getKeyForExchange
[ https://issues.apache.org/activemq/browse/SM-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-871. Resolution: Fixed Author: gnodet Date: Wed Mar 7 11:09:09 2007 New Revision: 515699 URL: http://svn.apache.org/viewvc?view=revrev=515699 Log: SM-871: Several small optimizations Modified: incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/messaging/DeliveryChannelImpl.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/messaging/MessageExchangeImpl.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/AbstractServiceEndpoint.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/DynamicEndpoint.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/EndpointSupport.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/ExternalEndpoint.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/InternalEndpoint.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/LinkedEndpoint.java Author: gnodet Date: Wed Mar 7 11:13:37 2007 New Revision: 515701 URL: http://svn.apache.org/viewvc?view=revrev=515701 Log: SM-871: Several small optimizations Modified: incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/messaging/DeliveryChannelImpl.java incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/messaging/MessageExchangeImpl.java incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/AbstractServiceEndpoint.java incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/DynamicEndpoint.java incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/EndpointSupport.java incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/ExternalEndpoint.java incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/InternalEndpoint.java incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/servicedesc/LinkedEndpoint.java Optimize EndpointSupport.getKey, EndpointSupport.getUniqueKey, MessageExchange.setMessage, and DeliveryChannel.getKeyForExchange Key: SM-871 URL: https://issues.apache.org/activemq/browse/SM-871 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Affects Versions: 3.1 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1, 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Web site schema links broken
they are not broken, they are just not there because we never got them in on the old site ;-) I still need get this info updated (unless somebody wants to volunteer? it will be a great experience with the new site!!! :-p ) Cheers! Hernan Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Re: Web site schema links broken
Probably just use: http://geronimo.apache.org/schemas-1.1/ http://geronimo.apache.org/schemas-1.0/ And then map those urls up to the page content. Or use this for reference: http://svn.apache.org/repos/asf/geronimo/site/tags/pre- confluence/docs/schemas.html --jason On Mar 7, 2007, at 11:26 AM, Hernan Cunico wrote: they are not broken, they are just not there because we never got them in on the old site ;-) I still need get this info updated (unless somebody wants to volunteer? it will be a great experience with the new site!!! :-p ) Cheers! Hernan Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Re: Web site schema links broken
On 3/7/07, Jason Dillon [EMAIL PROTECTED] wrote: I wouldn't say they are broken... they are just plain missing. ;-) True. They must live on the East coast, and have escaped to a warmer climate. :) Thanks, Aaron On Mar 7, 2007, at 11:14 AM, Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Re: Web site schema links broken
yeah, I can use those as a guidance but I'm not really sure about all the schemas or versions each of the releases (that is 1.1.1, 1.2 and 2.0) are depending on. for 1.1.1 I'm guessing there are no changes, how about for 1.2 or 2.0. Can you guys chime in with some info, I'll be happy to do the updates on the site. Cheers! Hernan Jason Dillon wrote: Probably just use: http://geronimo.apache.org/schemas-1.1/ http://geronimo.apache.org/schemas-1.0/ And then map those urls up to the page content. Or use this for reference: http://svn.apache.org/repos/asf/geronimo/site/tags/pre-confluence/docs/schemas.html --jason On Mar 7, 2007, at 11:26 AM, Hernan Cunico wrote: they are not broken, they are just not there because we never got them in on the old site ;-) I still need get this info updated (unless somebody wants to volunteer? it will be a great experience with the new site!!! :-p ) Cheers! Hernan Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Re: Web site schema links broken
No clue... I'd just get the new page with all of the links from the old page for now... worry about 1.1.1 1.2. 2.0... aaahhh later ;-) --jason On Mar 7, 2007, at 12:49 PM, Hernan Cunico wrote: yeah, I can use those as a guidance but I'm not really sure about all the schemas or versions each of the releases (that is 1.1.1, 1.2 and 2.0) are depending on. for 1.1.1 I'm guessing there are no changes, how about for 1.2 or 2.0. Can you guys chime in with some info, I'll be happy to do the updates on the site. Cheers! Hernan Jason Dillon wrote: Probably just use: http://geronimo.apache.org/schemas-1.1/ http://geronimo.apache.org/schemas-1.0/ And then map those urls up to the page content. Or use this for reference: http://svn.apache.org/repos/asf/geronimo/site/tags/pre- confluence/docs/schemas.html --jason On Mar 7, 2007, at 11:26 AM, Hernan Cunico wrote: they are not broken, they are just not there because we never got them in on the old site ;-) I still need get this info updated (unless somebody wants to volunteer? it will be a great experience with the new site!!! :-p ) Cheers! Hernan Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Re: Web site schema links broken
I think we should post 1.2/2.0 links when those releases go final (so we can post the final schemas). I don't know that it's worth trying to keep them up to date for non-final releases or actively developed code. As far as schemas for maintenance release, I would hope there were no changes, but if there are, ideally, we'd put a comment to that effect in the header and just post (hypothetically) the modified 1.1.2 schema as the official 1.1.x schema and don't worry about trying to reflect the previous =1.1.1 schema on the web site. Thanks, Aaron On 3/7/07, Hernan Cunico [EMAIL PROTECTED] wrote: yeah, I can use those as a guidance but I'm not really sure about all the schemas or versions each of the releases (that is 1.1.1, 1.2 and 2.0) are depending on. for 1.1.1 I'm guessing there are no changes, how about for 1.2 or 2.0. Can you guys chime in with some info, I'll be happy to do the updates on the site. Cheers! Hernan Jason Dillon wrote: Probably just use: http://geronimo.apache.org/schemas-1.1/ http://geronimo.apache.org/schemas-1.0/ And then map those urls up to the page content. Or use this for reference: http://svn.apache.org/repos/asf/geronimo/site/tags/pre-confluence/docs/schemas.html --jason On Mar 7, 2007, at 11:26 AM, Hernan Cunico wrote: they are not broken, they are just not there because we never got them in on the old site ;-) I still need get this info updated (unless somebody wants to volunteer? it will be a great experience with the new site!!! :-p ) Cheers! Hernan Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Re: Web site schema links broken
I'll stick to what we already have then ;-) Cheers! Hernan Aaron Mulder wrote: I think we should post 1.2/2.0 links when those releases go final (so we can post the final schemas). I don't know that it's worth trying to keep them up to date for non-final releases or actively developed code. As far as schemas for maintenance release, I would hope there were no changes, but if there are, ideally, we'd put a comment to that effect in the header and just post (hypothetically) the modified 1.1.2 schema as the official 1.1.x schema and don't worry about trying to reflect the previous =1.1.1 schema on the web site. Thanks, Aaron On 3/7/07, Hernan Cunico [EMAIL PROTECTED] wrote: yeah, I can use those as a guidance but I'm not really sure about all the schemas or versions each of the releases (that is 1.1.1, 1.2 and 2.0) are depending on. for 1.1.1 I'm guessing there are no changes, how about for 1.2 or 2.0. Can you guys chime in with some info, I'll be happy to do the updates on the site. Cheers! Hernan Jason Dillon wrote: Probably just use: http://geronimo.apache.org/schemas-1.1/ http://geronimo.apache.org/schemas-1.0/ And then map those urls up to the page content. Or use this for reference: http://svn.apache.org/repos/asf/geronimo/site/tags/pre-confluence/docs/schemas.html --jason On Mar 7, 2007, at 11:26 AM, Hernan Cunico wrote: they are not broken, they are just not there because we never got them in on the old site ;-) I still need get this info updated (unless somebody wants to volunteer? it will be a great experience with the new site!!! :-p ) Cheers! Hernan Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Re: Web site schema links broken
I'd still like to see the schemas get put into the mvn generated sites so they are always updated. And then we'd have to have per- version site deployed, which isn't that hard to implement... should eventually do that so we have per-version javadocs, maven-plugin docs and other stuff. --jason On Mar 7, 2007, at 1:13 PM, Aaron Mulder wrote: I think we should post 1.2/2.0 links when those releases go final (so we can post the final schemas). I don't know that it's worth trying to keep them up to date for non-final releases or actively developed code. As far as schemas for maintenance release, I would hope there were no changes, but if there are, ideally, we'd put a comment to that effect in the header and just post (hypothetically) the modified 1.1.2 schema as the official 1.1.x schema and don't worry about trying to reflect the previous =1.1.1 schema on the web site. Thanks, Aaron On 3/7/07, Hernan Cunico [EMAIL PROTECTED] wrote: yeah, I can use those as a guidance but I'm not really sure about all the schemas or versions each of the releases (that is 1.1.1, 1.2 and 2.0) are depending on. for 1.1.1 I'm guessing there are no changes, how about for 1.2 or 2.0. Can you guys chime in with some info, I'll be happy to do the updates on the site. Cheers! Hernan Jason Dillon wrote: Probably just use: http://geronimo.apache.org/schemas-1.1/ http://geronimo.apache.org/schemas-1.0/ And then map those urls up to the page content. Or use this for reference: http://svn.apache.org/repos/asf/geronimo/site/tags/pre- confluence/docs/schemas.html --jason On Mar 7, 2007, at 11:26 AM, Hernan Cunico wrote: they are not broken, they are just not there because we never got them in on the old site ;-) I still need get this info updated (unless somebody wants to volunteer? it will be a great experience with the new site!!! :- p ) Cheers! Hernan Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Problem with svn head, TagLibConfiguration, xerces, and jdk 1.5 (in geronimo)
I'm trying to run svn head inside the geronimo integration and ran into a bizarre problem (yet again, see below) in which xerces is closing a JarUrlStream which closes the entire ZipFile thus preventing any further access to the jar file. Going back to 6.1.0 fixes the problem. The relevant part of the stacktraces I get look like: java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:518) at java.util.zip.ZipFile.getInputStream(ZipFile.java:300) at java.util.zip.ZipFile.getInputStream(ZipFile.java:286) at java.util.jar.JarFile.getInputStream(JarFile.java:387) at sun.net.www.protocol.jar.JarURLConnection.getInputStream (JarURLConnection.java:136) at org.mortbay.resource.URLResource.getInputStream (URLResource.java:206) at org.mortbay.resource.JarResource.getInputStream (JarResource.java:106) at org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp (TagLibConfiguration.java:189) at org.mortbay.jetty.webapp.WebAppContext.startContext (WebAppContext.java:1171) at org.mortbay.jetty.handler.ContextHandler.doStart (ContextHandler.java:501) at org.mortbay.jetty.webapp.WebAppContext.doStart (WebAppContext.java:444) Putting a breakpoing on ZipFile.close() I found that xerxes (I think the one in the apple 1.5.0_07 vm) is calling the close method when it's just trying to close an input stream from a jar entry. I ran across this problem a couple years ago and solved it with an UnclosableInputStream that ignored close calls, but I don't quite see how to apply such a solution here. Before I spend more time looking I wonder if anyone else has seen anything like this and might have advice on a solution. thanks david jencks
Re: Web site schema links broken
Done, we should see the updates in 5 after the hour ;-) Cheers! Hernan Hernan Cunico wrote: I'll stick to what we already have then ;-) Cheers! Hernan Aaron Mulder wrote: I think we should post 1.2/2.0 links when those releases go final (so we can post the final schemas). I don't know that it's worth trying to keep them up to date for non-final releases or actively developed code. As far as schemas for maintenance release, I would hope there were no changes, but if there are, ideally, we'd put a comment to that effect in the header and just post (hypothetically) the modified 1.1.2 schema as the official 1.1.x schema and don't worry about trying to reflect the previous =1.1.1 schema on the web site. Thanks, Aaron On 3/7/07, Hernan Cunico [EMAIL PROTECTED] wrote: yeah, I can use those as a guidance but I'm not really sure about all the schemas or versions each of the releases (that is 1.1.1, 1.2 and 2.0) are depending on. for 1.1.1 I'm guessing there are no changes, how about for 1.2 or 2.0. Can you guys chime in with some info, I'll be happy to do the updates on the site. Cheers! Hernan Jason Dillon wrote: Probably just use: http://geronimo.apache.org/schemas-1.1/ http://geronimo.apache.org/schemas-1.0/ And then map those urls up to the page content. Or use this for reference: http://svn.apache.org/repos/asf/geronimo/site/tags/pre-confluence/docs/schemas.html --jason On Mar 7, 2007, at 11:26 AM, Hernan Cunico wrote: they are not broken, they are just not there because we never got them in on the old site ;-) I still need get this info updated (unless somebody wants to volunteer? it will be a great experience with the new site!!! :-p ) Cheers! Hernan Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
Re: Web site schema links broken
Done, we should see the updates in 5 after the hour ;-) Cheers! Hernan Cunico wrote: I'll stick to what we already have then ;-) Cheers! Hernan Aaron Mulder wrote: I think we should post 1.2/2.0 links when those releases go final (so we can post the final schemas). I don't know that it's worth trying to keep them up to date for non-final releases or actively developed code. As far as schemas for maintenance release, I would hope there were no changes, but if there are, ideally, we'd put a comment to that effect in the header and just post (hypothetically) the modified 1.1.2 schema as the official 1.1.x schema and don't worry about trying to reflect the previous =1.1.1 schema on the web site. Thanks, Aaron On 3/7/07, Hernan Cunico [EMAIL PROTECTED] wrote: yeah, I can use those as a guidance but I'm not really sure about all the schemas or versions each of the releases (that is 1.1.1, 1.2 and 2.0) are depending on. for 1.1.1 I'm guessing there are no changes, how about for 1.2 or 2.0. Can you guys chime in with some info, I'll be happy to do the updates on the site. Cheers! Hernan Jason Dillon wrote: Probably just use: http://geronimo.apache.org/schemas-1.1/ http://geronimo.apache.org/schemas-1.0/ And then map those urls up to the page content. Or use this for reference: http://svn.apache.org/repos/asf/geronimo/site/tags/pre-confluence/docs/schemas.html --jason On Mar 7, 2007, at 11:26 AM, Hernan Cunico wrote: they are not broken, they are just not there because we never got them in on the old site ;-) I still need get this info updated (unless somebody wants to volunteer? it will be a great experience with the new site!!! :-p ) Cheers! Hernan Aaron Mulder wrote: So we talked about removing the Sun schemas from our site. But I don't get it -- now all the links to the Geronimo schemas are just plain text instead of links?? The whole point of having that page is so that people can click through to the actual Geronimo schemas. http://geronimo.apache.org/xml-schemas.html Thanks, Aaron
[jira] Commented: (GERONIMO-2887) Hook up injections for jetty and app client
[ https://issues.apache.org/jira/browse/GERONIMO-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478915 ] David Jencks commented on GERONIMO-2887: rev 515780 uses Holder everywhere and cleans up app client code a lot. Hook up injections for jetty and app client --- Key: GERONIMO-2887 URL: https://issues.apache.org/jira/browse/GERONIMO-2887 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 2.0 Attachments: GERONIMO-2887.patch Now all the annotations are getting put into the xml dd. We need to actually use this info to do the injections for jetty and the app client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2841) Valve reports request method as GET even though POST request was made
[ https://issues.apache.org/jira/browse/GERONIMO-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478918 ] Paul McMahan commented on GERONIMO-2841: The test case asks for: URL url = new URL(baseURL + warName + /JAXWSBean) When tomcat sees that request URI it redirects the request to http://.../JAXWSBean/ (note the appended slash). The testcase's URLConnection is configured to follow redirects but uses GET instead of POST on the ensuing request. Changing the test case to use this URL fixed the problem for me: URL url = new URL(baseURL + warName + /JAXWSBean/) Valve reports request method as GET even though POST request was made - Key: GERONIMO-2841 URL: https://issues.apache.org/jira/browse/GERONIMO-2841 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Reporter: Jarek Gawor The Request of EJBWebServiceValve in Tomcat return the request method as GET even though POST request was sent. In similar class in Jetty the request method is reported correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-2841) Valve reports request method as GET even though POST request was made
[ https://issues.apache.org/jira/browse/GERONIMO-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved GERONIMO-2841. Resolution: Invalid Assignee: Paul McMahan Please reopen if tomcat's current behavior is not acceptable for invoking web services. Valve reports request method as GET even though POST request was made - Key: GERONIMO-2841 URL: https://issues.apache.org/jira/browse/GERONIMO-2841 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Reporter: Jarek Gawor Assigned To: Paul McMahan The Request of EJBWebServiceValve in Tomcat return the request method as GET even though POST request was sent. In similar class in Jetty the request method is reported correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2454) Upgrade xerces to version 2.8.1
[ https://issues.apache.org/jira/browse/GERONIMO-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478922 ] David Jencks commented on GERONIMO-2454: Finally took Anita's hint and removed xml stuff from lib/endorsed in rev 515796. Upgrade xerces to version 2.8.1 --- Key: GERONIMO-2454 URL: https://issues.apache.org/jira/browse/GERONIMO-2454 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: common Affects Versions: 1.2 Environment: All Reporter: Heinz Drews Assigned To: David Jencks Priority: Minor Fix For: 1.2, 2.0-M3 Attachments: xercesupgrade.diff, xercesupgrade2.diff, xercesupgrade3.diff Upgrade xerces to version 2.8.1. Consolidate to use xml-apis instead of xmlParserAPIs. I'll attach a path for several pom.xml. It would be necessary to upload the xerces and xml-apis to the repository -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problem with svn head, TagLibConfiguration, xerces, and jdk 1.5 (in geronimo)
When we've had problems like this before, we passed the offending library with an unclosable stream. -dain On Mar 7, 2007, at 1:29 PM, David Jencks wrote: I'm trying to run svn head inside the geronimo integration and ran into a bizarre problem (yet again, see below) in which xerces is closing a JarUrlStream which closes the entire ZipFile thus preventing any further access to the jar file. Going back to 6.1.0 fixes the problem. The relevant part of the stacktraces I get look like: java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:518) at java.util.zip.ZipFile.getInputStream(ZipFile.java:300) at java.util.zip.ZipFile.getInputStream(ZipFile.java:286) at java.util.jar.JarFile.getInputStream(JarFile.java:387) at sun.net.www.protocol.jar.JarURLConnection.getInputStream (JarURLConnection.java:136) at org.mortbay.resource.URLResource.getInputStream (URLResource.java:206) at org.mortbay.resource.JarResource.getInputStream (JarResource.java:106) at org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp (TagLibConfiguration.java:189) at org.mortbay.jetty.webapp.WebAppContext.startContext (WebAppContext.java:1171) at org.mortbay.jetty.handler.ContextHandler.doStart (ContextHandler.java:501) at org.mortbay.jetty.webapp.WebAppContext.doStart (WebAppContext.java:444) Putting a breakpoing on ZipFile.close() I found that xerxes (I think the one in the apple 1.5.0_07 vm) is calling the close method when it's just trying to close an input stream from a jar entry. I ran across this problem a couple years ago and solved it with an UnclosableInputStream that ignored close calls, but I don't quite see how to apply such a solution here. Before I spend more time looking I wonder if anyone else has seen anything like this and might have advice on a solution. thanks david jencks
[jira] Created: (GERONIMO-2939) JAXWS Client Failed for Axis2
JAXWS Client Failed for Axis2 - Key: GERONIMO-2939 URL: https://issues.apache.org/jira/browse/GERONIMO-2939 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Reporter: Lasantha Ranaweera Axis2 related JAXWS web services are getting failed due to the wrong JAXWS provider. This small patch will make things work for web services clients. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2939) JAXWS Client Failed for Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lasantha Ranaweera updated GERONIMO-2939: - Attachment: GERONIMO-2939.patch This is one way to set the JAXWS provider as a system properties. JAXWS Client Failed for Axis2 - Key: GERONIMO-2939 URL: https://issues.apache.org/jira/browse/GERONIMO-2939 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Reporter: Lasantha Ranaweera Attachments: GERONIMO-2939.patch Axis2 related JAXWS web services are getting failed due to the wrong JAXWS provider. This small patch will make things work for web services clients. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2939) JAXWS Client Failed for Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Genender closed GERONIMO-2939. --- Resolution: Fixed Fix Version/s: 2.0-beta1 Committed revision 515866. JAXWS Client Failed for Axis2 - Key: GERONIMO-2939 URL: https://issues.apache.org/jira/browse/GERONIMO-2939 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Reporter: Lasantha Ranaweera Fix For: 2.0-beta1 Attachments: GERONIMO-2939.patch Axis2 related JAXWS web services are getting failed due to the wrong JAXWS provider. This small patch will make things work for web services clients. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2838) Fix Transaction Recovery bug
[ https://issues.apache.org/jira/browse/GERONIMO-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-2838. -- Resolution: Fixed Fix Version/s: (was: 1.2) (was: 2.0) 2.0-beta1 Transaction Recovery is looking much better. Basic flows seem to be working, correctly. If any other problems pop up, we can fix in other Jiras. Multiple problems were fixed. First, XAResources were not being identified as recoverable resources. Next, database configuration was occurring too late during server startup. So, DB creation and/or access was not working properly. Next, ActivationSpecs were not being properly added to the ResourceManagers ReferenceCollection. So, MDB's would never be recovered... Fix Transaction Recovery bug Key: GERONIMO-2838 URL: https://issues.apache.org/jira/browse/GERONIMO-2838 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1, 1.2, 2.0 Reporter: Kevan Miller Assigned To: Kevan Miller Priority: Critical Fix For: 2.0-beta1 On server restart, Geronimo is not cleaning up in doubt transactions. Problem is that ManagedConnectionInfo's are not being properly initialized -- they don't realize they have XA Resources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-2838) Fix Transaction Recovery bug
[ https://issues.apache.org/jira/browse/GERONIMO-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reopened GERONIMO-2838: Fix Transaction Recovery bug Key: GERONIMO-2838 URL: https://issues.apache.org/jira/browse/GERONIMO-2838 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1, 1.2, 2.0 Reporter: Kevan Miller Assigned To: Kevan Miller Priority: Critical Fix For: 1.2, 2.0-beta1 On server restart, Geronimo is not cleaning up in doubt transactions. Problem is that ManagedConnectionInfo's are not being properly initialized -- they don't realize they have XA Resources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2838) Fix Transaction Recovery bug
[ https://issues.apache.org/jira/browse/GERONIMO-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-2838. -- Resolution: Fixed Fix Version/s: 1.2 Updated fix versions to include 1.2 Fix Transaction Recovery bug Key: GERONIMO-2838 URL: https://issues.apache.org/jira/browse/GERONIMO-2838 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1, 1.2, 2.0 Reporter: Kevan Miller Assigned To: Kevan Miller Priority: Critical Fix For: 1.2, 2.0-beta1 On server restart, Geronimo is not cleaning up in doubt transactions. Problem is that ManagedConnectionInfo's are not being properly initialized -- they don't realize they have XA Resources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
Yep... It looks awsome. Gr8 work. :) Lasantha we can easily do that by adding a label to the news we create. We need to come up with a standard set of labels tho Maybe just news and events will do it. Cheers! Hernan Sachin Patel wrote: Also with conference season arriving, what if we broke the news section into 2, News Events and the events sections could contain any BOF and Session Information? -sachin On Mar 7, 2007, at 1:05 PM, Sachin Patel wrote: Yes, looks really great! One comment however is that the font sizes look a little out of whack to me. Seems like the News section title should be a bigger font then each news entry. -sachin On Mar 7, 2007, at 12:59 PM, Jacek Laskowski wrote: Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r515866 - /geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
Jeff,
Once this change [1] in Axis2 propagates to the m2 snapshot repo's (by
tomorrow AM). You can take remove the System.setProperty hack
thanks,
dims
[1] http://svn.apache.org/viewvc?view=revrevision=515891
On 3/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jgenender
Date: Wed Mar 7 16:29:23 2007
New Revision: 515866
URL: http://svn.apache.org/viewvc?view=revrev=515866
Log:
GERONIMO-2939
Modified:
geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
Modified:
geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java?view=diffrev=515866r1=515865r2=515866
==
---
geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
(original)
+++
geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
Wed Mar 7 16:29:23 2007
@@ -30,6 +30,7 @@
String handlerChainsXML,
MapObject, EndpointInfo seiInfoMap) {
super(handlerChainsXML, seiInfoMap, name, serviceQName, wsdlURI,
referenceClassName, serviceClassName);
+System.setProperty(javax.xml.ws.spi.Provider,
org.apache.axis2.jaxws.spi.Provider);
}
protected HandlerChainsType getHandlerChains() {
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: svn commit: r515866 - /geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
Thanks...let me know...
Jeff
Davanum Srinivas wrote:
Jeff,
Once this change [1] in Axis2 propagates to the m2 snapshot repo's (by
tomorrow AM). You can take remove the System.setProperty hack
thanks,
dims
[1] http://svn.apache.org/viewvc?view=revrevision=515891
On 3/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jgenender
Date: Wed Mar 7 16:29:23 2007
New Revision: 515866
URL: http://svn.apache.org/viewvc?view=revrev=515866
Log:
GERONIMO-2939
Modified:
geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
Modified:
geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java?view=diffrev=515866r1=515865r2=515866
==
---
geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
(original)
+++
geronimo/server/trunk/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/client/Axis2ServiceReference.java
Wed Mar 7 16:29:23 2007
@@ -30,6 +30,7 @@
String handlerChainsXML,
MapObject, EndpointInfo seiInfoMap) {
super(handlerChainsXML, seiInfoMap, name, serviceQName,
wsdlURI, referenceClassName, serviceClassName);
+System.setProperty(javax.xml.ws.spi.Provider,
org.apache.axis2.jaxws.spi.Provider);
}
protected HandlerChainsType getHandlerChains() {
wiki link dead
It seems that the wiki link is dead on the page http://geronimo.apache.org/source-code.html under Building Geronimo from Source, heres the fragment h3a name=SourceCode-BuildingGeronimofromSource/aBuilding Geronimo from Source/h3 pRefer to the a href=../geronimo/index.html title=View Apache Geronimo Documentation spaceWiki/a for the build procedure. It typically takes 10-30 minutes for a full build, and it needs to be run while online in order to download or update a large number of dependencies./p
Re: wiki link dead
Fixed, pending sync to update. For now just look here: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- maven-2.html Thanks :-) --jason On Mar 7, 2007, at 6:42 PM, Don Hill wrote: It seems that the wiki link is dead on the page http:// geronimo.apache.org/source-code.html under Building Geronimo from Source, heres the fragment h3a name=SourceCode-BuildingGeronimofromSource /aBuilding Geronimo from Source/h3 pRefer to the a href=../geronimo/index.html title=View Apache Geronimo Documentation space Wiki/a for the build procedure. It typically takes 10-30 minutes for a full build, and it needs to be run while online in order to download or update a large number of dependencies./ p
Re: Problem with svn head, TagLibConfiguration, xerces, and jdk 1.5 (in geronimo)
Hi David, There were some changes to the TagLibConfiguration class recently. They might be tickling this xerces/apple issue. I've put in what I believe is a fix - svn rev 1645. Could you possibly try it out as I don't have a mac :-) I've also opened this issue to track it: http://jira.codehaus.org/browse/JETTY-254 cheers Jan David Jencks wrote: I'm trying to run svn head inside the geronimo integration and ran into a bizarre problem (yet again, see below) in which xerces is closing a JarUrlStream which closes the entire ZipFile thus preventing any further access to the jar file. Going back to 6.1.0 fixes the problem. The relevant part of the stacktraces I get look like: java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:518) at java.util.zip.ZipFile.getInputStream(ZipFile.java:300) at java.util.zip.ZipFile.getInputStream(ZipFile.java:286) at java.util.jar.JarFile.getInputStream(JarFile.java:387) at sun.net.www.protocol.jar.JarURLConnection.getInputStream (JarURLConnection.java:136) at org.mortbay.resource.URLResource.getInputStream (URLResource.java:206) at org.mortbay.resource.JarResource.getInputStream (JarResource.java:106) at org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp (TagLibConfiguration.java:189) at org.mortbay.jetty.webapp.WebAppContext.startContext (WebAppContext.java:1171) at org.mortbay.jetty.handler.ContextHandler.doStart (ContextHandler.java:501) at org.mortbay.jetty.webapp.WebAppContext.doStart (WebAppContext.java:444) Putting a breakpoing on ZipFile.close() I found that xerxes (I think the one in the apple 1.5.0_07 vm) is calling the close method when it's just trying to close an input stream from a jar entry. I ran across this problem a couple years ago and solved it with an UnclosableInputStream that ignored close calls, but I don't quite see how to apply such a solution here. Before I spend more time looking I wonder if anyone else has seen anything like this and might have advice on a solution. thanks david jencks - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
The new site looks really good! :-) One question, I seem to have a hard time in locating the Java EE 5 report card, which I remember was on the left panel previously? Wonder if you removed that on purpose or my memory was poor.:-) Lin Hernan Cunico wrote: we can easily do that by adding a label to the news we create. We need to come up with a standard set of labels tho Maybe just news and events will do it. Cheers! Hernan Sachin Patel wrote: Also with conference season arriving, what if we broke the news section into 2, News Events and the events sections could contain any BOF and Session Information? -sachin On Mar 7, 2007, at 1:05 PM, Sachin Patel wrote: Yes, looks really great! One comment however is that the font sizes look a little out of whack to me. Seems like the News section title should be a bigger font then each news entry. -sachin On Mar 7, 2007, at 12:59 PM, Jacek Laskowski wrote: Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Whoa! The website is sooo beautiful and the logo astounded me much!
Fixed. Will show up in an hour or so. --jason On Mar 7, 2007, at 9:07 PM, Lin Sun wrote: The new site looks really good! :-) One question, I seem to have a hard time in locating the Java EE 5 report card, which I remember was on the left panel previously? Wonder if you removed that on purpose or my memory was poor.:-) Lin Hernan Cunico wrote: we can easily do that by adding a label to the news we create. We need to come up with a standard set of labels tho Maybe just news and events will do it. Cheers! Hernan Sachin Patel wrote: Also with conference season arriving, what if we broke the news section into 2, News Events and the events sections could contain any BOF and Session Information? -sachin On Mar 7, 2007, at 1:05 PM, Sachin Patel wrote: Yes, looks really great! One comment however is that the font sizes look a little out of whack to me. Seems like the News section title should be a bigger font then each news entry. -sachin On Mar 7, 2007, at 12:59 PM, Jacek Laskowski wrote: Hi, Just opened the website and got struck with the beauty of it. I'm not saying the previous website style was worse - it's just that it's fresh. I like it. Besides, I see the conferences I'm presenting Geronimo at are there. Thanks Hernan! p.s. I wonder why Jason hasn't announced it to the public yet? Does he want us - the faint-hearted - to suffer a great pain of excitement? ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
