[jira] Commented: (SM-915) FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
[
https://issues.apache.org/activemq/browse/SM-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38945
]
Guillaume Nodet commented on SM-915:
You're right. The sendSync command may throw an exception.
I'm not sure if this happens in this case, but it needs to be fixed anyway.
FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
Key: SM-915
URL: https://issues.apache.org/activemq/browse/SM-915
Project: ServiceMix
Issue Type: Bug
Components: servicemix-ftp
Affects Versions: 3.1
Reporter: Gert Vanthienen
FTP poller threads stop working with the stack trace below, causing the FTP
client pool to run out of connections
{code}
Name: pool-component.servicemix-ftp-thread-2
State: RUNNABLE
Total blocked: 78,430 Total waited: 4,771
Stack trace:
java.net.PlainSocketImpl.socketAccept(Native Method)
java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
java.net.ServerSocket.implAccept(ServerSocket.java:450)
java.net.ServerSocket.accept(ServerSocket.java:421)
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502)
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2390)
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2364)
org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141)
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:211)
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:203)
org.apache.servicemix.ftp.FtpPollerEndpoint.poll(FtpPollerEndpoint.java:78)
org.apache.servicemix.common.endpoints.PollingEndpoint$PollSchedulerTask$1.run(PollingEndpoint.java:155)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
java.lang.Thread.run(Thread.java:595)
{code}
See http://www.nabble.com/FTP-poller-stalls...-tf3490690s12049.html for more
information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-915) FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
[
https://issues.apache.org/activemq/browse/SM-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen updated SM-915:
---
Attachment: SM-915.patch
The patch file makes sure that the inputstream is always closed -- followed by
the required call to {{completePendingCommand}}.
FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
Key: SM-915
URL: https://issues.apache.org/activemq/browse/SM-915
Project: ServiceMix
Issue Type: Bug
Components: servicemix-ftp
Affects Versions: 3.1
Reporter: Gert Vanthienen
Attachments: SM-915.patch
FTP poller threads stop working with the stack trace below, causing the FTP
client pool to run out of connections
{code}
Name: pool-component.servicemix-ftp-thread-2
State: RUNNABLE
Total blocked: 78,430 Total waited: 4,771
Stack trace:
java.net.PlainSocketImpl.socketAccept(Native Method)
java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
java.net.ServerSocket.implAccept(ServerSocket.java:450)
java.net.ServerSocket.accept(ServerSocket.java:421)
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502)
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2390)
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2364)
org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141)
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:211)
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:203)
org.apache.servicemix.ftp.FtpPollerEndpoint.poll(FtpPollerEndpoint.java:78)
org.apache.servicemix.common.endpoints.PollingEndpoint$PollSchedulerTask$1.run(PollingEndpoint.java:155)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
java.lang.Thread.run(Thread.java:595)
{code}
See http://www.nabble.com/FTP-poller-stalls...-tf3490690s12049.html for more
information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-904) The jmx url is wrong if there are spaces at the end of the properties
[ https://issues.apache.org/activemq/browse/SM-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38947 ] Thomas Termin commented on SM-904: -- Backport to 3.1 branch Author: tterm Date: Tue Apr 3 05:01:41 2007 New Revision: 525144 URL: http://svn.apache.org/viewvc?view=revrev=525144 Log: SM-904 The jmx url is wrong if there are spaces at the end of the properties Modified: incubator/servicemix/branches/servicemix-3.1/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/jmx/ConnectorServerFactoryBean.java The jmx url is wrong if there are spaces at the end of the properties - Key: SM-904 URL: https://issues.apache.org/activemq/browse/SM-904 Project: ServiceMix Issue Type: Bug Components: servicemix-core Reporter: Thomas Termin Assigned To: Thomas Termin The jmx.url string is wrong if the properties in servicemix.properties have spaces at the end. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-807) Add jboss-service.xml to servicemix component so they can be properly deployed in jboss.
[ https://issues.apache.org/activemq/browse/SM-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-807. Resolution: Fixed URL: http://svn.apache.org/viewvc?view=revrev=524061 Add jboss-service.xml to servicemix component so they can be properly deployed in jboss. Key: SM-807 URL: https://issues.apache.org/activemq/browse/SM-807 Project: ServiceMix Issue Type: Improvement Components: servicemix-assembly, servicemix-audit, servicemix-bpe, servicemix-common, servicemix-components, servicemix-core, servicemix-drools, servicemix-eip, servicemix-file, servicemix-ftp, servicemix-http, servicemix-jbi, servicemix-jms, servicemix-jsr181, servicemix-lwcontainer, servicemix-quartz, servicemix-saxon, servicemix-sca, servicemix-script, servicemix-soap, servicemix-wsn2005 Affects Versions: 3.1 Environment: JBoss 4.0.5 GA Reporter: Eric Dofonsou Assigned To: Eric Dofonsou Fix For: 3.2 Original Estimate: 1 hour Remaining Estimate: 1 hour Right now there are no dependencies set on the servicemix components to ensure that they are loaded after the servicemix deployer. This can cause bugs when the component are deployed before the servicemix deployer, and thus are not handled by servicemix (and therefore not available). The fix for this is do include a dependence in the META-INF/jboss-service.xml of the component .zip file. here is the content of the file : - ?xml version=1.0 encoding=UTF-8? server dependsorg.servicemix:service=Deployer/depends /server - PS : The servicemix-http component already has a jboss-web.xml see issue (SM-584) file this should be deleted and the content of the new jboss-service.xml file should now be : - server class-loading loader-repository org.apache.commons.httpclient:loader=commons-httpclient-3.0.jar /loader-repository /class-loading dependsorg.servicemix:service=Deployer/depends /server --- Eric, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-910) better handling of unavailable external http services
[
https://issues.apache.org/activemq/browse/SM-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38950
]
Dominique De Vito commented on SM-910:
--
I have done a simple test using a seda flow with a JCA consumer.
sm:flows
sm:sedaFlow /
sm:jcaFlow connectionManager=#connectionManager
jmsURL=${activemq.url} /
/sm:flows
...
sm:activationSpec componentName=inputReceiver_2
sm:component
jms:component
jms:endpoints
jms:endpoint
role=consumer
endpoint=jmsbeginningpoint_2
service=foo:myJmsReceiver_2
connectionFactory=#jmsFactory
targetService=foo:ws_2
synchronous=true
rollbackOnError=true
defaultMep=http://www.w3.org/2004/08/wsdl/in-only;
processorName=jca
bootstrapContext=#bootstrapContext
resourceAdapter=#activemqRA
jms:activationSpec
amqra:activationSpec destination=queue_2
destinationType=javax.jms.Queue /
/jms:activationSpec
/jms:endpoint
/jms:endpoints
/jms:component
/sm:component
/sm:activationSpec
sm:activationSpec componentName=ws_2
sm:component
http:component
http:endpoints
http:endpoint service=foo:ws_2
endpoint=myProvider
role=provider
locationURI=http://localhost:8090/WsListener/index.do;
defaultMep=http://www.w3.org/2004/08/wsdl/in-only;
/
/http:endpoints
/http:component
/sm:component
/sm:activationSpec
The test scenario was the following:
(a) using another pipeline, I have pushed a message into the queue_2
(b) I have run the pipeline defined above WITHOUT running the external web
service provider, than I have got plenty of java.net.ConnectException:
Connection refused: connect.
The traces are full of rollback, no single one commit.
(c) While there was no commit into the traces, and due to
rollbackOnError=true, I was expecting still the message to be into the queue
(called queue_2).
I have re-started ServiceMix and my external web service provider too. I was
expecting ServiceMix to get this message to give it to the external web service
provider now running. But ServiceMix has not treated any message.
I have tested this under servicemix-3.1-incubating et
servicemix-3.2-incubating-20070308.121113-12
While traces include no commit, only rollbacks, I expect the message to be stil
into the queue and ServiceMix to treat it again while restarting. This is not
the case, i.e. when adding synchronous=true rollbackOnError=true, the
message is rollbacked, but after a few number of attempts, it disappears
somewhere.
Can you tell me what happens ?
Where this message goes ?
Why ServiceMix does not treat it again when restarted ?
Did the message go some component DLQ ?
I have found these traces after the last rollback:
DEBUG - AbstractRegion - Adding destination:
queue://ActiveMQ.DLQ
DEBUG - JournalPersistenceAdapter - Waking for checkpoint to complete.
DEBUG - JournalPersistenceAdapter - Checkpoint started.
DEBUG - JournalPersistenceAdapter - Checkpoint done.
DEBUG - JournalMessageStore- Journalled message add for:
ID:p-105825-1398-1175602237242-3:35:1:1:1, at: 0:10457
DEBUG - DLQ- No subscriptions registered, will not
dispatch message at this time.
Thanks.
better handling of unavailable external http services
-
Key: SM-910
URL: https://issues.apache.org/activemq/browse/SM-910
Project: ServiceMix
Issue Type: Improvement
Components: servicemix-http
Affects Versions: 3.1
Reporter: Dominique De Vito
Fix For: 3.1.1
Attachments: patchfile.txt
Original Estimate: 1 hour
Remaining Estimate: 1 hour
The org.apache.servicemix.http.processors.ProviderProcessor calls an external
http service.
When calling an unavailable external http service, the following stack trace
appears after an exception rise:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:516)
at java.net.Socket.connect(Socket.java:466)
at
[jira] Created: (SM-916) Upgrade to ActiveMQ 4.1.1
Upgrade to ActiveMQ 4.1.1 - Key: SM-916 URL: https://issues.apache.org/activemq/browse/SM-916 Project: ServiceMix Issue Type: Task Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-916) Upgrade to ActiveMQ 4.1.1
[ https://issues.apache.org/activemq/browse/SM-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-916. Resolution: Fixed Done at rev. 525153 Upgrade to ActiveMQ 4.1.1 - Key: SM-916 URL: https://issues.apache.org/activemq/browse/SM-916 Project: ServiceMix Issue Type: Task Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-914) Exception upon generating a dot file from the apache-servicemix-web distribution in Tomcat
[
https://issues.apache.org/activemq/browse/SM-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38943
]
Guillaume Nodet commented on SM-914:
Dot is a diagramming tool that can from the dot format to png images.
It can be downloaded at http://www.graphviz.org
Exception upon generating a dot file from the apache-servicemix-web
distribution in Tomcat
---
Key: SM-914
URL: https://issues.apache.org/activemq/browse/SM-914
Project: ServiceMix
Issue Type: Bug
Affects Versions: 3.1
Environment: MacOS X 10.4.8/Tomcat 5.5.20
Reporter: Bruce Snyder
Upon deploying the {{apache-servicemix-web-3.1-incubating.war}} file in
Tomcat 5.5.20 and clicking on the 'View' link in the ServiceMix console, the
following exception is thrown:
{code}
WARN - [dispatcher] - Servlet.service() for servlet
dispatcher threw exception
java.io.IOException: dot: not found
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.init(UNIXProcess.java:52)
at java.lang.ProcessImpl.start(ProcessImpl.java:91)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
at java.lang.Runtime.exec(Runtime.java:591)
at java.lang.Runtime.exec(Runtime.java:429)
at java.lang.Runtime.exec(Runtime.java:326)
at
org.apache.servicemix.web.view.DotView.renderMergedOutputModel(DotView.java:71)
at
org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:249)
at
org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1105)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:841)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:755)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:396)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:350)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.servicemix.web.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:81)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
at
com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:613)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Hi Dain Congratulation! cheers! Kanchana On Fri, 2007-03-30 at 14:26 -0400, Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
[jira] Created: (SM-915) FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
Key: SM-915
URL: https://issues.apache.org/activemq/browse/SM-915
Project: ServiceMix
Issue Type: Bug
Components: servicemix-ftp
Affects Versions: 3.1
Reporter: Gert Vanthienen
FTP poller threads stop working with the stack trace below, causing the FTP
client pool to run out of connections
{code}
Name: pool-component.servicemix-ftp-thread-2
State: RUNNABLE
Total blocked: 78,430 Total waited: 4,771
Stack trace:
java.net.PlainSocketImpl.socketAccept(Native Method)
java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
java.net.ServerSocket.implAccept(ServerSocket.java:450)
java.net.ServerSocket.accept(ServerSocket.java:421)
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502)
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2390)
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2364)
org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141)
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:211)
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:203)
org.apache.servicemix.ftp.FtpPollerEndpoint.poll(FtpPollerEndpoint.java:78)
org.apache.servicemix.common.endpoints.PollingEndpoint$PollSchedulerTask$1.run(PollingEndpoint.java:155)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
java.lang.Thread.run(Thread.java:595)
{code}
See http://www.nabble.com/FTP-poller-stalls...-tf3490690s12049.html for more
information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-915) FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
[
https://issues.apache.org/activemq/browse/SM-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38944
]
Gert Vanthienen commented on SM-915:
Some additional observations - the problem only appears when:
* when a lot of files become available on the FTP server together
* some of them are being downloaded before they are complete, i.e. incomplete
XML messages are being read and processing fails for these messages
In the FTP poller code, we find
{code}
InputStream in = ftp.retrieveFileStream(file);
InOnly exchange = getExchangeFactory().createInOnlyExchange();
configureExchangeTarget(exchange);
NormalizedMessage message = exchange.createMessage();
exchange.setInMessage(message);
marshaler.readMessage(exchange, message, in, file);
sendSync(exchange);
in.close();
ftp.completePendingCommand();
{code}
My question: Is it possible that {{sendSync(exchange)}} throws an Exception
when an incomplete XML message is retrieved from the server? If it does, the
inputstream is never closed and {{completePendingCommand()}} is never called,
which might explain the problems
FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
Key: SM-915
URL: https://issues.apache.org/activemq/browse/SM-915
Project: ServiceMix
Issue Type: Bug
Components: servicemix-ftp
Affects Versions: 3.1
Reporter: Gert Vanthienen
FTP poller threads stop working with the stack trace below, causing the FTP
client pool to run out of connections
{code}
Name: pool-component.servicemix-ftp-thread-2
State: RUNNABLE
Total blocked: 78,430 Total waited: 4,771
Stack trace:
java.net.PlainSocketImpl.socketAccept(Native Method)
java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
java.net.ServerSocket.implAccept(ServerSocket.java:450)
java.net.ServerSocket.accept(ServerSocket.java:421)
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502)
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2390)
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2364)
org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141)
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:211)
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:203)
org.apache.servicemix.ftp.FtpPollerEndpoint.poll(FtpPollerEndpoint.java:78)
org.apache.servicemix.common.endpoints.PollingEndpoint$PollSchedulerTask$1.run(PollingEndpoint.java:155)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
java.lang.Thread.run(Thread.java:595)
{code}
See http://www.nabble.com/FTP-poller-stalls...-tf3490690s12049.html for more
information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] 2.0-M4 Binaries available (rc1)
On Apr 2, 2007, at 6:50 PM, Joe Bohn wrote: David, Very true. I had just assumed that the minimal tomcat config.xml must have included Jasper ... but I see that it doesn't. I did verify again that I can deploy the war on tomcat minimal and it works. When I list-modules I see the jasper config listed and started but not the jasper-deployer. Looking a little further I see that tomcat6 includes a dependency in its pom on jasper with a comment stating that it is required because tomcat and jasper share the LifeCycleProvider interface, or AnnotationProcessor. Jetty doesn't include this same dependency and so it is not included. Ah, hoist by my own petard or something like that :-). I may be able to fix this in my next tomcat proposal. thanks david jencks Joe David Jencks wrote: if jsps work on tomcat without the jasper and jasper-deployer configs then something is wrong :-) Can you double check this? I don't have a real problem including jasper with both jetty and tomcat, but I would prefer to know _how_ its getting included :-) thanks david jencks On Apr 2, 2007, at 3:11 PM, Joe Bohn wrote: To maintain backward compatibility and consistency with the minimal tomcat assembly (I only had this problem with Jetty) I think we need to add Jasper Jasper-Deployer into the assembly. I'll give it a try. JSF is another story. It wasn't included in earlier minimal assemblies so we're not regressing any function if we choose to not include it. I don't have a strong opinion on it one way or the other. Joe David Jencks wrote: ya, I think I figured minimal meant no jsps which no one except greg wilkins might agree with :-). How about jsf? (maybe I'm exaggerating his distaste for jsps) for jsps we need to add the jasper and jasper-builder configs. for jsf we need to add myfaces and myfaces-builder configs. the builder configs need to be loaded, the others can have load=false: any such config needs to be in the pom (yes, I had to build the tomcat-ee config about 4-6 times while I sorted out which went where) thanks david jencks On Apr 2, 2007, at 2:36 PM, Joe Bohn wrote: Joe Bohn wrote: geronimo-jetty6-minimal: - Deploying a simple JSP war resulted in an UnavailableException for org.apache.jasper.servlet.JspServlet from the application classloader and failures attempting to start the GBean. I'll open a JIRA for this issue. I suspect that we're not including the correct jasper item in the classloader of the web app. I think we can push this milestone out even with this error given that people can work with the jetty and the jee5 assembly until this issue is resolved in a subsequent milestone. Created https://issues.apache.org/jira/browse/GERONIMO-3057 Joe
Re: [VOTE] 2.0-M4 Binaries available (rc1)
+1 Jacek On 4/1/07, Matt Hogstrom [EMAIL PROTECTED] wrote: I have placed the 2.0-M4 binaries out on http://people.apache.org/ ~hogstrom/2.0-M4-rc1 for you to take a look at. (They are uploading as I write this). I have done some testing with DayTrader. There is an issue in connecting with he MDB container which still needs to be worked out so the application will not deploy as is. However, given the scopwe of function DayTrader covers as well as all the late code drops I don't see an issue with that. Smaller samples should be ok and tests look good. Given that we're in the final stages of testing I'd like to get this Milestone on the wire as is and fix issues in trunk. Users that pull this binary and report issues will help us in the Drive to 5. Other than that limitation I think this Milestone looks ready to go. After reviewing the content please cast your vote. [ ] +1 - Release these binaries [ ] 0 [ ] -1 Do not release these binaries (provide reason) This vote will conclude on April 4th at 0600 Eastern. Thanks! -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
It is great to welcome you back! Gianny On 31/03/2007, at 4:26 AM, Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
I think we need to look into following issues: 1. Initial startup error caused by https://issues.apache.org/jira/browse/GERONIMO-2941 2. Why is that in console's Application section and deployment list-module, I see all the modules twice? One with the version 2.0-M4, appears as started and one with version 2.0-M4-SNAPSHOT stopped. All the modules also have two folders for two versions. Its not causing any error or exception, but i am just worried as this result in larger size of zip/gz and installed folder, and may also have other effects. 3. Shutdown error. thanks Rakesh On 4/3/07, Jacek Laskowski [EMAIL PROTECTED] wrote: +1 Jacek On 4/1/07, Matt Hogstrom [EMAIL PROTECTED] wrote: I have placed the 2.0-M4 binaries out on http://people.apache.org/ ~hogstrom/2.0-M4-rc1 for you to take a look at. (They are uploading as I write this). I have done some testing with DayTrader. There is an issue in connecting with he MDB container which still needs to be worked out so the application will not deploy as is. However, given the scopwe of function DayTrader covers as well as all the late code drops I don't see an issue with that. Smaller samples should be ok and tests look good. Given that we're in the final stages of testing I'd like to get this Milestone on the wire as is and fix issues in trunk. Users that pull this binary and report issues will help us in the Drive to 5. Other than that limitation I think this Milestone looks ready to go. After reviewing the content please cast your vote. [ ] +1 - Release these binaries [ ] 0 [ ] -1 Do not release these binaries (provide reason) This vote will conclude on April 4th at 0600 Eastern. Thanks! -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Assigned: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3045: -- Assignee: Lin Sun (was: Donald Woods) Unable to run jax-rpc war test with Axis2 - Key: GERONIMO-3045 URL: https://issues.apache.org/jira/browse/GERONIMO-3045 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: 1.5 SUN SDK + WIN XP Reporter: Lin Sun Assigned To: Lin Sun Fix For: 2.0-M5 Attachments: G3045.patch When running the jax-rpc war test with axis2, both test failed due to an exception thrown when parseWebServiceDescriptor is called. from reading the code, if webservices.xml doesn't exist, we call discoverwebservices, which will check if the class has annotation. if webservices.xml exists, we 'll just call parseWebServiceDescriptor, which caused the error for axis2 because axis2 moved to xbeans. The fix is to check if annotation exists when webservices.xml exists also. Tested the fix and able to pass the 2 jax-rpc war test test with them. Will attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2534) Security realms portlet should validate the realm-name for duplicate name
[ https://issues.apache.org/jira/browse/GERONIMO-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2534: --- Patch Info: [Patch Available] Security realms portlet should validate the realm-name for duplicate name - Key: GERONIMO-2534 URL: https://issues.apache.org/jira/browse/GERONIMO-2534 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1, 1.2 Reporter: Vamsavardhana Reddy Fix For: 1.x, 2.0-M5 Attachments: SecurityRealmPortlet.patch, selectType.jsp.patch Add new security realm function does not check if the realm-name entered by the user is already in use. There are no errors shown in the console, whereas the following error is logged: 18:32:12,033 ERROR [ProxyCollection] Listener threw exception java.lang.IllegalArgumentException: ConfigurationEntry already registered at org.apache.geronimo.security.jaas.GeronimoLoginConfiguration.addConfi guration(GeronimoLoginConfiguration.java:115) at org.apache.geronimo.security.jaas.GeronimoLoginConfiguration.memberAd ded(GeronimoLoginConfiguration.java:96) at org.apache.geronimo.gbean.runtime.ProxyCollection.addTarget(ProxyColl ection.java:102) at org.apache.geronimo.gbean.runtime.GBeanCollectionReference.targetAdde d(GBeanCollectionReference.java:96) at org.apache.geronimo.gbean.runtime.GBeanCollectionReference.addTarget( GBeanCollectionReference.java:180) at org.apache.geronimo.gbean.runtime.GBeanCollectionReference$1.running( GBeanCollectionReference.java:110) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:526) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke
[jira] Commented: (GERONIMO-3054) org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement
[ https://issues.apache.org/jira/browse/GERONIMO-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486338 ] Matt Hogstrom commented on GERONIMO-3054: - Many of these files came from Bouncy Castle. We had to break them apart as there was an issue with the Bouncy Castle jars shipping a ptented algorithm. If you simply need the file you can go to www.bouncycastle.org. If not, is there some function that is not working as intended in Geornimo? org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement Key: GERONIMO-3054 URL: https://issues.apache.org/jira/browse/GERONIMO-3054 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1.1 Environment: All Reporter: Ken Priority: Minor Hello, all. I am looking at the source code for several files, and one of them, org.apache.geronimo.util.jce.X509V1CertificateGenerator has the following tag notice: /** * class to produce an X.509 Version 1 certificate. * * @deprecated use the equivalent class in org.apache.geronimo.util.x509 */ I (think I) have looked everywhere for a package named x509 under util, or even a reference to when/how/why/to what it was changed, but can't seem to find one. Where is this replacement class that is mentioned in the deprecation? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (GERONIMO-3054) org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement
Matt, thanks very much for your reply. There may be an issue, with importing a PKCS7 key and its cert chain, but before I brought it up I wanted to make sure I had the latest (read: not deprecated) file. Was this a clean pull from Bouncy Castle? I can't tell because it is packaged with the org.apache namespace instead of the org.bouncycastle namespace. I'm guessing you guys just did a refactor to change the namespace? The latest BouncyCastle release has org.bouncycastle.x509.X509V1CertificateGenerator, which seems to be correct... -Ken At 08:19 AM 4/3/2007, you wrote: [ https://issues.apache.org/jira/browse/GERONIMO-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486338 ] Matt Hogstrom commented on GERONIMO-3054: - Many of these files came from Bouncy Castle. We had to break them apart as there was an issue with the Bouncy Castle jars shipping a ptented algorithm. If you simply need the file you can go to www.bouncycastle.org. If not, is there some function that is not working as intended in Geornimo? org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement Key: GERONIMO-3054 URL: https://issues.apache.org/jira/browse/GERONIMO-3054 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1.1 Environment: All Reporter: Ken Priority: Minor Hello, all. I am looking at the source code for several files, and one of them, org.apache.geronimo.util.jce.X509V1CertificateGenerator has the following tag notice: /** * class to produce an X.509 Version 1 certificate. * * @deprecated use the equivalent class in org.apache.geronimo.util.x509 */ I (think I) have looked everywhere for a package named x509 under util, or even a reference to when/how/why/to what it was changed, but can't seem to find one. Where is this replacement class that is mentioned in the deprecation? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Dain Sundstrom is the newest member of the Geronimo PMC
Congrats!! On 4/3/07, Gianny Damour [EMAIL PROTECTED] wrote: It is great to welcome you back! Gianny On 31/03/2007, at 4:26 AM, Matt Hogstrom wrote: The Apache Geronimo PMC is pleased to announce that Dain Sundstrom has accepted an invitation to join the PMC. Nuf 'said. Welcome :-0 -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
[jira] Created: (GERONIMO-3059) CLIs refactoring - options and arguments parsing should be done prior the boot of a Kernel to provide a quicker feedback to users if they are invalid
CLIs refactoring - options and arguments parsing should be done prior the boot of a Kernel to provide a quicker feedback to users if they are invalid - Key: GERONIMO-3059 URL: https://issues.apache.org/jira/browse/GERONIMO-3059 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: usability Affects Versions: 2.0-M4 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-M5 CLIs options and arguments are parsed after the boot of a Kernel. As the boot of a Kernel, and especially the loading of configurations, are time expensive, users have to wait an unacceptable time to receive a feedback from CLs if these options or arguments are invalid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3054) org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement
[ https://issues.apache.org/jira/browse/GERONIMO-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486348 ] Rick McGuire commented on GERONIMO-3054: The set of files pulled from Bouncy Castle originally were the minimal set needed to implement some of the console features. There was just a global chance of the package name, so that deprecation reference got caught in the Replace All operation and points to a non-existent class. If additional classes are needed to implement Geronimo functions, these can be pulled in if they don't pull in some of the patent-protected algorithms. org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement Key: GERONIMO-3054 URL: https://issues.apache.org/jira/browse/GERONIMO-3054 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1.1 Environment: All Reporter: Ken Priority: Minor Hello, all. I am looking at the source code for several files, and one of them, org.apache.geronimo.util.jce.X509V1CertificateGenerator has the following tag notice: /** * class to produce an X.509 Version 1 certificate. * * @deprecated use the equivalent class in org.apache.geronimo.util.x509 */ I (think I) have looked everywhere for a package named x509 under util, or even a reference to when/how/why/to what it was changed, but can't seem to find one. Where is this replacement class that is mentioned in the deprecation? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3059) CLIs refactoring - options and arguments parsing should be done prior the boot of a Kernel to provide a quicker feedback to users if they are invalid
[ https://issues.apache.org/jira/browse/GERONIMO-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-3059: Attachment: GERONIMO-3059.patch Here is a patch to fix this problem: * Add a geronimo-cli JAR containing all the classes to perform options and arguments parsing. It is included in the lib/ folder and added to the Class-Path manifest entry of the deployer.jar, server.jar and client.jar runnable JARs; * Use commons-cli to perform the option parsing; and * add support for an extra verbose level, -vvv, and remap the verbose level as follows: -v - INFO, -vv - DEBUG, -vvv - TRACE. CLIs refactoring - options and arguments parsing should be done prior the boot of a Kernel to provide a quicker feedback to users if they are invalid - Key: GERONIMO-3059 URL: https://issues.apache.org/jira/browse/GERONIMO-3059 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: usability Affects Versions: 2.0-M4 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-M5 Attachments: GERONIMO-3059.patch CLIs options and arguments are parsed after the boot of a Kernel. As the boot of a Kernel, and especially the loading of configurations, are time expensive, users have to wait an unacceptable time to receive a feedback from CLs if these options or arguments are invalid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: org.apache.geronimo.system.main.Daemon and commons-cli
Hi, As discussed with Jason, I worked on a fix to this problem: GERONIMO-3059. I will be on holiday, with sporadic internet access, for a couple of weeks starting tomorrow night; So, I will not check in these changes now as I will not be able to support related problems, if any. Having said that, Jason, if you are happy to check them in and fix related issues, if any, then I am fine with it :) Thanks, Gianny On 21/03/2007, at 11:05 AM, Sachin Patel wrote: I agree, this is a usability regression. -sachin On Mar 20, 2007, at 5:08 PM, Jason Dillon wrote: You have to wait several seconds for the bootstrap kernel to load... just to display the cli usage... that seems wrong IMO.
[jira] Created: (GERONIMO-3060) Add a separate tree branch for persistence units into the JMX viewer
Add a separate tree branch for persistence units into the JMX viewer Key: GERONIMO-3060 URL: https://issues.apache.org/jira/browse/GERONIMO-3060 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Components: console, persistence Affects Versions: 2.0-M4, 2.0-M5 Reporter: Jay D. McHugh Assigned To: Jay D. McHugh Priority: Minor Added a branch under J2EE Managed Objects that show the persistence unit gbeans. Note: persistence unit gbeans still appear under All MBeans/geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3060) Add a separate tree branch for persistence units into the JMX viewer
[ https://issues.apache.org/jira/browse/GERONIMO-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3060: Attachment: geronimo-3060.patch Add a separate tree branch for persistence units into the JMX viewer Key: GERONIMO-3060 URL: https://issues.apache.org/jira/browse/GERONIMO-3060 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console, persistence Affects Versions: 2.0-M4, 2.0-M5 Reporter: Jay D. McHugh Assigned To: Jay D. McHugh Priority: Minor Attachments: geronimo-3060.patch Added a branch under J2EE Managed Objects that show the persistence unit gbeans. Note: persistence unit gbeans still appear under All MBeans/geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] TRUNK: Failed for Revision: 525155
Building with Maven version: 2.0.5 Revision: 525155 built with tests skipped See the full build-1000.log file at http://people.apache.org/~prasad/binaries/20070403/build-1000.log Downloading: http://tomcat.apache.org/dev/dist/m2-repository//activemq/jmdns/1.0-RC2/jmdns-1.0-RC2.jar [WARNING] Unable to get resource 'activemq:jmdns:jar:1.0-RC2' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository//activemq/jmdns/1.0-RC2/jmdns-1.0-RC2.jar [WARNING] Unable to get resource 'activemq:jmdns:jar:1.0-RC2' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository/activemq/jmdns/1.0-RC2/jmdns-1.0-RC2.jar [WARNING] Unable to get resource 'activemq:jmdns:jar:1.0-RC2' from repository apache.incubating.releases (http://people.apache.org/repo/m2-incubating-repository) Downloading: http://repo1.maven.org/maven2/activemq/jmdns/1.0-RC2/jmdns-1.0-RC2.jar 80K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository//com/sun/xml/bind/jaxb-impl/2.0.3/jaxb-impl-2.0.3.jar [WARNING] Unable to get resource 'com.sun.xml.bind:jaxb-impl:jar:2.0.3' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository//com/sun/xml/bind/jaxb-impl/2.0.3/jaxb-impl-2.0.3.jar [WARNING] Unable to get resource 'com.sun.xml.bind:jaxb-impl:jar:2.0.3' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository/com/sun/xml/bind/jaxb-impl/2.0.3/jaxb-impl-2.0.3.jar [WARNING] Unable to get resource 'com.sun.xml.bind:jaxb-impl:jar:2.0.3' from repository apache-incubating-repository (http://people.apache.org/repo/m2-incubating-repository) Downloading: http://repo1.maven.org/maven2/com/sun/xml/bind/jaxb-impl/2.0.3/jaxb-impl-2.0.3.jar 765K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository//org/apache/openjpa/openjpa-persistence-jdbc/0.9.6-incubating/openjpa-persistence-jdbc-0.9.6-incubating.jar [WARNING] Unable to get resource 'org.apache.openjpa:openjpa-persistence-jdbc:jar:0.9.6-incubating' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-persistence-jdbc/0.9.6-incubating/openjpa-persistence-jdbc-0.9.6-incubating.jar 83K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository//org/apache/geronimo/specs/geronimo-annotation_1.0_spec/1.0/geronimo-annotation_1.0_spec-1.0.jar [WARNING] Unable to get resource 'org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-annotation_1.0_spec/1.0/geronimo-annotation_1.0_spec-1.0.jar [WARNING] Unable to get resource 'org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.0' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/geronimo/specs/geronimo-annotation_1.0_spec/1.0/geronimo-annotation_1.0_spec-1.0.jar [WARNING] Unable to get resource 'org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.0' from repository apache-incubating-repository (http://people.apache.org/repo/m2-incubating-repository) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-annotation_1.0_spec/1.0/geronimo-annotation_1.0_spec-1.0.jar 11K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository//log4j/log4j/1.2.12/log4j-1.2.12.jar [WARNING] Unable to get resource 'log4j:log4j:jar:1.2.12' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository//log4j/log4j/1.2.12/log4j-1.2.12.jar [WARNING] Unable to get resource 'log4j:log4j:jar:1.2.12' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://people.apache.org/repo/m2-incubating-repository/log4j/log4j/1.2.12/log4j-1.2.12.jar [WARNING] Unable to get resource 'log4j:log4j:jar:1.2.12' from repository apache-incubating-repository (http://people.apache.org/repo/m2-incubating-repository) Downloading: http://repo1.maven.org/maven2/log4j/log4j/1.2.12/log4j-1.2.12.jar 349K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository//com/thoughtworks/xstream/xstream/1.2.1/xstream-1.2.1.jar [WARNING] Unable to get resource 'com.thoughtworks.xstream:xstream:jar:1.2.1' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/) Downloading: http://people.apache.org/repo/m2
[jira] Commented: (GERONIMO-2694) STATUS file sent out as the Geronimo Weekly Status email needs updating
[ https://issues.apache.org/jira/browse/GERONIMO-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486371 ] Donald Woods commented on GERONIMO-2694: Committed revision 525156 in trunk with updated 1.2 status from Jason. STATUS file sent out as the Geronimo Weekly Status email needs updating --- Key: GERONIMO-2694 URL: https://issues.apache.org/jira/browse/GERONIMO-2694 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: documentation Affects Versions: 1.2, 2.0-M2 Reporter: Donald Woods Assigned To: Donald Woods Priority: Trivial Fix For: 2.0-M5 Attachments: G2694-server-trunk.patch The geronimo/server/trunk/STATUS file needs to be updated to mention trunk is now 2.0, where the 1.2 branch is located and the fact that 1.2-Beta and 2.0-M1 were released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Fwd: Is the GERONIMODEVTOOLS JIRA still under RTC?]
Yep, I was able to close 139 as a dup and I can now enter edit mode on the cwiki committers page. Thanks. -Donald Jason Dillon wrote: So are you sorted? --jason On Apr 2, 2007, at 7:08 PM, Donald Woods wrote: Thanks for the mojo :-) -Donald Jason Dillon wrote: Probably not in the right group... You were still just in geronimo-contributor, but I've moved you to geronimo-developers. You should be good now. I'll do the same for confluence. --jason On Apr 2, 2007, at 6:38 PM, Sachin Patel wrote: I see close as an action. Perhaps your permissions are not correct. But no, DEVTOOLS is not under RTC and the workflow should have been removed from this project as well. -sachin On Apr 2, 2007, at 9:23 PM, Donald Woods wrote: Resending as this never showed up on the list Original Message Subject: Is the GERONIMODEVTOOLS JIRA still under RTC? Date: Mon, 02 Apr 2007 20:11:13 -0400 From: Donald Woods [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: gdev dev@geronimo.apache.org I'm trying to close GERONIMODEVTOOLS-139, which is a duplicate of 132 that I just fixed and closed, but 139 only gives me workflow actions of- Begin RTC Review Start Progress For 132, I had the Resolve option and could close it as fixed. What's up? -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: [jira] Created: (GERONIMO-3054) org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement
I took a look at the svn log and the orginal version of the file that was checked in from Bouncy Castle by David Jencks in Rev291352 on Sept. 24, 2005 was marked as deprecated, so it doesn't look like anything we changed and its been that way since the 1.0 release BTW - Why do you care, given most if not all of this JCE and crypto code in util is no longer needed, since we have moved to Java 5? -Donald Ken wrote: Hi, folks. Any thoughts on this one? Does anyone know *who* deprecated the file, because perhaps I could direct my question to him/her? Thanks a lot! -Ken At 04:57 PM 3/31/2007, you wrote: org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement Key: GERONIMO-3054 URL: https://issues.apache.org/jira/browse/GERONIMO-3054 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.1.1 Environment: All Reporter: Ken Priority: Minor Hello, all. I am looking at the source code for several files, and one of them, org.apache.geronimo.util.jce.X509V1CertificateGenerator has the following tag notice: /** * class to produce an X.509 Version 1 certificate. * * @deprecated use the equivalent class in org.apache.geronimo.util.x509 */ I (think I) have looked everywhere for a package named x509 under util, or even a reference to when/how/why/to what it was changed, but can't seem to find one. Where is this replacement class that is mentioned in the deprecation? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. smime.p7s Description: S/MIME Cryptographic Signature
Re: Fisheye for Apache Geronimo?
Jason Dillon wrote: Hey, I noticed that fisheye6 is service pages now, but the geronimo_server repository is marked as stopped. Is this repo still syncing? Actually I stopped it. I attempted to set up the repo to import its state from the point where it was moved to the server dir. Unfortunately some operations to Apache timed out. I decided to rework a few things to make this more robust. I should be able to retry next weekend. Conor
Re: Restructuring trunk (LONG)
I like your proposal, but this feels like a major change to make in the last month of a release, when we are just now seeing and fixing Console bugs and the Samples still need work for 2.0. Waiting until after M5 (or after CTS setup is finished) to start changing any of the groupIds could cause us another several weeks of churn to find and fix all of the unpredictable ripple affects through the server, daytrader and any Plug-ins we create or help others to produce (like Liferay or Roller) Seems like if we want to do any of this for 2.0, we need to make the changes this week and then cut a M5 or Beta, to give everyone time to verify that their apps and favorite Console portlets still work -Donald Jason Dillon wrote: Awhile back I sent some email [1] about restructuring server/trunk into smaller groups of modules organized by function/feature. I had been waiting for svk2 to be usable enough to manage restructuring in a branch while pulling in new changes to src files, and the latest updates to the svk2 trunk has working support to --track-renames when merging. Last night I spent a few hours and whipped up a POC, using svk to move modules around into groups. I've been tracking changes made to trunk since then and merging them into my local svk repository and it appears that the --track-rename feature is working... yay! I just wanted to provide a little details on this, how it is working out so far and start up some discussion about eventually making these changes to server/trunk. Right off the bat, I want to mention that these changes should probably be implemented *after* we are done with the bulk of 2.0 work. I don't want to limit this to 2.1, since with the --track-rename feature it may be very feasible to implement this change before we are done with 2.0, but should definitely not be done until we are sorted on the features and TCK muck. When we do decide to implement something like this, I think we should also re-groupId things under org.apache.geronimo.server, and use that namespace for a fresh start... meaning we should not re-groupId to o.a.g.server until then. * * * Below are _examples_ of how modules _might_ be organized, nothing in stone, probably not completely accurate. I did leave the actual names of modules as they were, we can deal with the naming of them later. So far what I have done was to create 2 new top-level modules: * framework * components These are just pom modules which serve to group other modules. The 'framework' module contains the core (code and configuration) modules that make up the backbone of the server. Each of these modules only has dependencies on other modules in this group, or on modules in testsupport or buildsupport, both of which are built prior to building framework (except for a wee bit of magic to get the car-maven-plugin working, see details on that below). For example: framework framework/geronimo-activation framework/geronimo-client framework/geronimo-client-builder framework/geronimo-clustering framework/geronimo-common framework/geronimo-connector framework/geronimo-connector-builder framework/geronimo-core framework/geronimo-deploy-config framework/geronimo-deploy-jsr88 framework/geronimo-deploy-jsr88-bootstrapper framework/geronimo-deploy-tool framework/geronimo-deployment framework/geronimo-gbean-deployer framework/geronimo-interceptor framework/geronimo-j2ee framework/geronimo-j2ee-builder framework/geronimo-j2ee-schema framework/geronimo-jmx-remoting framework/geronimo-kernel framework/geronimo-management framework/geronimo-naming framework/geronimo-naming-builder framework/geronimo-security framework/geronimo-security-builder framework/geronimo-service-builder framework/geronimo-system framework/geronimo-test-ddbean framework/geronimo-timer framework/geronimo-transaction framework/geronimo-transaction-jta11 framework/geronimo-transformer framework/geronimo-util framework/geronimo-web-2.5-builder NOTE: this ^^^ is not a complete list, there are still a bunch of bits in configs/* which I'm trying to figure out where they should live. See the bits below about framework and javaee stuff. The 'components' module contains modules for each of the major non-framework feature components, which in turn contain the (code and configuration) modules that implement/configure that feature. For example: components components/activemq components/axis components/axis2 components/converter components/corba components/cxf components/derby components/directory components/hotdeploy components/jasper components/javamail components/jaxws components/jetty6 components/jetty6-wadi components/jpa components/myfaces components/openejb components/tomcat6 components/upgrade
Re: [jira] Created: (GERONIMO-3054) org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement
Thanks -- I see the updated classes in Bouncy Castle. The issue is around importing PKCS7 certs, and the cert chain not being imported properly. It's actually associated with the KeyStoreGBean.java file, but I want to make sure I have clean code before I call it a bug. -Ken At 08:03 AM 4/3/2007, you wrote: I took a look at the svn log and the orginal version of the file that was checked in from Bouncy Castle by David Jencks in Rev291352 on Sept. 24, 2005 was marked as deprecated, so it doesn't look like anything we changed and its been that way since the 1.0 release BTW - Why do you care, given most if not all of this JCE and crypto code in util is no longer needed, since we have moved to Java 5? -Donald Ken wrote: Hi, folks. Any thoughts on this one? Does anyone know *who* deprecated the file, because perhaps I could direct my question to him/her? Thanks a lot! -Ken At 04:57 PM 3/31/2007, you wrote: org.apache.geronimo.util.jce.X509V1CertificateGenerator appears to be deprecated with no replacement Key: GERONIMO-3054 URL: https://issues.apache.org/jira/browse/GERONIMO-3054 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.1.1 Environment: All Reporter: Ken Priority: Minor Hello, all. I am looking at the source code for several files, and one of them, org.apache.geronimo.util.jce.X509V1CertificateGenerator has the following tag notice: /** * class to produce an X.509 Version 1 certificate. * * @deprecated use the equivalent class in org.apache.geronimo.util.x509 */ I (think I) have looked everywhere for a package named x509 under util, or even a reference to when/how/why/to what it was changed, but can't seem to find one. Where is this replacement class that is mentioned in the deprecation? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Fwd: Is the GERONIMODEVTOOLS JIRA still under RTC?]
Donald, just to clarify, JIRA and cwiki although in the same physical box, are totally independent, they don't share any user base. You need to be in the geronimo-committers (which you already are) groups to edit the restricted Geronimo spaces. Cheers! Hernan Donald Woods wrote: Yep, I was able to close 139 as a dup and I can now enter edit mode on the cwiki committers page. Thanks. -Donald Jason Dillon wrote: So are you sorted? --jason On Apr 2, 2007, at 7:08 PM, Donald Woods wrote: Thanks for the mojo :-) -Donald Jason Dillon wrote: Probably not in the right group... You were still just in geronimo-contributor, but I've moved you to geronimo-developers. You should be good now. I'll do the same for confluence. --jason On Apr 2, 2007, at 6:38 PM, Sachin Patel wrote: I see close as an action. Perhaps your permissions are not correct. But no, DEVTOOLS is not under RTC and the workflow should have been removed from this project as well. -sachin On Apr 2, 2007, at 9:23 PM, Donald Woods wrote: Resending as this never showed up on the list Original Message Subject: Is the GERONIMODEVTOOLS JIRA still under RTC? Date: Mon, 02 Apr 2007 20:11:13 -0400 From: Donald Woods [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: gdev dev@geronimo.apache.org I'm trying to close GERONIMODEVTOOLS-139, which is a duplicate of 132 that I just fixed and closed, but 139 only gives me workflow actions of- Begin RTC Review Start Progress For 132, I had the Resolve option and could close it as fixed. What's up? -Donald
Re: [VOTE] 2.0-M4 Binaries available (rc1)
-1 (non-veto) since it does not build. Regards, Alan On Apr 1, 2007, at 2:54 AM, Matt Hogstrom wrote: I have placed the 2.0-M4 binaries out on http://people.apache.org/ ~hogstrom/2.0-M4-rc1 for you to take a look at. (They are uploading as I write this). I have done some testing with DayTrader. There is an issue in connecting with he MDB container which still needs to be worked out so the application will not deploy as is. However, given the scopwe of function DayTrader covers as well as all the late code drops I don't see an issue with that. Smaller samples should be ok and tests look good. Given that we're in the final stages of testing I'd like to get this Milestone on the wire as is and fix issues in trunk. Users that pull this binary and report issues will help us in the Drive to 5. Other than that limitation I think this Milestone looks ready to go. After reviewing the content please cast your vote. [ ] +1 - Release these binaries [ ] 0 [ ] -1 Do not release these binaries (provide reason) This vote will conclude on April 4th at 0600 Eastern. Thanks!
Re: SOAP binding/serialization
Sorry to answer with such a delay. The wsdl11 wrapper is not supported yet, this is one of the purpose of the new soap2 module. The consumer part is in a usable state and I have something ready to commit on the provider side, but I'm waiting for some recent jetty snapshots to be published (I guess I will upload some to our private repo soon). So I'm not really at ease with changing the current endpoints to add a non complete support for the wsdl 1.1 wrapper ... If you want to test it, I can commit the work I did on the provider endpoint ... On 3/29/07, Janne Savukoski [EMAIL PROTECTED] wrote: Hi, I had some issues with soap messages not being serialized properly, header/body handling (binding) etc. I'm using the wsdl11-wrapping and I don't know if it has something to do with this. Anyways, at least it looks like the binding stuff is being discarded at org.apache.servicemix.http.HttpEndpoint:228, but I don't know if the part handling (soap binding) was occurring before that; although, the end-results weren't suggesting so. (All parts were serialized to the soap body, or something.) So I hacked up this little patch which does the part handling. Diffs attached. Best effort -kind of stuff, works for me. Just if anyone else is interested.. Though, I didn't quite get what HttpEndpoint#overrideDefinition was trying to do so that hack may be a little conflicting.. (see the httpendpoint-patch.) I'd also like to know if this would somehow work without the patch as patches are a bit annoying. :) (There also appears to be some major stuff coming in the soap2-module, but it seemed a little incomplete so I didn't take a closer look.) Btw., I guess the soap-headers of the reply message are being forwarded correctly? -janne -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Re: [VOTE] 2.0-M4 Binaries available (rc1)
Did you want the repo so you can build ? 1335571863 Apr 1 06:00 geronimo-2.0-M4-repository.tar.gz I can make it available on people if you like. It has the correct SNAPSHOT versions for dependencies. On Apr 3, 2007, at 11:31 AM, Alan D. Cabrera wrote: -1 (non-veto) since it does not build. Regards, Alan On Apr 1, 2007, at 2:54 AM, Matt Hogstrom wrote: I have placed the 2.0-M4 binaries out on http://people.apache.org/ ~hogstrom/2.0-M4-rc1 for you to take a look at. (They are uploading as I write this). I have done some testing with DayTrader. There is an issue in connecting with he MDB container which still needs to be worked out so the application will not deploy as is. However, given the scopwe of function DayTrader covers as well as all the late code drops I don't see an issue with that. Smaller samples should be ok and tests look good. Given that we're in the final stages of testing I'd like to get this Milestone on the wire as is and fix issues in trunk. Users that pull this binary and report issues will help us in the Drive to 5. Other than that limitation I think this Milestone looks ready to go. After reviewing the content please cast your vote. [ ] +1 - Release these binaries [ ] 0 [ ] -1 Do not release these binaries (provide reason) This vote will conclude on April 4th at 0600 Eastern. Thanks!
Re: [VOTE] 2.0-M4 Binaries available (rc1)
What do we do for anyone else who wants to build? Maybe we should release the binaries only? Regards, Alan On Apr 3, 2007, at 9:03 AM, Matt Hogstrom wrote: Did you want the repo so you can build ? 1335571863 Apr 1 06:00 geronimo-2.0-M4-repository.tar.gz I can make it available on people if you like. It has the correct SNAPSHOT versions for dependencies. On Apr 3, 2007, at 11:31 AM, Alan D. Cabrera wrote: -1 (non-veto) since it does not build. Regards, Alan On Apr 1, 2007, at 2:54 AM, Matt Hogstrom wrote: I have placed the 2.0-M4 binaries out on http://people.apache.org/ ~hogstrom/2.0-M4-rc1 for you to take a look at. (They are uploading as I write this). I have done some testing with DayTrader. There is an issue in connecting with he MDB container which still needs to be worked out so the application will not deploy as is. However, given the scopwe of function DayTrader covers as well as all the late code drops I don't see an issue with that. Smaller samples should be ok and tests look good. Given that we're in the final stages of testing I'd like to get this Milestone on the wire as is and fix issues in trunk. Users that pull this binary and report issues will help us in the Drive to 5. Other than that limitation I think this Milestone looks ready to go. After reviewing the content please cast your vote. [ ] +1 - Release these binaries [ ] 0 [ ] -1 Do not release these binaries (provide reason) This vote will conclude on April 4th at 0600 Eastern. Thanks!
[jira] Assigned: (DAYTRADER-5) Add LICENSE.txt and NOTICE.txt files
[ https://issues.apache.org/jira/browse/DAYTRADER-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned DAYTRADER-5: Assignee: Donald Woods Add LICENSE.txt and NOTICE.txt files Key: DAYTRADER-5 URL: https://issues.apache.org/jira/browse/DAYTRADER-5 Project: DayTrader Issue Type: Task Components: buildsystem Affects Versions: 1.1 Reporter: John Sisson Assigned To: Donald Woods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-5) Add LICENSE.txt and NOTICE.txt files
[ https://issues.apache.org/jira/browse/DAYTRADER-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed DAYTRADER-5. Resolution: Fixed Fix Version/s: 2.0 Completed: At revision: 525208 in trunk Add LICENSE.txt and NOTICE.txt files Key: DAYTRADER-5 URL: https://issues.apache.org/jira/browse/DAYTRADER-5 Project: DayTrader Issue Type: Task Components: buildsystem Affects Versions: 1.1 Reporter: John Sisson Assigned To: Donald Woods Fix For: 2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-41) Upgrade to Genesis 1.2-SNAPSHOT and use maven-enforcer-plugin and our tools-maven-plugin
Upgrade to Genesis 1.2-SNAPSHOT and use maven-enforcer-plugin and our tools-maven-plugin Key: DAYTRADER-41 URL: https://issues.apache.org/jira/browse/DAYTRADER-41 Project: DayTrader Issue Type: Improvement Components: buildsystem Affects Versions: 2.0 Reporter: Donald Woods Assigned To: Donald Woods Priority: Minor Fix For: 2.0 Upgrade Daytrader to use the Genesis 1.2-SNAPSHOT artifacts to match the upgrade just made to server trunk. Use tools-maven-plugin from Genesis to copy the License and Notice files into the built artifacts, but don't fail the build on verifying they got copied for now. Use the new maven-enforcer-plugin to validate the Java and Maven versions, like we are doing in the server build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
I'm -1 on releasing as is because of (2). I think our binaries should be cleaner that that :-/ I don't think (1) is significant. There is no functional change from applying the patch from GERONIMO-2941. (3) also doesn't bother me. thanks david jencks On Apr 3, 2007, at 2:57 AM, Rakesh Midha wrote: I think we need to look into following issues: 1. Initial startup error caused by https://issues.apache.org/jira/ browse/GERONIMO-2941 2. Why is that in console's Application section and deployment list- module, I see all the modules twice? One with the version 2.0-M4, appears as started and one with version 2.0-M4-SNAPSHOT stopped. All the modules also have two folders for two versions. Its not causing any error or exception, but i am just worried as this result in larger size of zip/gz and installed folder, and may also have other effects. 3. Shutdown error. thanks Rakesh On 4/3/07, Jacek Laskowski [EMAIL PROTECTED] wrote: +1 Jacek On 4/1/07, Matt Hogstrom [EMAIL PROTECTED] wrote: I have placed the 2.0-M4 binaries out on http://people.apache.org/ ~hogstrom/2.0-M4-rc1 for you to take a look at. (They are uploading as I write this). I have done some testing with DayTrader. There is an issue in connecting with he MDB container which still needs to be worked out so the application will not deploy as is. However, given the scopwe of function DayTrader covers as well as all the late code drops I don't see an issue with that. Smaller samples should be ok and tests look good. Given that we're in the final stages of testing I'd like to get this Milestone on the wire as is and fix issues in trunk. Users that pull this binary and report issues will help us in the Drive to 5. Other than that limitation I think this Milestone looks ready to go. After reviewing the content please cast your vote. [ ] +1 - Release these binaries [ ] 0 [ ] -1 Do not release these binaries (provide reason) This vote will conclude on April 4th at 0600 Eastern. Thanks! -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[
https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486446
]
Lin Sun commented on GERONIMO-3045:
---
Jarek, I tried to make change at the JAX-WS level as I don't think we should
call parseWebServiceDescriptor at all if it is JAX-RPC based webservices.xml.
However, I didn't handle the case when web.xml isn't there as the servletTypes
will be null.
The new patch is to revert the changes at JAX-WS level and ignore the xmlbeans
xmlexception in Axis2Builder.
I tried to check if namespaceURI equals http://java.sun.com/xml/ns/javaee;
first but it is hard for me to get xbeans to do what I want.
Here's what I had:
XmlObject xobj = XmlObject.Factory.parse(in);
SchemaType st = xobj.schemaType();
cursor = xobj.newCursor();
cursor.toStartDoc();
cursor.toFirstChild();
if
(http://java.sun.com/xml/ns/javaee.equals(cursor.getName().getNamespaceURI()))
{
//the checking is needed as we also send JAX-RPC based
webservices.xml here
//if (xobj instanceof WebservicesDocument) {
WebservicesType wst =
WebservicesDocument.Factory.parse(in).getWebservices();
it turned out the xobj isn't instanceof WebservicesDocument, so I cannot cast
it to WebservicesDocument.
The above if statement works fine, but the inputstream isn't at the right
position so calling the following after if
WebservicesType wst =
WebservicesDocument.Factory.parse(in).getWebservices();
will fail. I tried to use inputstream.mark and .reset but these two methods
aren't supported.
Thus I decided just to ignore the xmlexception unless someone has a better
solution.
Thanks, Lin
Unable to run jax-rpc war test with Axis2
-
Key: GERONIMO-3045
URL: https://issues.apache.org/jira/browse/GERONIMO-3045
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.0-M5
Environment: 1.5 SUN SDK + WIN XP
Reporter: Lin Sun
Assigned To: Lin Sun
Fix For: 2.0-M5
Attachments: G3045.patch
When running the jax-rpc war test with axis2, both test failed due to an
exception thrown when parseWebServiceDescriptor is called.
from reading the code, if webservices.xml doesn't exist, we call
discoverwebservices, which will check if the class has annotation. if
webservices.xml exists, we 'll just call parseWebServiceDescriptor, which
caused the error for axis2 because axis2 moved to xbeans.
The fix is to check if annotation exists when webservices.xml exists also.
Tested the fix and able to pass the 2 jax-rpc war test test with them. Will
attach the patch after a full build.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-3045: -- Attachment: G3045-new.patch Tested the patch with jaxrpc-war and jaxws-war testsuites. Unable to run jax-rpc war test with Axis2 - Key: GERONIMO-3045 URL: https://issues.apache.org/jira/browse/GERONIMO-3045 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: 1.5 SUN SDK + WIN XP Reporter: Lin Sun Assigned To: Lin Sun Fix For: 2.0-M5 Attachments: G3045-new.patch, G3045.patch When running the jax-rpc war test with axis2, both test failed due to an exception thrown when parseWebServiceDescriptor is called. from reading the code, if webservices.xml doesn't exist, we call discoverwebservices, which will check if the class has annotation. if webservices.xml exists, we 'll just call parseWebServiceDescriptor, which caused the error for axis2 because axis2 moved to xbeans. The fix is to check if annotation exists when webservices.xml exists also. Tested the fix and able to pass the 2 jax-rpc war test test with them. Will attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reassigned GERONIMO-3045: - Assignee: (was: Lin Sun) Unassign it so a committer can grab it. Unable to run jax-rpc war test with Axis2 - Key: GERONIMO-3045 URL: https://issues.apache.org/jira/browse/GERONIMO-3045 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: 1.5 SUN SDK + WIN XP Reporter: Lin Sun Fix For: 2.0-M5 Attachments: G3045-new.patch, G3045.patch When running the jax-rpc war test with axis2, both test failed due to an exception thrown when parseWebServiceDescriptor is called. from reading the code, if webservices.xml doesn't exist, we call discoverwebservices, which will check if the class has annotation. if webservices.xml exists, we 'll just call parseWebServiceDescriptor, which caused the error for axis2 because axis2 moved to xbeans. The fix is to check if annotation exists when webservices.xml exists also. Tested the fix and able to pass the 2 jax-rpc war test test with them. Will attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-41) Upgrade to Genesis 1.2-SNAPSHOT and use maven-enforcer-plugin and our tools-maven-plugin
[ https://issues.apache.org/jira/browse/DAYTRADER-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed DAYTRADER-41. - Resolution: Fixed Completed: At revision: 525209 in trunk. Upgrade to Genesis 1.2-SNAPSHOT and use maven-enforcer-plugin and our tools-maven-plugin Key: DAYTRADER-41 URL: https://issues.apache.org/jira/browse/DAYTRADER-41 Project: DayTrader Issue Type: Improvement Components: buildsystem Affects Versions: 2.0 Reporter: Donald Woods Assigned To: Donald Woods Priority: Minor Fix For: 2.0 Upgrade Daytrader to use the Genesis 1.2-SNAPSHOT artifacts to match the upgrade just made to server trunk. Use tools-maven-plugin from Genesis to copy the License and Notice files into the built artifacts, but don't fail the build on verifying they got copied for now. Use the new maven-enforcer-plugin to validate the Java and Maven versions, like we are doing in the server build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-917) Missing M2_REPO JavaMail classpath variable in servicemix-itests for building in Eclipse
Missing M2_REPO JavaMail classpath variable in servicemix-itests for building in Eclipse Key: SM-917 URL: https://issues.apache.org/activemq/browse/SM-917 Project: ServiceMix Issue Type: Bug Affects Versions: 3.2 Environment: Windows XP, Eclipse 3.2.2, Maven 2.0.5 Reporter: Colin Surprenant Priority: Minor Using trunk source from Apr 3, 2007 Eclipse build breaks in servicemix-itests because of missing classpath variable for M2_REPO/javax/mail/mail/1.4/mail-1.4.jar. Build error is : The type javax.mail.internet.MimeMessage cannot be resolved. It is indirectly referenced from required .class files servicemix-itests/src/test/java/org/apache/servicemix/itests Jsr181HttpTest.java line 103 To solve add this line in the .classpath of servicemix-itests: classpathentry kind=var path=M2_REPO/javax/mail/mail/1.4/mail-1.4.jar/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
Can't argue with #2. I can't see how these got picked up and it is sloppy. I'm ok with knocking this set of binaries down. Although, I'm not sure I want to invest more time on this milestone as there are lots of functional pieces to fix. Anyone else want to put together an M4 or shall we pass this month? On Apr 3, 2007, at 1:51 PM, David Jencks wrote: I'm -1 on releasing as is because of (2). I think our binaries should be cleaner that that :-/ I don't think (1) is significant. There is no functional change from applying the patch from GERONIMO-2941. (3) also doesn't bother me. thanks david jencks On Apr 3, 2007, at 2:57 AM, Rakesh Midha wrote: I think we need to look into following issues: 1. Initial startup error caused by https://issues.apache.org/jira/ browse/GERONIMO-2941 2. Why is that in console's Application section and deployment list-module, I see all the modules twice? One with the version 2.0-M4, appears as started and one with version 2.0-M4-SNAPSHOT stopped. All the modules also have two folders for two versions. Its not causing any error or exception, but i am just worried as this result in larger size of zip/gz and installed folder, and may also have other effects. 3. Shutdown error. thanks Rakesh On 4/3/07, Jacek Laskowski [EMAIL PROTECTED] wrote: +1 Jacek On 4/1/07, Matt Hogstrom [EMAIL PROTECTED] wrote: I have placed the 2.0-M4 binaries out on http://people.apache.org/ ~hogstrom/2.0-M4-rc1 for you to take a look at. (They are uploading as I write this). I have done some testing with DayTrader. There is an issue in connecting with he MDB container which still needs to be worked out so the application will not deploy as is. However, given the scopwe of function DayTrader covers as well as all the late code drops I don't see an issue with that. Smaller samples should be ok and tests look good. Given that we're in the final stages of testing I'd like to get this Milestone on the wire as is and fix issues in trunk. Users that pull this binary and report issues will help us in the Drive to 5. Other than that limitation I think this Milestone looks ready to go. After reviewing the content please cast your vote. [ ] +1 - Release these binaries [ ] 0 [ ] -1 Do not release these binaries (provide reason) This vote will conclude on April 4th at 0600 Eastern. Thanks! -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: org.apache.geronimo.system.main.Daemon and commons-cli
I will take a peek at GERONIMO-3059 and provide some feedback. Thanks :-) --jason On Apr 3, 2007, at 6:45 AM, Gianny Damour wrote: Hi, As discussed with Jason, I worked on a fix to this problem: GERONIMO-3059. I will be on holiday, with sporadic internet access, for a couple of weeks starting tomorrow night; So, I will not check in these changes now as I will not be able to support related problems, if any. Having said that, Jason, if you are happy to check them in and fix related issues, if any, then I am fine with it :) Thanks, Gianny On 21/03/2007, at 11:05 AM, Sachin Patel wrote: I agree, this is a usability regression. -sachin On Mar 20, 2007, at 5:08 PM, Jason Dillon wrote: You have to wait several seconds for the bootstrap kernel to load... just to display the cli usage... that seems wrong IMO.
Re: Restructuring trunk (LONG)
On Apr 3, 2007, at 7:11 AM, Donald Woods wrote: I like your proposal, but this feels like a major change to make in the last month of a release, when we are just now seeing and fixing Console bugs and the Samples still need work for 2.0. Waiting until after M5 (or after CTS setup is finished) to start changing any of the groupIds could cause us another several weeks of churn to find and fix all of the unpredictable ripple affects through the server, daytrader and any Plug-ins we create or help others to produce (like Liferay or Roller) Seems like if we want to do any of this for 2.0, we need to make the changes this week and then cut a M5 or Beta, to give everyone time to verify that their apps and favorite Console portlets still work I don't think any of these changes will be made to trunk for quite a few weeks, I did mention this... snip Right off the bat, I want to mention that these changes should probably be implemented *after* we are done with the bulk of 2.0 work. I don't want to limit this to 2.1, since with the --track- rename feature it may be very feasible to implement this change before we are done with 2.0, but should definitely not be done until we are sorted on the features and TCK muck. /snip I do believe this should be done, but I don't want it to distract from the current 2.0+TCK work, so merging these changes into trunk will have to wait until most of that stuff is sorted. --jason -Donald Jason Dillon wrote: Awhile back I sent some email [1] about restructuring server/trunk into smaller groups of modules organized by function/feature. I had been waiting for svk2 to be usable enough to manage restructuring in a branch while pulling in new changes to src files, and the latest updates to the svk2 trunk has working support to --track-renames when merging. Last night I spent a few hours and whipped up a POC, using svk to move modules around into groups. I've been tracking changes made to trunk since then and merging them into my local svk repository and it appears that the --track-rename feature is working... yay! I just wanted to provide a little details on this, how it is working out so far and start up some discussion about eventually making these changes to server/trunk. Right off the bat, I want to mention that these changes should probably be implemented *after* we are done with the bulk of 2.0 work. I don't want to limit this to 2.1, since with the --track-rename feature it may be very feasible to implement this change before we are done with 2.0, but should definitely not be done until we are sorted on the features and TCK muck. When we do decide to implement something like this, I think we should also re-groupId things under org.apache.geronimo.server, and use that namespace for a fresh start... meaning we should not re-groupId to o.a.g.server until then. * * * Below are _examples_ of how modules _might_ be organized, nothing in stone, probably not completely accurate. I did leave the actual names of modules as they were, we can deal with the naming of them later. So far what I have done was to create 2 new top-level modules: * framework * components These are just pom modules which serve to group other modules. The 'framework' module contains the core (code and configuration) modules that make up the backbone of the server. Each of these modules only has dependencies on other modules in this group, or on modules in testsupport or buildsupport, both of which are built prior to building framework (except for a wee bit of magic to get the car-maven-plugin working, see details on that below). For example: framework framework/geronimo-activation framework/geronimo-client framework/geronimo-client-builder framework/geronimo-clustering framework/geronimo-common framework/geronimo-connector framework/geronimo-connector-builder framework/geronimo-core framework/geronimo-deploy-config framework/geronimo-deploy-jsr88 framework/geronimo-deploy-jsr88-bootstrapper framework/geronimo-deploy-tool framework/geronimo-deployment framework/geronimo-gbean-deployer framework/geronimo-interceptor framework/geronimo-j2ee framework/geronimo-j2ee-builder framework/geronimo-j2ee-schema framework/geronimo-jmx-remoting framework/geronimo-kernel framework/geronimo-management framework/geronimo-naming framework/geronimo-naming-builder framework/geronimo-security framework/geronimo-security-builder framework/geronimo-service-builder framework/geronimo-system framework/geronimo-test-ddbean framework/geronimo-timer framework/geronimo-transaction framework/geronimo-transaction-jta11 framework/geronimo-transformer framework/geronimo-util framework/geronimo-web-2.5-builder NOTE: this ^^^ is not a complete list, there are still a bunch of bits in
Re: Fisheye for Apache Geronimo?
Okay, thanks for the update. --jason On Apr 3, 2007, at 5:43 AM, Conor MacNeill wrote: Jason Dillon wrote: Hey, I noticed that fisheye6 is service pages now, but the geronimo_server repository is marked as stopped. Is this repo still syncing? Actually I stopped it. I attempted to set up the repo to import its state from the point where it was moved to the server dir. Unfortunately some operations to Apache timed out. I decided to rework a few things to make this more robust. I should be able to retry next weekend. Conor
[jira] Commented: (GERONIMO-2988) Axis2: needs to support optional wsdl file
[ https://issues.apache.org/jira/browse/GERONIMO-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486483 ] Lin Sun commented on GERONIMO-2988: --- Investigated the aptmirrorapi project (https://aptmirrorapi.dev.java.net/) and seems it contains the API we need, however it was not too clear to me whether it is under BSD or Sun license. Sent a note to the owners of the project and copied dims. Axis2: needs to support optional wsdl file -- Key: GERONIMO-2988 URL: https://issues.apache.org/jira/browse/GERONIMO-2988 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Reporter: Lin Sun Fix For: 2.0-M5 Attachments: G2988.patch When wsdl file is not created, the axis2 currently uses WSDL2Java tool to generate the schema but the tool doesn't process annotation yet! The alternative is to use the wsgen tool provided by sun before Axis2 provides a tool to generate the schema from annotation. There is code that writes out a web.xml to disk when web.xml is not there and we may be able to use some of the code there. The idea is to write a generated wsdl file on disk based on java classes and remove the wsdl file when the app is undeployed. 3 deployment scenarios need to be supported - 1) regular deployment 2) in place deployment 3) hot deployment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
I'll upload the 11 Axis2 and 11 CXF artifacts into the M4 branches local repo and update the pom.xml if someone will either respin/republish the build for me or walk me through how to do it:-) -Donald Matt Hogstrom wrote: Can't argue with #2. I can't see how these got picked up and it is sloppy. I'm ok with knocking this set of binaries down. Although, I'm not sure I want to invest more time on this milestone as there are lots of functional pieces to fix. Anyone else want to put together an M4 or shall we pass this month? On Apr 3, 2007, at 1:51 PM, David Jencks wrote: I'm -1 on releasing as is because of (2). I think our binaries should be cleaner that that :-/ I don't think (1) is significant. There is no functional change from applying the patch from GERONIMO-2941. (3) also doesn't bother me. thanks david jencks On Apr 3, 2007, at 2:57 AM, Rakesh Midha wrote: I think we need to look into following issues: 1. Initial startup error caused by https://issues.apache.org/jira/browse/GERONIMO-2941 2. Why is that in console's Application section and deployment list-module, I see all the modules twice? One with the version 2.0-M4, appears as started and one with version 2.0-M4-SNAPSHOT stopped. All the modules also have two folders for two versions. Its not causing any error or exception, but i am just worried as this result in larger size of zip/gz and installed folder, and may also have other effects. 3. Shutdown error. thanks Rakesh On 4/3/07, *Jacek Laskowski* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: +1 Jacek On 4/1/07, Matt Hogstrom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have placed the 2.0-M4 binaries out on http://people.apache.org/ ~hogstrom/2.0-M4-rc1 for you to take a look at. (They are uploading as I write this). I have done some testing with DayTrader. There is an issue in connecting with he MDB container which still needs to be worked out so the application will not deploy as is. However, given the scopwe of function DayTrader covers as well as all the late code drops I don't see an issue with that. Smaller samples should be ok and tests look good. Given that we're in the final stages of testing I'd like to get this Milestone on the wire as is and fix issues in trunk. Users that pull this binary and report issues will help us in the Drive to 5. Other than that limitation I think this Milestone looks ready to go. After reviewing the content please cast your vote. [ ] +1 - Release these binaries [ ] 0 [ ] -1 Do not release these binaries (provide reason) This vote will conclude on April 4th at 0600 Eastern. Thanks! -- Jacek Laskowski http://www.JacekLaskowski.pl smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
We really should not be using the local repo like this... :-( --jason On Apr 3, 2007, at 1:57 PM, Donald Woods wrote: I'll upload the 11 Axis2 and 11 CXF artifacts into the M4 branches local repo and update the pom.xml if someone will either respin/ republish the build for me or walk me through how to do it:-) -Donald Matt Hogstrom wrote: Can't argue with #2. I can't see how these got picked up and it is sloppy. I'm ok with knocking this set of binaries down. Although, I'm not sure I want to invest more time on this milestone as there are lots of functional pieces to fix. Anyone else want to put together an M4 or shall we pass this month? On Apr 3, 2007, at 1:51 PM, David Jencks wrote: I'm -1 on releasing as is because of (2). I think our binaries should be cleaner that that :-/ I don't think (1) is significant. There is no functional change from applying the patch from GERONIMO-2941. (3) also doesn't bother me. thanks david jencks On Apr 3, 2007, at 2:57 AM, Rakesh Midha wrote: I think we need to look into following issues: 1. Initial startup error caused by https://issues.apache.org/ jira/browse/GERONIMO-2941 2. Why is that in console's Application section and deployment list-module, I see all the modules twice? One with the version 2.0-M4, appears as started and one with version 2.0-M4-SNAPSHOT stopped. All the modules also have two folders for two versions. Its not causing any error or exception, but i am just worried as this result in larger size of zip/gz and installed folder, and may also have other effects. 3. Shutdown error. thanks Rakesh On 4/3/07, *Jacek Laskowski* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: +1 Jacek On 4/1/07, Matt Hogstrom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have placed the 2.0-M4 binaries out on http:// people.apache.org/ ~hogstrom/2.0-M4-rc1 for you to take a look at. (They are uploading as I write this). I have done some testing with DayTrader. There is an issue in connecting with he MDB container which still needs to be worked out so the application will not deploy as is. However, given the scopwe of function DayTrader covers as well as all the late code drops I don't see an issue with that. Smaller samples should be ok and tests look good. Given that we're in the final stages of testing I'd like to get this Milestone on the wire as is and fix issues in trunk. Users that pull this binary and report issues will help us in the Drive to 5. Other than that limitation I think this Milestone looks ready to go. After reviewing the content please cast your vote. [ ] +1 - Release these binaries [ ] 0 [ ] -1 Do not release these binaries (provide reason) This vote will conclude on April 4th at 0600 Eastern. Thanks! -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
On Apr 3, 2007, at 4:57 PM, Donald Woods wrote: I'll upload the 11 Axis2 and 11 CXF artifacts into the M4 branches local repo and update the pom.xml if someone will either respin/ republish the build for me or walk me through how to do it:-) Donald, excellent and I appreciate it. I would checkout the 2.0-M4 in branches to start with. There must be some lingering issue in hte build or we somehow picked up the SNAPSHOT though some transitive dependencies. If you like I can provide you with the repo I used for this build. It may be possible to address Alan's concern about being able to rebuild as well. Although, personally I think the time invested in 2.0 is better spent than waving a dead chicken on 2.0-M4. By the time it get built and voted on we'll be into next week most likely with the next milestone a few weeks away. I think a better solution would be to simply create an unstable set and put them up on people.apache.org. Other's thoughts? -Donald
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
On Apr 3, 2007, at 2:18 PM, Matt Hogstrom wrote: On Apr 3, 2007, at 4:57 PM, Donald Woods wrote: I'll upload the 11 Axis2 and 11 CXF artifacts into the M4 branches local repo and update the pom.xml if someone will either respin/ republish the build for me or walk me through how to do it:-) Donald, excellent and I appreciate it. I would checkout the 2.0-M4 in branches to start with. There must be some lingering issue in hte build or we somehow picked up the SNAPSHOT though some transitive dependencies. If you like I can provide you with the repo I used for this build. It may be possible to address Alan's concern about being able to rebuild as well. Although, personally I think the time invested in 2.0 is better spent than waving a dead chicken on 2.0-M4. By the time it get built and voted on we'll be into next week most likely with the next milestone a few weeks away. I think a better solution would be to simply create an unstable set and put them up on people.apache.org. Other's thoughts? I would just put up the assembly bin-* bits for folks to play with and then not worry about the rest. M5 will be here soon enough. As long as we can learn from what was wrong with M4 and incorporate the fixes (to code, process, whatever) into M5 then we are making progress. Though now I have a wonderful image of Matt twirling a dead chicken over his head. Can we get a dead chicken for J1 and get Matt to reenact this? I'd like to get that on video :-) --jason
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
can't we just provide the binaries?, it is a milestone release that will live less than a month. Cheers! Hernan Matt Hogstrom wrote: On Apr 3, 2007, at 4:57 PM, Donald Woods wrote: I'll upload the 11 Axis2 and 11 CXF artifacts into the M4 branches local repo and update the pom.xml if someone will either respin/republish the build for me or walk me through how to do it:-) Donald, excellent and I appreciate it. I would checkout the 2.0-M4 in branches to start with. There must be some lingering issue in hte build or we somehow picked up the SNAPSHOT though some transitive dependencies. If you like I can provide you with the repo I used for this build. It may be possible to address Alan's concern about being able to rebuild as well. Although, personally I think the time invested in 2.0 is better spent than waving a dead chicken on 2.0-M4. By the time it get built and voted on we'll be into next week most likely with the next milestone a few weeks away. I think a better solution would be to simply create an unstable set and put them up on people.apache.org. Other's thoughts? -Donald
[jira] Created: (SM-918) Ability to reference Shared Libraries from Service Units
Ability to reference Shared Libraries from Service Units Key: SM-918 URL: https://issues.apache.org/activemq/browse/SM-918 Project: ServiceMix Issue Type: New Feature Components: servicemix-common Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Priority: Critical Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-918) Ability to reference Shared Libraries from Service Units
[ https://issues.apache.org/activemq/browse/SM-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-918. Resolution: Fixed URL: http://svn.apache.org/viewvc?view=revrev=525287 Ability to reference Shared Libraries from Service Units Key: SM-918 URL: https://issues.apache.org/activemq/browse/SM-918 Project: ServiceMix Issue Type: New Feature Components: servicemix-common Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Priority: Critical Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-919) Enhance JBI plugin to automatically generate SL references from SU
Enhance JBI plugin to automatically generate SL references from SU -- Key: SM-919 URL: https://issues.apache.org/activemq/browse/SM-919 Project: ServiceMix Issue Type: New Feature Components: tooling Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486509 ] Jarek Gawor commented on GERONIMO-3045: --- I think you can do something like WebservicesDocument doc = (WebservicesDocument)XmlObject.changeType(WebservicesDocument.type); Unable to run jax-rpc war test with Axis2 - Key: GERONIMO-3045 URL: https://issues.apache.org/jira/browse/GERONIMO-3045 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: 1.5 SUN SDK + WIN XP Reporter: Lin Sun Fix For: 2.0-M5 Attachments: G3045-new.patch, G3045.patch When running the jax-rpc war test with axis2, both test failed due to an exception thrown when parseWebServiceDescriptor is called. from reading the code, if webservices.xml doesn't exist, we call discoverwebservices, which will check if the class has annotation. if webservices.xml exists, we 'll just call parseWebServiceDescriptor, which caused the error for axis2 because axis2 moved to xbeans. The fix is to check if annotation exists when webservices.xml exists also. Tested the fix and able to pass the 2 jax-rpc war test test with them. Will attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486510 ] Jarek Gawor commented on GERONIMO-3045: --- Or even easier, you could just close the passed input stream and open another by doing wsDDUrl.openStream() if the namespace is right. Unable to run jax-rpc war test with Axis2 - Key: GERONIMO-3045 URL: https://issues.apache.org/jira/browse/GERONIMO-3045 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: 1.5 SUN SDK + WIN XP Reporter: Lin Sun Fix For: 2.0-M5 Attachments: G3045-new.patch, G3045.patch When running the jax-rpc war test with axis2, both test failed due to an exception thrown when parseWebServiceDescriptor is called. from reading the code, if webservices.xml doesn't exist, we call discoverwebservices, which will check if the class has annotation. if webservices.xml exists, we 'll just call parseWebServiceDescriptor, which caused the error for axis2 because axis2 moved to xbeans. The fix is to check if annotation exists when webservices.xml exists also. Tested the fix and able to pass the 2 jax-rpc war test test with them. Will attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (XBEAN-86) PATCH: null parameter in spring injections
PATCH: null parameter in spring injections -- Key: XBEAN-86 URL: https://issues.apache.org/jira/browse/XBEAN-86 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.7 Environment: Microsoft Windows XP [Version 5.1.2600] Reporter: Reshat Sabiq Spent a whole day on getting this to work thru xfire (services.xml): bean id=jaxbTypeRegistry class=org.codehaus.xfire.jaxb.JaxbTypeRegistry constructor-arg index=0null//constructor-arg /bean xbean-spring was forwarding this on erroneously to XBeanXmlBeanDefinitionParser.parseBeanFromExtensionElement, rather than delegating to super. PATCH to be attached right after submission. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (XBEAN-86) PATCH: null parameter in spring injections
[ https://issues.apache.org/jira/browse/XBEAN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reshat Sabiq updated XBEAN-86: -- Attachment: XBeanXmlBeanDefinitionParser.patch This fixes it, and appears to be the right way to do it to avoid a lot of other similar scenarios for various members of reservedElementNames. PATCH: null parameter in spring injections -- Key: XBEAN-86 URL: https://issues.apache.org/jira/browse/XBEAN-86 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.7 Environment: Microsoft Windows XP [Version 5.1.2600] Reporter: Reshat Sabiq Attachments: XBeanXmlBeanDefinitionParser.patch Spent a whole day on getting this to work thru xfire (services.xml): bean id=jaxbTypeRegistry class=org.codehaus.xfire.jaxb.JaxbTypeRegistry constructor-arg index=0null//constructor-arg /bean xbean-spring was forwarding this on erroneously to XBeanXmlBeanDefinitionParser.parseBeanFromExtensionElement, rather than delegating to super. PATCH to be attached right after submission. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2994) Apache Roller plugin
[ https://issues.apache.org/jira/browse/GERONIMO-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Petersson updated GERONIMO-2994: -- Attachment: roller_plugin.patch Attaching a patch for the changes described above. There are still problems getting the roller derby plugin setup to work correctly. I have tested deploying the roller derby db pool and the roller war (in G v2.0 jetty) manually and it currently fails to get a connection to the database so things seems to be a bit broken at the moment. I will try the mysql, tomcat combo configuration to see if it works. Apache Roller plugin - Key: GERONIMO-2994 URL: https://issues.apache.org/jira/browse/GERONIMO-2994 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.2 Reporter: Peter Petersson Assigned To: David Jencks Priority: Minor Attachments: geronimo-plugins.xml, geronimo-web.xml, geronimo-web.xml, plan.xml, pom.xml, pom.xml, roller-custom.properties, roller-custom.properties, roller-custom.properties, roller-derbydb-plan-g1_2.xml, roller-mysql-db-plan-1-2.xml, roller_plugin.patch Have been working on getting Apache Roller running under Geronimo I finally got to the point where the roller application seems to be running smoothly in Geronimo v1.2 (current snapshot). It would be great to eventually see this application as a plugin in G so here are pointers to resources and attached plans. Apache Roller v3.1 Resources (soon to be released) Apache roller home: http://rollerweblogger.org/project/ The bundle: http://people.apache.org/~snoopdave/apache-roller-3.1/ (until it will be available directly via roller home) Required jars: https://roller.dev.java.net/servlets/ProjectDocumentList?expandFolder=6959folderID=0 Path to database create scripts can be found in the bundle above under: apache-roller-3.1/webapp/roller/WEB-INF/dbscripts/ I have tested with the derby database and mysql 5. There is currently a issue with G v1.2 and hibernates v3.1 (used by roller 3.1) property loader that gets a FATAL [HibernateRollerImpl] Error initializing Hibernate java.lang.ClassCastException: java.util.HashSet at org.hibernate.util.PropertiesHelper.resolvePlaceHolders(PropertiesHelper.java:88) Hibernate is expecting a String value (This issue is fixed in hibernate 3.2 with a instanceOf check) Fortunately David Jencks hit this problem in trunk and suggested turning off the activemq and activemq-broker modules in config.xml, to test things out, and after that everything was running smothly :). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3061) Upgrade Dojo to 0.4.2
Upgrade Dojo to 0.4.2 - Key: GERONIMO-3061 URL: https://issues.apache.org/jira/browse/GERONIMO-3061 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0-M4, 2.0-M5 Reporter: Jay D. McHugh Priority: Minor There is a new version of Dojo (0.4.2) available for download. http://download.dojotoolkit.org/release-0.4.2/dojo-0.4.2-ajax.zip There are a number of bug fixes and the update should cause no ripples. The actual changes necessary are fairly straight forward: 1) download the zip 2) copy the zip into the /repository/org/dojotoolkit/dojo/0.4.2 directory with the name dojo-0.4.2.zip (have to create the directory first). 3) update the dojo-version variable in the root pom.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
Lesson learned, is that we need at least a milestone cut from our dependent projects. For M4, we could have used Jetty 6.1.2rc2, which was released on 3/27, but for CXF and Axis2, we only have timestamped snapshots, which I couldn't get to work via the local server/repository hack after several hours of trying, due to the snapshots having dependencies on other snapshots -Donald Jason Dillon wrote: On Apr 3, 2007, at 2:18 PM, Matt Hogstrom wrote: On Apr 3, 2007, at 4:57 PM, Donald Woods wrote: I'll upload the 11 Axis2 and 11 CXF artifacts into the M4 branches local repo and update the pom.xml if someone will either respin/republish the build for me or walk me through how to do it:-) Donald, excellent and I appreciate it. I would checkout the 2.0-M4 in branches to start with. There must be some lingering issue in hte build or we somehow picked up the SNAPSHOT though some transitive dependencies. If you like I can provide you with the repo I used for this build. It may be possible to address Alan's concern about being able to rebuild as well. Although, personally I think the time invested in 2.0 is better spent than waving a dead chicken on 2.0-M4. By the time it get built and voted on we'll be into next week most likely with the next milestone a few weeks away. I think a better solution would be to simply create an unstable set and put them up on people.apache.org. Other's thoughts? I would just put up the assembly bin-* bits for folks to play with and then not worry about the rest. M5 will be here soon enough. As long as we can learn from what was wrong with M4 and incorporate the fixes (to code, process, whatever) into M5 then we are making progress. Though now I have a wonderful image of Matt twirling a dead chicken over his head. Can we get a dead chicken for J1 and get Matt to reenact this? I'd like to get that on video :-) --jason smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
Agree, lets release M4 as-is with the repo and source zipfiles, in case anyone wants to debug a problem they find -Donald Hernan Cunico wrote: can't we just provide the binaries?, it is a milestone release that will live less than a month. Cheers! Hernan Matt Hogstrom wrote: On Apr 3, 2007, at 4:57 PM, Donald Woods wrote: I'll upload the 11 Axis2 and 11 CXF artifacts into the M4 branches local repo and update the pom.xml if someone will either respin/republish the build for me or walk me through how to do it:-) Donald, excellent and I appreciate it. I would checkout the 2.0-M4 in branches to start with. There must be some lingering issue in hte build or we somehow picked up the SNAPSHOT though some transitive dependencies. If you like I can provide you with the repo I used for this build. It may be possible to address Alan's concern about being able to rebuild as well. Although, personally I think the time invested in 2.0 is better spent than waving a dead chicken on 2.0-M4. By the time it get built and voted on we'll be into next week most likely with the next milestone a few weeks away. I think a better solution would be to simply create an unstable set and put them up on people.apache.org. Other's thoughts? -Donald smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-3045: -- Attachment: G3045-latest.patch Hi Jarek, thanks again for your comment. Tried No. 1 you proposed and worked well. That seemed a bit easier to me so that we don't need to open the stream and parse the inputstream again. Please let me know if the latest patch looks ok. Thanks, Lin Unable to run jax-rpc war test with Axis2 - Key: GERONIMO-3045 URL: https://issues.apache.org/jira/browse/GERONIMO-3045 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: 1.5 SUN SDK + WIN XP Reporter: Lin Sun Fix For: 2.0-M5 Attachments: G3045-latest.patch, G3045-new.patch, G3045.patch When running the jax-rpc war test with axis2, both test failed due to an exception thrown when parseWebServiceDescriptor is called. from reading the code, if webservices.xml doesn't exist, we call discoverwebservices, which will check if the class has annotation. if webservices.xml exists, we 'll just call parseWebServiceDescriptor, which caused the error for axis2 because axis2 moved to xbeans. The fix is to check if annotation exists when webservices.xml exists also. Tested the fix and able to pass the 2 jax-rpc war test test with them. Will attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3056) WARNING messages issued during deployment on Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486544 ] Jay D. McHugh commented on GERONIMO-3056: - I am encountering the same problem on tomcat (current trunk build). And it does not appear to be dependent on whether or not there is a web.xml file. Here is a snip of the log using my own app (I did have a web.xml): 21:00:13,307 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/rt.jar!/META-INF 21:00:13,308 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/jsse.jar!/META-INF 21:00:13,309 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/jce.jar!/META-INF 21:00:13,329 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/charsets.jar!/META-INF 21:00:13,330 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/ext/dnsns.jar!/META-INF 21:00:13,352 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/ext/sunpkcs11.jar!/META-INF 21:00:13,353 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/ext/sunjce_provider.jar!/META-INF 21:00:13,353 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/ext/localedata.jar!/META-INF 21:00:13,354 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/bin/server.jar!/META-INF 21:00:13,355 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/lib/geronimo-kernel-2.0-SNAPSHOT.jar!/META-INF 21:00:13,357 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/lib/commons-logging-1.0.4.jar!/META-INF 21:00:13,358 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/lib/log4j-1.2.14.jar!/META-INF Here is a snip of the log using the snoop.war: 21:02:53,359 WARN [TomcatModuleBuilder] Web application . does not contain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. 21:02:53,446 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/rt.jar!/META-INF 21:02:53,448 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/jsse.jar!/META-INF 21:02:53,449 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/jce.jar!/META-INF 21:02:53,450 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/charsets.jar!/META-INF 21:02:53,451 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/ext/dnsns.jar!/META-INF 21:02:53,453 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/ext/sunpkcs11.jar!/META-INF 21:02:53,454 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/ext/sunjce_provider.jar!/META-INF 21:02:53,455 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/jdk1.5.0_11/jre/lib/ext/localedata.jar!/META-INF 21:02:53,456 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/bin/server.jar!/META-INF 21:02:53,457 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/lib/geronimo-kernel-2.0-SNAPSHOT.jar!/META-INF 21:02:53,458 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/lib/commons-logging-1.0.4.jar!/META-INF 21:02:53,459 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/lib/log4j-1.2.14.jar!/META-INF 21:02:53,460 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/lib/xpp3-1.1.3.3.jar!/META-INF 21:02:53,461 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/lib/xstream-1.1.3.jar!/META-INF 21:02:53,462 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/opt/geronimo-tomcat6-jee5-2.0-SNAPSHOT/bin/jpa.jar!/META-INF WARNING messages issued during deployment on Jetty -- Key: GERONIMO-3056 URL: https://issues.apache.org/jira/browse/GERONIMO-3056 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, Jetty Affects Versions: 2.0-M4 Reporter: Joe Bohn
[jira] Commented: (GERONIMO-3051) DB Viewer portlet error
[ https://issues.apache.org/jira/browse/GERONIMO-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486548 ] Joe Bohn commented on GERONIMO-3051: I had a similar problem with some other JSTL apps so I tried to apply the GERONIMO-3051-new.patch. After I applied the patch I could no longer build the config for webconsole-tomcat (and I presume webonsole-jetty though the build didn't get that far). It seems like building this car requires jstl to be at a higher level in the classpath than just in the TCCL. Here's the build exception: [ERROR] FATAL ERROR [INFO] [INFO] org/apache/taglibs/standard/tag/common/core/ChooseTag [INFO] [INFO] Trace java.lang.NoClassDefFoundError: org/apache/taglibs/standard/tag/common/core/ChooseTag at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.getDeclaredMethods(Class.java:1763) at org.apache.xbean.finder.ClassFinder.init(ClassFinder.java:162) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:780) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:790) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:303) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder$$FastClassByCGLIB$$6f85ec2c.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$166ace5e.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$166ace5e.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:607) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$4d984873.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at
[jira] Assigned: (GERONIMO-3056) WARNING messages issued during deployment on Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3056: --- Assignee: Jay D. McHugh WARNING messages issued during deployment on Jetty -- Key: GERONIMO-3056 URL: https://issues.apache.org/jira/browse/GERONIMO-3056 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, Jetty Affects Versions: 2.0-M4 Reporter: Joe Bohn Assigned To: Jay D. McHugh Priority: Minor Attachments: snoop.war While deploying a simple web application (WAR) without a plan from the admin console on a Jetty JEE5 server instance everything appears to deploy and work correctly. However, there are these WARNing messages written to the console that appear to reference each jar in the repository. Note, the first WARNing message below is expected (because there was no plan) but the subsequent Cannott read JAR file... messages are not expected. I didn't see the same problem on Tomcat. This was using the 2.0-M4-rc1 13:25:12,369 WARN [JettyModuleBuilder] Web application . does not contain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. 13:25:13,151 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/endorsed/yoko-rmi-spec-1.0-incubating-SNAPSHOT.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/endorsed/yoko-spec-corba-1.0-incubating-SNAPSHOT.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/ui.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/laf.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsse.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jce.jar!/META-INF 13:25:13,153 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/charsets.jar!/META-INF 13:25:13,153 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/apple_provider.jar!/META-INF 13:25:13,323 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/dnsns.jar!/META-INF 13:25:13,373 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/localedata.jar!/META-INF 13:25:13,373 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunjce_provider.jar!/META-INF 13:25:13,833 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunpkcs11.jar!/META-INF 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/bin/server.jar!/META-INF 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/geronimo-kernel-2.0-M4.jar!/META-INF 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/commons-logging-1.0.4.jar!/META-INF 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/log4j-1.2.14.jar!/META-INF 13:25:13,835 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/xpp3-1.1.3.3.jar!/META-INF 13:25:13,835 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/xstream-1.1.3.jar!/META-INF 13:25:13,835 WARN
[jira] Updated: (GERONIMO-3056) WARNING messages issued during deployment on Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3056: Attachment: geronimo-3056.patch A previous change to remove spaces from the jar name that was being scanned added and additional test (isDirectory and canRead). Both conditions were being tested in the same if, so regardless of which one failed, the result appeared to be a problem reading the jar. Adjusted the test to check each condition seperately. WARNING messages issued during deployment on Jetty -- Key: GERONIMO-3056 URL: https://issues.apache.org/jira/browse/GERONIMO-3056 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, Jetty Affects Versions: 2.0-M4 Reporter: Joe Bohn Assigned To: Jay D. McHugh Priority: Minor Attachments: geronimo-3056.patch, snoop.war While deploying a simple web application (WAR) without a plan from the admin console on a Jetty JEE5 server instance everything appears to deploy and work correctly. However, there are these WARNing messages written to the console that appear to reference each jar in the repository. Note, the first WARNing message below is expected (because there was no plan) but the subsequent Cannott read JAR file... messages are not expected. I didn't see the same problem on Tomcat. This was using the 2.0-M4-rc1 13:25:12,369 WARN [JettyModuleBuilder] Web application . does not contain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. 13:25:13,151 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/endorsed/yoko-rmi-spec-1.0-incubating-SNAPSHOT.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/endorsed/yoko-spec-corba-1.0-incubating-SNAPSHOT.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/ui.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/laf.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsse.jar!/META-INF 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jce.jar!/META-INF 13:25:13,153 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/charsets.jar!/META-INF 13:25:13,153 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/apple_provider.jar!/META-INF 13:25:13,323 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/dnsns.jar!/META-INF 13:25:13,373 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/localedata.jar!/META-INF 13:25:13,373 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunjce_provider.jar!/META-INF 13:25:13,833 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunpkcs11.jar!/META-INF 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/bin/server.jar!/META-INF 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/geronimo-kernel-2.0-M4.jar!/META-INF 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/commons-logging-1.0.4.jar!/META-INF 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/log4j-1.2.14.jar!/META-INF 13:25:13,835 WARN
[jira] Updated: (GERONIMO-3017) Web Apps (WAR files) that directly contain JPA entities cannot be deployed
[ https://issues.apache.org/jira/browse/GERONIMO-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh updated GERONIMO-3017: Patch Info: [Patch Available] Marking this issue to indicate that it has a patch. Web Apps (WAR files) that directly contain JPA entities cannot be deployed -- Key: GERONIMO-3017 URL: https://issues.apache.org/jira/browse/GERONIMO-3017 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0-M5 Reporter: Jay D. McHugh Assigned To: Jay D. McHugh Attachments: geronimo-3017-2.patch, geronimo-jira-3017.patch There is still a find and parse problem with persistence.xml in war files. It seems to work if you have your jpa entities in a jar file. But, if you have a WEB-INF/lib/META-INF/persistence.xml file, it finds it and dies with a substring error. I have not tested to see if this is a problem for WAR files contained in an EAR. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3045) Unable to run jax-rpc war test with Axis2
[ https://issues.apache.org/jira/browse/GERONIMO-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3045. --- Resolution: Fixed Patch applied (Committed revision 525383). Thanks so much Lin! Unable to run jax-rpc war test with Axis2 - Key: GERONIMO-3045 URL: https://issues.apache.org/jira/browse/GERONIMO-3045 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: 1.5 SUN SDK + WIN XP Reporter: Lin Sun Fix For: 2.0-M5 Attachments: G3045-latest.patch, G3045-new.patch, G3045.patch When running the jax-rpc war test with axis2, both test failed due to an exception thrown when parseWebServiceDescriptor is called. from reading the code, if webservices.xml doesn't exist, we call discoverwebservices, which will check if the class has annotation. if webservices.xml exists, we 'll just call parseWebServiceDescriptor, which caused the error for axis2 because axis2 moved to xbeans. The fix is to check if annotation exists when webservices.xml exists also. Tested the fix and able to pass the 2 jax-rpc war test test with them. Will attach the patch after a full build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3061) Upgrade Dojo to 0.4.2
[ https://issues.apache.org/jira/browse/GERONIMO-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486557 ] Paul McMahan commented on GERONIMO-3061: I tried out dojo 0.4.2 and like you say their website suggests that this version contains only bug fixes and should not cause any upgrade problems. However, several of the new dojo based debug viewers in the console don't function correctly on this new version of dojo. The invert tree button in the classloader viewer, for example, doesn't work. So we may need to skip this version of dojo or look into the problem in the classloader and dependency viewers. The JMX viewer seems to work ok. Upgrade Dojo to 0.4.2 - Key: GERONIMO-3061 URL: https://issues.apache.org/jira/browse/GERONIMO-3061 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M4, 2.0-M5 Reporter: Jay D. McHugh Priority: Minor There is a new version of Dojo (0.4.2) available for download. http://download.dojotoolkit.org/release-0.4.2/dojo-0.4.2-ajax.zip There are a number of bug fixes and the update should cause no ripples. The actual changes necessary are fairly straight forward: 1) download the zip 2) copy the zip into the /repository/org/dojotoolkit/dojo/0.4.2 directory with the name dojo-0.4.2.zip (have to create the directory first). 3) update the dojo-version variable in the root pom.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3051) DB Viewer portlet error
[ https://issues.apache.org/jira/browse/GERONIMO-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486568 ] Frank G commented on GERONIMO-3051: --- Hi, Joe, I retried to build the webconsole-tomcat and webconsole-jetty6 using the patch and didn't see the error you encountered. GERONIMO-3051-new.patch was made based on GeroninoSource_home\configs, not GeroninoSource_home, I'm not sure if this caused the error. Can you try it again, if it still fails, I need more deep investigation :-). DB Viewer portlet error --- Key: GERONIMO-3051 URL: https://issues.apache.org/jira/browse/GERONIMO-3051 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 2.0-M4 Environment: embedded Derby databases Reporter: Hernan Cunico Attachments: GERONIMO-3051-new.patch, GERONIMO-3051.patch There is a problem when trying to view an embedded Derby database. I am able to successfully create a new DB with the DB manager and a new entry appears in the DB Viewer but when I try to view that DB from the DB Viewer I get a portlet error. When I check the logs I get this: 09:57:02,421 ERROR [listTables_jsp]] Servlet.service() for servlet jsp.WEB_002dINF.view.internaldb.listTables_jsp threw exception javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Error getting connection: java.sql.SQLException: No suitable driver ... 09:57:02,421 ERROR [[DBViewer]] Servlet.service() for servlet DBViewer threw exception javax.servlet.ServletException ... 09:57:02,453 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException ... With the exception of the SystemDatabase all the other databases created on the embedded Derby are also unaccessible from other applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
