Re: ActiveMQ and ServiceMix reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noel J. Bergman wrote: Considering that both ActiveMQ and ServiceMix really ought to be targeting TLP status, learning to do this is important. That's a bit much, Noel. Where they end up is primarily their own concern -- and not determined until graduation anyway. You started the message wearing your official hat. If you have a personal opinion about the matter :-) please take the official hat off before expressing it? - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBRBgpOJrNPMCpn3XdAQIvvgP9FTGNDj2QOYA9AIuCSv7UiIRH2Ukv8xgz MCTFszKtvSCe4OLp6zZ1Yiy+hktg8mKS9JVPlK3c6cTye6eEqX17Rk3UbDI6MKuj R4giGBf+1iLNILFuvDfMUyLY2q50u++sn4HTj3LgYiou86MSKaj9Zz2iz4vWU2cm v4sLfoVgdEw= =VBCd -END PGP SIGNATURE-
Re: exposing a jbi endpoint as a SOAP endpoint
I'm having problems building servicemix so I can't try your update. I
have the following errors
[WARNING] POM for 'incubator-activemq:activemq-core:pom:4.0-SNAPSHOT' is
invalid. It will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM.
Downloading:
http://repo1.maven.org/maven2/org/apache/db/ddlutils/ddlutils/1.0-20060223/ddlutils-1.0-20060223.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
Downloading:
http://snapshots.maven.codehaus.org/maven2/org/apache/db/ddlutils/ddlutils/1.0-20060223/ddlutils-1.0-20060223.pom
[WARNING] Unable to get resource from repository maven2-snapshots
(http://snapshots.maven.codehaus.org/maven2)
Downloading:
http://servicemix.org/m2-repo/org/apache/db/ddlutils/ddlutils/1.0-20060223/ddlutils-1.0-20060223.pom
[WARNING] Unable to get resource from repository servicemix-m2-repo
(http://servicemix.org/m2-repo)
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/db/ddlutils/ddlutils/1.0-20060223/ddlutils-1.0-20060223.pom
[WARNING] Unable to get resource from repository apache-m2
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://cvs.apache.org/repository/org.apache.db.ddlutils/poms/ddlutils-1.0-20060223.pom
[WARNING] Unable to get resource from repository apache
(http://cvs.apache.org/repository)
Downloading:
http://dist.codehaus.org/org.apache.db.ddlutils/poms/ddlutils-1.0-20060223.pom
[WARNING] Unable to get resource from repository codehaus
(http://dist.codehaus.org)
Downloading:
http://repo.logicblaze.com/maven1/org.apache.db.ddlutils/poms/ddlutils-1.0-20060223.pom
[WARNING] Unable to get resource from repository logicblaze
(http://repo.logicblaze.com/maven1)
and so on ...
Maven seems to have problems with active-mq and its depencies, I know is
not a problem of servicemix, but do you know a workaround?
Another issue: writing my component I used xfire for web service
runtime, wrapping it as a JBI component I had to import the following
class: org.apache.servicemix.jsr181.xfire.JbiTransport, which is located
in the jsr181 component. Do you think it could be moved to common? or am
I doing something wrong?
thanks
Raffaele
On Mon, 2006-03-13 at 17:28 +0100, Guillaume Nodet wrote:
On 3/13/06, Raffaele Spazzoli [EMAIL PROTECTED] wrote:
I did as you said and it worked, thanks.
There are still a couple of issue that I'd like to understand:
1. the SOAP-Http proxy service doesn't provide a wsdl. Do you think that
could be possible to take the wsdl of the proxied service strip the jbi
binding and put a SOAP-http binding?
Done. You should give it a try. It does not currenly generate the binding
informations,
only the http or soap address for the endpoint.
2. I configured the routing using the xbean file:
http:endpoint service=im:VinciService
endpoint=imhttp:VinciService
role=consumer
locationURI=http://localhost:8192/Service/VinciService;
defaultMep=http://www.w3.org/2004/08/wsdl/in-out;
soap=true /
I'd like to do the same using the standard connection definitions of the
jbi deployment descriptor of the service assembly. Does it make sense
and is it supported in serivicemix?
Connections are now fully supported, but I'm not really sure how you could
use them.
They have been rewritten last week.
A connection defines that when a component will send a message to the
consumer
endpoint (or interface), it will be routed to the given provider endpoint.
The main goal
is to be able to define service units that are independant of the provider
endpoints.
These endpoints are thus defined in the service assembly with connections.
connection
consumer endpoint-name=im:VinciServiceHttpPort
service-name=im:VinciService
/consumer
provider endpoint-name=im:VinciServiceJBIPort
service-name=im:VinciService
/provider
/connection
If I try to do it servicemix complains that it can't find the cosumer
service (the proxy), I believe it does is because the proxy service
doesn't register a wsdl, so back to the previous point.
About the service-common library I found it useful but not much
documented, it took me a couple of days of code reading to understand
what it could do for me.
Yeah, i know. I will try to put write some doc in the following weeks.
Last thing I suggest to add to the maven-servicemix-plugin a couple of goal
to help the deploy of install zip and service assemblies.
supposing to have a directory structure that mirrors the service assembly,
I did the following scripts that could be a start:
goal name=jbi:install prereqs=jbi:jbi description=install
installer in deploy directory of esb
ant:echoinstalling installer/ant:echo
ant:delete file=${maven.jbi.esb.dir}/install/${maven.jbi.final.name
}/
ant:copy file=${maven.build.dir}/${maven.jbi.final.name} todir=${
Re: ActiveMQ and ServiceMix reports
Hi Henri, I think a good example of why not just a shoe in is because when the ServiceMix and ActiveMQ apache commiter list was created, it included all previous commiters to the project. But 100% of committers may not have been active during the period of the incubation. All though the projects trusted those individuals enough in the past to give them commit privileges, perhaps the TLP PMC may want to see more recent activity to evaluate if they truly 'get' the Apache way. Regards, Hiram On 3/15/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/15/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Noel, If the ActiveMQ / ServiceMix community do decide to go under some other TLP, I'm sure it would not take long for the active participants of the community to asked to Join the TLP's PMC. It would behoove that PMC to include such active community participants in the decision making proccess. Interesting reply - I'd been assuming that when an incubatee graduates into an existing project, it's PPMC automatically get added to the PMC. So I was a bit confused as to why Noel was even asking the question. Furthermore, I believe that merging ActiveMQ and Servicemix into Geronimo community and PMC is easier than most cases since there are all ready several active ActiveMQ/ServiceMix commiters thar are Geronimo PMC members. Those PMC memebers can help propose and vouch for additional commiters to join the PMC. Yeah, overlap would help. Still surprised that it's not just a shoe-in. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Hiram
Re: ActiveMQ and ServiceMix reports
Noel, I think this email represents a good example of mixing official communication of the incubator with your personal agenda to make these top level projects. Emails like this lead to questions like, is this required of all podlings or is this just a requirement because Noel thinks these podlings should go top level. If your email had simply left your email at stating the policy, I think it would have been more effective and would not lead to the level of frustration I have. -dain On Mar 14, 2006, at 5:22 PM, Noel J. Bergman wrote: The full status of incubation is at URL is not what the board accepts as a report. No reports by reference. Actual text describing status and progress, please. :-) Also the file referenced by URL should be: http://incubator.apache.org/projects/activemq.html http://incubator.apache.org/projects/servicemix.html which comes from: http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ projects /activemq.xml http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ projects /servicemix.xml See http://incubator.apache.org/guides/website.html for further details. That should have the standard checklist as well as a log of important events, but we also want descriptive text in a Board report. Considering that both ActiveMQ and ServiceMix really ought to be targeting TLP status, learning to do this is important. --- Noel
[jira] Commented: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
[ http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12370491 ] Greg Wilkins commented on GERONIMO-1686: javax/servlet/SingleThreadedModel.java should be javax/servlet/SingleThreadModel.java Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work -- Key: GERONIMO-1686 URL: http://issues.apache.org/jira/browse/GERONIMO-1686 Project: Geronimo Type: New Feature Reporter: Bill Dudney Assignee: Jeff Genender Priority: Minor Attachments: jee5_exp.patch, jee5_exp_servlet.patch I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the week of 3/6/06. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ Graduation From Incubator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noel J. Bergman wrote: Personally, I believe that ActiveMQ ought to be a TLP. Just to be clear, though, that's just a personal opinion at this time, and in no way a 'dis is how t'ings is gonna be' statement. Right? :-) What makes a project with multiple codebases an umbrella is a gray area. I've posted *my* first-pass definition of the term: a TLP that has no deliverable packages of its own, only from its subprojects. There's no 'Apache Jakarta' package, so it's an umbrella. There *is* an 'Apache HTTP Server' package, so that isn't. Subject to exceptions, clarifications, and further refinements, of course, but that's my working definition. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBRBf065rNPMCpn3XdAQKD9wQA3KqhUOsk9WG2OAvFyGmZF+e9mbQTq9O/ aXOa4qVFWfNns/rc2NpPwO6jewSepneo+uVKMBk/5MCjczuwFZSmq9uMyE9LJ/Na czsKVChEYYrHJnrDoKXoQqmaIxnDLBtYU/SEHggzWH8L9RuryFUXPV5/HGSCSLKu EvPHDljpWJU= =dSia -END PGP SIGNATURE-
Re: ActiveMQ Graduation From Incubator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: What if folks involved in the project on the Geronimo project don't want it to be a TLP - at least not for a while yet? e.g. can't we just use the Geronimo PMC until the time folks want/decide to start to go TLP? Or is going TLP now mandatory? No, it's not mandatory. And (AFAIK) no-one's going to force it TLP against the consensual wishes of its participants and sponsor unless there's a bloody good reason. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBRBf2JZrNPMCpn3XdAQK1+wQAtugkocu4mpiMjbSW1Trgby2tbGlme3rt ZoHH6dj27vAGIEqwqP8K0elHhh7fezea0cItawPcXTHjwXKQMkbonv1XGdfdeAIZ nrwIfyJAb3t3P0qR5O3oekEeazFu7odeoWf6vYKypg0JyBc1jPTRxEd6QB6yEvai dxSP6AMPGzw= =EygF -END PGP SIGNATURE-
Re: ActiveMQ Graduation From Incubator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: Just to make sure this was allowed, before pitching it to the communities, I asked a few of the Board members at Euro OS con and they said it was possible. I didn't want to get into a situation where we do all of the work to uproot and move exiting communities and then end up with just a bunch of separate TLPs because of some unknown apache rules. Now it seem like that is exactly what will happen. Why do you say that? Noel has stated his current *personal* opinion, and his *personal* opinion of board policy as Keep in mind that the ASF Board has established a pretty conscious decision for projects to go TLP, and to disband umbrella projects. IMHO, a podling that was envisioned as joining an existing TLP will end up doing so unless there are really good reasons for it to go TLP instead. The only time (again IMHO) that the collective desires of the specific communities involved (in this case, AMQ and Geronimo) would be overruled is if the determination is made that such a merger would not make sense or would not be in the best interests of the ASF.As an hypothetical example, I very much doubt that a podling for a pattern recognition filtering package would be allowed to join the HTTP Server project, despite being originally intended for filtering server logs. A traffic-filtering module written to the httpd API would be unlikely to go anywhere else. An IRC server based on the httpd framework might go either way. It's not just rhe podling's and sponsor's communities that need to be considered, although they're by far the biggest part. It's also the overall Apache community that needs to be factored in. If going subproject is considered to be likely to be harmful to the ASF, it won't happen. Otherwise it probably will. All IMHO. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBRBf8a5rNPMCpn3XdAQL5VwP9E/nNpdNA3CHD4jjLrCqwSRy7dgXUjzQj OCCujB5mm2H8LMVhNYgHSfRYlrQAAayXrizwTwUT5zZIOstbX9scUSGM5MCnHOg8 ZakW6O/+N41EaNkdWhBBdwPHVNl9PmTqbwb5sMW1Abo+RKtPEVUG1gnheoFyqd4M 6w82VLeqVi0= =NVCO -END PGP SIGNATURE-
Re: svn commit: r386059 - in /geronimo/site: ./ docs/ docs/redirects/ lib/ wikimesh/activemq-site/ wikimesh/servicemix-site/ xdocs/ xdocs/redirects/ xdocs/stylesheets/
2006/3/15, [EMAIL PROTECTED] [EMAIL PROTECTED]: Author: jsisson Date: Wed Mar 15 03:53:51 2006 New Revision: 386059 ... Added: geronimo/site/lib/commons-collections-3.1.jar (with props) geronimo/site/lib/commons-lang-2.1.jar (with props) geronimo/site/lib/jdom-1.0.jar (with props) geronimo/site/lib/oro-2.0.8.jar (with props) geronimo/site/lib/werken-xpath-0.9.4.jar (with props) What are the jars for? It looks very weird in the age of Maven, doesn't it? ;) Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: m2 : security module
Comments inline --- Prasad Kashyap [EMAIL PROTECTED] wrote: The following line seems to be the culprit. gbean.setAttribute(baseDirectory, .); You may already have got the system property basedir and used it in the line above. M2 builds run the tests in the same jvm. So the following props set in an earlier BasicServerInfo object is left behind. org.apache.geronimo.home.dir org.apache.geronimo.server.dir. Are you also having problems running surefire-plugin with forkmode=once? Try to unset those too before you begin the test. Cheers Prasaf On 3/14/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Anita, The path doesn't look right. Where's the module name in that path ? D:\anita\geronimo\geronimo-1.1\.\src\test-data\data\users.properties Seems like user.dir property is being used instead of basedir. At first, I also thought that this path was the culprit. But the same path is used in maven1 build and the other m2 build and the properties file is found. The following appears on the console just before the java-io.FileNotFoundException. ERROR [Socket Connection: /127.0.0.1:4242 - /127.0.0.1:1580] Properties File Lo gin Module - data load failed java.io.FileNotFoundException Thnaks Anita Cheers Prasad On 3/14/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Hi, I am trying to debug a strange problem in security module (rev 385723). The module builds fine with maven1 build. It builds fine with m2 from 'security' directory. When I build from the top level directory using mvn -Dmodule=security clean test I get build failures. I have attached the report for ConfigurationEntryTest. The main cause of failures in three tests is : ERROR [main] Properties File Login Module - data load failed java.io.FileNotFoundException: D:\anita\geronimo\geronimo-1.1\.\src\test-data\data\users.properties (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at java.io.FileInputStream.init(FileInputStream.java:66) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.jav a:156) at java.net.URL.openStream(URL.java:913) any ideas? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: ActiveMQ Graduation From Incubator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Strachan wrote: What if folks involved in the project on the Geronimo project don't want it to be a TLP - at least not for a while yet? e.g. can't we just use the Geronimo PMC until the time folks want/decide to start to go TLP? Or is going TLP now mandatory? Unless there is a really good reason for AMQ *not* to graduate into Geronimo, that's what will happen. At which point it will be part of Geronimo and the Geronimo PMC applies. While it's still in the incubator, though.. no, AMQ *can't* use the Geronimo PMC for oversight. AMQ's PPMC can have zero to N of the Geronimo PMC members on it, but it would also have some from the incubator (at least the mentors -- currently just you) and some committers from the podling (who would *not* be on the Geronimo PMC). Sponsoring TLPs can provide advice and guidance to podlings, but not direction -- they're self-directing. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBRBgRj5rNPMCpn3XdAQLnLQP/cZMXTLLaS+/wvVXwXqzseNwA8PqUziaJ H3aRUgfzskZtYcZ0a6XNKQsIFtPbmtq7hC1Wpd3vQ6b7hYt4wmjkAsw7ZhgXH5yE p1sI1WXJvG44Mr27mQdAVF/zuAnOFaAe4yThWyR9Jp4tb95qPY56MsuDkO0y4Cd9 zBfyXY7edfY= =PKwQ -END PGP SIGNATURE-
Re: daytrader benchmark results
Hi Matt,thanks a lot for the reply. A few more questions...The Y-Axis represents transactions per second.What is this value - is it a general magnitude like time or is it related to the type of request which is under study, ( i.e. number of JDBCRead transactions per second)?All the TPS metrics were gathered from the client. The goal was to get the server to 100% CPU utilization.Before your reply I suppose that Web Server Manager portlet was used to perform monitoring, please see the post http://www.mail-archive.com/dev@geronimo.apache.org/msg18979.htmlSo the question is - do you use any additional client application (not included in Daytrader), which provides workload for Geronimo? Thank you.--Best regards,Maxim Berkultsev, Intel Middleware Products DivisionMatt Hogstrom wrote:Hi Maxim,Comments inline...Maxim Berkultsev wrote: Hello all, I've looked through Daytrader workload results and analysis for Geronimo published at http://www-1.ibm.com/support/docview.wss?uid=swg27006724 For the bar diagrams, which show Geronimo and 'target' server indicators, immediate questions are: - what is the measure unit for values in Y-axis? The Y-Axis represents transactions per second. - how are the values for 'target' performance received?One problem with performance measurments is that they typically incite many people to claim victory or cry foul depending on the results. This is also complicated by the fact that many commercial products have a no benchmark publish clause in their licenses. In order to have something to compare Geronimo to as well as avoid the inevitable fallout of naming a comparison point I did a series of measurments on other Open Source and commercial AppServer products. I thook these results and created the competitive target metric.The competitive target metric is simply my estimation of a respectable performance measurement. Meaning, as we achieve that metric one should be happy with the results.Note that these numbers are pretty old. I have a new set of data that I've been saying will be out for a while. I guess its time to actually make that happen.So, for purposes of consumption I would wait a few days for the new report to surface. We'll post it on our site. Also, could someone clarify if the performance data was collected on a client or a server side?All the TPS metrics were gathered from the client. The goal was to get the server to 100% CPU utilization. Also, if you guys are willing we could use some of the newer Potomac 3.6Ghz chips:)
[jira] Assigned: (GERONIMO-1740) Plugin migration to Maven 2: geronimo-packaging-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1740?page=all ] Anita Kulshreshtha reassigned GERONIMO-1740: Assign To: Anita Kulshreshtha Plugin migration to Maven 2: geronimo-packaging-plugin -- Key: GERONIMO-1740 URL: http://issues.apache.org/jira/browse/GERONIMO-1740 Project: Geronimo Type: Sub-task Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Anita Kulshreshtha It's a task to keep track of the progress of the plugin build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r383123 - /geronimo/trunk/configs/openejb/project.xml
I seem to be having problems with the dependency in openejb recently added for activecluster. Starting with a clean source image (386076), an empty local cache, and an empty local repository I get an error that the activecluster dependency cannot be found. I can see the dependency on activecluster in the openejb project.xml, the version appears to match the version that is available on codehaus. However, I never see an attempt to download the jar locally and hence it isn't available. Is there something else that needs to be specified to cause the download of activecluster? Here's the output from the build failure: + | geronimo-configs Configuration for application client deployments | Memory: 42M/53M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download j2ee-deployer-1.2-SNAPSHOT.car. Attempting to download geronimo-spec-corba-1.0-SNAPSHOT.jar. Attempting to download geronimo-client-builder-1.2-SNAPSHOT.jar. Attempting to download geronimo-jetty-builder-1.2-SNAPSHOT.jar. Attempting to download openejb-builder-2.2-SNAPSHOT.jar. Attempting to download openejb-pkgen-builder-2.2-SNAPSHOT.jar. build:start: multiproject:install-callback: [echo] Running car:install for Configuration for application client deployments 13:22:05,812 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri active cluster/activecluster/1.2-20051115174934/jar not found in repository org.apache.geronimo.common.DeploymentException: org.apache.geronimo.kernel.repository.MissingDependencyException: uri activecluster/activecluster/1.2-2005111517 4934/jar not found in repository at org.apache.geronimo.deployment.service.ServiceConfigBuilder.getDependencyURI(ServiceConfigBuilder.java:402) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:276) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addDependencies(ServiceConfigBuilder.java:303) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:204) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:167) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$f5ac0140.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:279) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:389) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:294) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute(PackageBuilderShell.java:232) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
little-G fixes
Jeff or Aaron, After the first patch for little-G was integrated about a month ago, I soon discovered two items in the console that were broken because they relied upon dependencies specified in other configurations that were removed. I have patches for these items that are waiting to be integrated. Could one of you take a look at them? https://issues.apache.org/jira/browse/GERONIMO-1634 https://issues.apache.org/jira/browse/GERONIMO-1699 Thanks, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: little-G fixes
Sure...I'll take a look today...thanks. Jeff Joe Bohn wrote: Jeff or Aaron, After the first patch for little-G was integrated about a month ago, I soon discovered two items in the console that were broken because they relied upon dependencies specified in other configurations that were removed. I have patches for these items that are waiting to be integrated. Could one of you take a look at them? https://issues.apache.org/jira/browse/GERONIMO-1634 https://issues.apache.org/jira/browse/GERONIMO-1699 Thanks, Joe
Re: ActiveMQ Graduation From Incubator
Noel J. Bergman wrote: Alan D. Cabrera wrote: This is not a vote, but simply a discussion about the graduation of ActiveMQ from the Incubator. Personally, I do not consider ActiveMQ ready. And I do believe that it should be targeting TLP status. It has its own community, is separately releasable and useable in many projects, not just as part of a J2EE server, and would do better as its own TLP. To reiterate, these are my views. The Incubator PMC may share or differ in its collective view. Keep in mind that I am not saying anything negative about ActiveMQ. I like the project. I have had quite constructive discussions with members of the project about possibly using the project. It simply has a way to go before it is ready as a TLP. For that matter, as others have pointed out, it still has some way to go in migrating infrastructure, of which JIRA is only one issue, and is being addressed. Generally speaking, I concur with the point made by others: new projects should learn from the mistakes of others, not emulate them. I only see infrastructure issues in your list of concerns that would prevent the graduation of ActiveMQ. You express an opinion that it should be a TLP but mention that it has a long way to go before it's ready for that. Can you enumerate what remains, aside from the infrastructure issues, to be done to graduate as a TLP? If AMQ has less inspiring aspirations and was to initially land as a sub-project, can you enumerate what remains to be done to graduate? IMO, aside from the infrastructure issues, AMQ is good to go as a sub-project. It should start there and if it's worthy enough, evolve into a TLP. I see no good reason for it to stay in the incubator at this time. Regards, Alan
[jira] Assigned: (GERONIMO-1743) Deploy.bat doesn't accept any arguments and hence doesn't work.
[ http://issues.apache.org/jira/browse/GERONIMO-1743?page=all ] John Sisson reassigned GERONIMO-1743: - Assign To: John Sisson Deploy.bat doesn't accept any arguments and hence doesn't work. --- Key: GERONIMO-1743 URL: http://issues.apache.org/jira/browse/GERONIMO-1743 Project: Geronimo Type: Bug Components: deployment Versions: 1.2 Environment: Windows xp Reporter: Joe Bohn Assignee: John Sisson Fix For: 1.2 Attachments: 1743_DeployScript.patch There is a bug in the deploy script with the treatment of arguments. Basically, the arguments are stored in a variable called ARGS but the script later assumes they are in CMD_LINE_ARGS. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r383123 - /geronimo/trunk/configs/openejb/project.xml
2006/3/15, Joe Bohn [EMAIL PROTECTED]: I seem to be having problems with the dependency in openejb recently added for activecluster. Starting with a clean source image (386076), an empty local cache, and an empty local repository I get an error that the activecluster dependency cannot be found. It turned out that client-deployer also depended on activecluster. I could reproduce it so it was easy to fix. Revision 386195 should sort it out. BTW: It had nothing to do with the previous commit. The real cause was that the configuration was built after openejb and that's why the jar was available at the time. Thanks Joe for spotting it! Joe Bohn Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Updated: (GERONIMO-1743) Deploy.bat doesn't accept any arguments and hence doesn't work.
[ http://issues.apache.org/jira/browse/GERONIMO-1743?page=all ] John Sisson updated GERONIMO-1743: -- Fix Version: 1.1 Version: 1.1 (was: 1.2) Bug introduced after 1.0. Fixed in time for 1.1 Deploy.bat doesn't accept any arguments and hence doesn't work. --- Key: GERONIMO-1743 URL: http://issues.apache.org/jira/browse/GERONIMO-1743 Project: Geronimo Type: Bug Components: deployment Versions: 1.1 Environment: Windows xp Reporter: Joe Bohn Assignee: John Sisson Fix For: 1.2, 1.1 Attachments: 1743_DeployScript.patch There is a bug in the deploy script with the treatment of arguments. Basically, the arguments are stored in a variable called ARGS but the script later assumes they are in CMD_LINE_ARGS. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1729) Module migration to Maven 2: installer-support
[ http://issues.apache.org/jira/browse/GERONIMO-1729?page=comments#action_12370595 ] Jacek Laskowski commented on GERONIMO-1729: --- Committed revision 386203. Thanks Prasad! Module migration to Maven 2: installer-support -- Key: GERONIMO-1729 URL: http://issues.apache.org/jira/browse/GERONIMO-1729 Project: Geronimo Type: Sub-task Components: installer Versions: 1.x Reporter: Jacek Laskowski Assignee: Prasad Kashyap Attachments: pom.xml, setup.xml It's a task to keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ Graduation From Incubator
On 3/15/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noel J. Bergman wrote: Personally, I believe that ActiveMQ ought to be a TLP. Just to be clear, though, that's just a personal opinion at this time, and in no way a 'dis is how t'ings is gonna be' statement. Right? :-) What makes a project with multiple codebases an umbrella is a gray area. I've posted *my* first-pass definition of the term: a TLP that has no deliverable packages of its own, only from its subprojects. There's no 'Apache Jakarta' package, so it's an umbrella. There *is* an 'Apache HTTP Server' package, so that isn't. Subject to exceptions, clarifications, and further refinements, of course, but that's my working definition. Ah, a subject dear to my heart. Here are some definitions I've been working to: * An umbrella. A collection of communities under a single community. * A disjoint umbrella. The situation in which the subcommunities of an umbrella have low overlap - this is synonymous with the negative meaning of Jakartization and the thing the board are trying to avoid occuring in more than one place. * The ASF. A disjoint umbrella. * Jakarta Commons. A non-disjoint umbrella - works well, though it's always a struggle to avoid entropy's slow pull towards disjoint. History: Jakarta: by means of being a disjoint umbrella - started to mimic the foundation it was meant to be a part of. This is a redundancy problem - we don't need N groups of people being foundations at the ASF - the idea is for the foundation to be as small as it can be and still support the communities for which it exists. No more umbrellas: thus umbrellas became passe. The Incubator was created as a managed umbrella to be a proto-foundation; the ASF remains the primary umbrella. All the problems inherent in Jakarta and other umbrellas remain; but they are now being dealt with by one group - the board. Speaking as an Incubator PMC member, I am currently -1 towards Geronimo ActiveMQ and +1 towards Apache ActiveMQ. This is because I've not yet heard much about how Geronimo plans to avoid disjointedness. I do really like the point that Geronimo has a common product - but I'm not sure it's enough. Plus how will it affect the use of the subprojects (because subprojects they would be) as stand alones? --- Lastly, speaking as someone who has used up the last couple of years of his Apache time dealing with the problem of being the bridge between a disjoint umbrella, and a board/foundation which is not organized for dealing with disjoint umbrellas, I recommend not creating a large umbrella. Have TLPs and have each TLP's website be at geronimo.apache.org. Investigate federations. Even investigate sharing mailing lists. However do not give yourself the pain of trying to funnel it all through a single chair. TLPs are not firewalled from each other (though it's not very obvious that that's the case); so investigate what it is you really want to achieve and don't focus on the single TLP part of things. TLPs are more about delegated oversight from the members/board, than community. Hen
RE: ActiveMQ Graduation From Incubator
Noel J. Bergman wrote: Personally, I believe that ActiveMQ ought to be a TLP. Just to be clear, though, that's just a personal opinion Which part of Personally, I believe wasn't clear? ;-) What makes a project with multiple codebases an umbrella is a gray area. I've posted *my* first-pass definition of the term: a TLP that has no deliverable packages of its own, only from its subprojects. So Geronimo would not be, DB would be? that's my working definition. Not at all bad for a first cut. Certainly thought provoking. --- Noel
[jira] Commented: (GERONIMO-1728) Module migration to Maven 2: installer-processing
[ http://issues.apache.org/jira/browse/GERONIMO-1728?page=comments#action_12370602 ] Jacek Laskowski commented on GERONIMO-1728: --- Committed revision 386212. Thanks Prasad! Module migration to Maven 2: installer-processing - Key: GERONIMO-1728 URL: http://issues.apache.org/jira/browse/GERONIMO-1728 Project: Geronimo Type: Sub-task Components: installer Versions: 1.x Reporter: Jacek Laskowski Assignee: Prasad Kashyap Attachments: pom.xml It's a task to keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ Graduation From Incubator
On 3/15/06, Henri Yandell [EMAIL PROTECTED] wrote: ...snip good stuff.. Have TLPs and have each TLP's website be at geronimo.apache.org. Investigate federations. Even investigate sharing mailing lists. ...snip good stuff.. Jakarta and XML have gone that 'federation' route with a bunch of 'friendly' TLPs. HTTP Server may eventually spin off more sub-projects to TLP status as well (such as mod_python). The APR spin-off from HTTP Server was probably the first federation (although it wasn't called that). HTTP Server depends upon APR and they have a large committer and PMCer overlap (but not total), but from the Foundation/Board's perspective - they are independent TLPs and are treated as such. The same technical arguments seem to be made for ActiveMQ and ServiceMix in their dependency relationship with Geronimo. -- justin
RE: ActiveMQ Graduation From Incubator
Dain Sundstrom wrote: Our goal when starting the incubation process of ActiveMQ, OpenEJB, ServiceMix, WADI, and XBean, was to consolidate the Geronimo community. Consolidating the community is a good thing. I've long wanted to see a number of those projects at the ASF. The vision was to have a single community focused on building a modular server architecture based on a single core. No disagreement. The question at hand is simple and specific. Are you going to actually make one community from the bunch, with everyone having access to work on every piece of code? Are you going to have a large, single, PMC with everyone having binding decisions over every aspect of the project? THAT is a TLP. each of the sub projects would be deliverable as a standalone (basically the core with one plugin installed). Separate from destination, but that sounded fine right up to the last point. What is the core? If I just want ActiveMQ, or I just want OpenEJB, or I just want ... can I get it, or do I have to take some code Geronimo stuff, too? From what Alan Cabrera said last night, it sounded as if there have been some complaints about that, specifically in his example with OpenEJB. Or in my case, if we want to use ActiveMQ for JMS in James, what other non-ActiveMQ bits would we required to deal with in order to get the code that was apparently separable earlier? end up with just a bunch of separate TLPs because of some unknown apache rules. I'm expressing a personal opinion that the projects would be better off as TLPs that collaborate with Geronimo. From what I am being told, that is not an uncommon view within those communities, although there are questions as to whether to go TLP directly or via Geronimo. Perhaps that ought to be put forward for the individuals who make up the communities to directly answer? :) --- Noel
[jira] Created: (GERONIMO-1744) dt_shmem default in geronimo.bat for JPDA_TRANSPORT environment variable not compatible with Eclipse debugger
dt_shmem default in geronimo.bat for JPDA_TRANSPORT environment variable not compatible with Eclipse debugger --- Key: GERONIMO-1744 URL: http://issues.apache.org/jira/browse/GERONIMO-1744 Project: Geronimo Type: Bug Components: startup/shutdown, usability Versions: 1.0 Environment: Windows XP Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.1, 1.2 Eclipse users cannot connect the Eclipse debugger to the JVM if you start Geronimo using the command geronimo.bat jpda run because the JPDA_TRANSPORT environment variable defaults to dt_shmem in the Geronimo.bat file and Eclipse only supports dt_socket and has no plans to support dt_shmem ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=1666 ). The default for JPDA_TRANSPORT in heronimo.bat should be changed to dt_socket so the default is usable by all debuggers and is consistent with the default in geronimo.sh -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ Graduation From Incubator
On 3/15/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On 3/15/06, Henri Yandell [EMAIL PROTECTED] wrote: ...snip good stuff.. Have TLPs and have each TLP's website be at geronimo.apache.org. Investigate federations. Even investigate sharing mailing lists. ...snip good stuff.. Jakarta and XML have gone that 'federation' route with a bunch of 'friendly' TLPs. HTTP Server may eventually spin off more sub-projects to TLP status as well (such as mod_python). The APR spin-off from HTTP Server was probably the first federation (although it wasn't called that). HTTP Server depends upon APR and they have a large committer and PMCer overlap (but not total), but from the Foundation/Board's perspective - they are independent TLPs and are treated as such. The same technical arguments seem to be made for ActiveMQ and ServiceMix in their dependency relationship with Geronimo. -- justin Right. I would suggest having individual TLPs, individual mailing lists, and individual websites, but with a lot of cross-linking, brand-logo [Geronimo federation image on each of the other TLP sites] and with the Geronimo PMC providing space (open to the other TLPs) on the Geronimo website for the integration details of each of these plugins. Just an idea though :) Hen
[jira] Closed: (GERONIMO-1724) Module migration to Maven 2: client
[ http://issues.apache.org/jira/browse/GERONIMO-1724?page=all ] Jacek Laskowski closed GERONIMO-1724: - Fix Version: 1.x Resolution: Fixed Assign To: Jacek Laskowski It seems that I had taken a look at project.xml where the directory was listed. Sorry for the confusion. Closing. Module migration to Maven 2: client --- Key: GERONIMO-1724 URL: http://issues.apache.org/jira/browse/GERONIMO-1724 Project: Geronimo Type: Sub-task Versions: 1.x Reporter: Jacek Laskowski Assignee: Jacek Laskowski Fix For: 1.x It's a task to help keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1745) The JPDA_OPTS environment variable is not honoured by geronimo.bat and is inconsistent with geronimo.sh
The JPDA_OPTS environment variable is not honoured by geronimo.bat and is inconsistent with geronimo.sh --- Key: GERONIMO-1745 URL: http://issues.apache.org/jira/browse/GERONIMO-1745 Project: Geronimo Type: Bug Components: startup/shutdown, usability Versions: 1.0 Environment: Windows XP Reporter: John Sisson Assigned to: John Sisson Priority: Trivial Fix For: 1.1, 1.2 geronimo.bat does not use the JPDA_OPTS environment variable that geronimo.sh uses. geronimo.bat should be fixed so it is consistent with geronimo.sh. geronimo.sh allows you to set the JPDA_OPTS environment variable that overrides the use of the other JPDA_* environment variables. If JPDA_OPTS is not set the JPDA command line options are contructed from the JPDA_ADDRESS, JPDA_SUSPEND and JPDA_TRANSPORT environment variables. To assist troubleshooting starting geronimo under the JPDA debugger, the environment variable information printed by the scripts should also output the value of JPDA_OPTS so users can see the JPDA options (e.g. JPDA address, whether suspend is set to yes etc) if the user has passed the jpda argument to the scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1714) Module migration to Maven2: connector-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1714?page=comments#action_12370612 ] Jacek Laskowski commented on GERONIMO-1714: --- Committed revision 386222. Thanks Prasad! Additional comments: * Use 'svn diff' only - zip's are a little pain when patching * Don't forget about ASL 2.0 in every committed file Module migration to Maven2: connector-builder - Key: GERONIMO-1714 URL: http://issues.apache.org/jira/browse/GERONIMO-1714 Project: Geronimo Type: Sub-task Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Prasad Kashyap Attachments: connector-builder-apply-me.patch, connector-builder.patch, test-setup.zip -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: ActiveMQ Graduation From Incubator
James Strachan wrote: What other issues are there? A number of infrastucture issues. Votes from the Incubator PMC and Geronimo PMC. To do that responsibly, I'd say that we would want to see communities having demonstrated that they understand how to practice as an ASF community. Such things are subjective, and typically have taken some time. Looking at the historical record: Derby took a year; Nutch took 5 months; JaxME and jUDDI took 6 months; JDO took 7 months. Those are just a few projects that have graduated to another TLP, and every community is different, but ActiveMQ and ServiceMix haven't been in the Incubator for 3 months, and are still moving over their infrastructure. Anyone see a need to rush to judgment? --- Noel
[jira] Updated: (GERONIMO-1672) Module migration to Maven2: security
[ http://issues.apache.org/jira/browse/GERONIMO-1672?page=all ] Jacek Laskowski updated GERONIMO-1672: -- Summary: Module migration to Maven2: security (was: Migrate security module to M2) Module migration to Maven2: security - Key: GERONIMO-1672 URL: http://issues.apache.org/jira/browse/GERONIMO-1672 Project: Geronimo Type: Task Components: security Versions: 1.x Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Fix For: 1.x Attachments: m2-log4j.patch, pom.patch, pom.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: ActiveMQ Graduation From Incubator
Henri Yandell wrote: Justin Erenkrantz wrote: The APR spin-off from HTTP Server was probably the first federation (although it wasn't called that). HTTP Server depends upon APR and they have a large committer and PMCer overlap (but not total), but from the Foundation/Board's perspective - they are independent TLPs and are treated as such. The same technical arguments seem to be made for ActiveMQ and ServiceMix in their dependency relationship with Geronimo. -- justin Right. I would suggest having individual TLPs, individual mailing lists, and individual websites, but with a lot of cross-linking, Something in that realm, sure. I am sure that there are a variety of ways to structure Federation. People are still exploring them. We also talked about how ontology might be addressed to support cross-project discussion. And the work that Dave Co are doing with projects.apache.org can help. --- Noel
Re: ActiveMQ Graduation From Incubator
If you ask me what my opinion on OpenEJB's future or James' opinion on ActiveMQ's future, we'll both probably tell you TLP is a good goal eventually. We've more or less been running as TLPs in relation to Geronimo for the past two plus years already, just at Codehaus. We've seen how that plays out and we'd like to try a much more unified front for a while and see what shakes out. We're all ready for a change in the status-quo. The Geronimo world is awkward and unbalanced. We have too tight integration with OpenEJB such that the standalone version of that completely disappeared. We have too little integration with ActiveMQ such that the things you can do with standalone ActiveMQ you can't do with the Geronimo ActiveMQ. We have parts of Geronimo which could very well become separately reusable components, like the transaction manager or the XBean code. We're aren't successfully leveraging each other's communities to the fullest. All in all, we don't make decisions together and lean on each other as much as we could. I'd really like to see all our projects rolled up, balanced out, then split up again along possibly different lines with potentially more standalone pieces than we see now. TLP is a good goal, but I really see value in the journey. -David
[jira] Closed: (GERONIMO-894) Need exhaustive list of jelly usage
[ http://issues.apache.org/jira/browse/GERONIMO-894?page=all ] Jacek Laskowski closed GERONIMO-894: Need exhaustive list of jelly usage --- Key: GERONIMO-894 URL: http://issues.apache.org/jira/browse/GERONIMO-894 Project: Geronimo Type: Sub-task Components: buildsystem Versions: 1.0-M4 Reporter: Alan Cabrera Fix For: 1.x We need exhaustive list of jelly usage. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1696) JPDA run command not listed in usage help for geronimo.sh and geronimo.bat
[ http://issues.apache.org/jira/browse/GERONIMO-1696?page=all ] John Sisson closed GERONIMO-1696: - Resolution: Fixed JPDA run command not listed in usage help for geronimo.sh and geronimo.bat -- Key: GERONIMO-1696 URL: http://issues.apache.org/jira/browse/GERONIMO-1696 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Trivial Fix For: 1.1, 1.2 If you run geronimo.sh or geronimo.bat without any arguments, usage information is listed showing the jpda start command, but not showing the jpda run command. The jpda run command should also be listed in the usage help as running geronimo in the foreground whilst debugging is probably a common requirement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1744) dt_shmem default in geronimo.bat for JPDA_TRANSPORT environment variable not compatible with Eclipse debugger
[ http://issues.apache.org/jira/browse/GERONIMO-1744?page=all ] John Sisson closed GERONIMO-1744: - Resolution: Fixed dt_shmem default in geronimo.bat for JPDA_TRANSPORT environment variable not compatible with Eclipse debugger --- Key: GERONIMO-1744 URL: http://issues.apache.org/jira/browse/GERONIMO-1744 Project: Geronimo Type: Bug Components: startup/shutdown, usability Versions: 1.0 Environment: Windows XP Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.1, 1.2 Eclipse users cannot connect the Eclipse debugger to the JVM if you start Geronimo using the command geronimo.bat jpda run because the JPDA_TRANSPORT environment variable defaults to dt_shmem in the Geronimo.bat file and Eclipse only supports dt_socket and has no plans to support dt_shmem ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=1666 ). The default for JPDA_TRANSPORT in heronimo.bat should be changed to dt_socket so the default is usable by all debuggers and is consistent with the default in geronimo.sh -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1745) The JPDA_OPTS environment variable is not honoured by geronimo.bat and is inconsistent with geronimo.sh
[ http://issues.apache.org/jira/browse/GERONIMO-1745?page=all ] John Sisson closed GERONIMO-1745: - Resolution: Fixed The JPDA_OPTS environment variable is not honoured by geronimo.bat and is inconsistent with geronimo.sh --- Key: GERONIMO-1745 URL: http://issues.apache.org/jira/browse/GERONIMO-1745 Project: Geronimo Type: Bug Components: startup/shutdown, usability Versions: 1.0 Environment: Windows XP Reporter: John Sisson Assignee: John Sisson Priority: Trivial Fix For: 1.1, 1.2 geronimo.bat does not use the JPDA_OPTS environment variable that geronimo.sh uses. geronimo.bat should be fixed so it is consistent with geronimo.sh. geronimo.sh allows you to set the JPDA_OPTS environment variable that overrides the use of the other JPDA_* environment variables. If JPDA_OPTS is not set the JPDA command line options are contructed from the JPDA_ADDRESS, JPDA_SUSPEND and JPDA_TRANSPORT environment variables. To assist troubleshooting starting geronimo under the JPDA debugger, the environment variable information printed by the scripts should also output the value of JPDA_OPTS so users can see the JPDA options (e.g. JPDA address, whether suspend is set to yes etc) if the user has passed the jpda argument to the scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: ActiveMQ Graduation From Incubator
Alan D. Cabrera wrote: I only see infrastructure issues in your list of concerns that would prevent the graduation of ActiveMQ. Look again, but also at comments from Dims, Henri and others. You express an opinion that it should be a TLP but mention that it has a long way to go before it's ready for that. Can you enumerate what remains, aside from the infrastructure issues See my reply to Dain. And I do feel that some of it does come down to being able to convey a subjective confidence to the Incubator PMC that the community really does get it regarding ASF principles and practices. And that is supposed to happen before, not after, a community leaves the Incubator. If AMQ has less inspiring aspirations and was to initially land as a sub-project I am not sure how much difference there ought to be, but some of that comes down to the landing PMC. I do have a concern an issue of fairness. Consider David Blevin's well-stated views, including We've more or less been running as TLPs [for] the past two plus years already. So if we have some community that has been autonomous, and it becomes part of another TLP within the ASF, how fair would it be for the members of that community to lose their decision making ability? I would say not, so are they going to be made part of the destination PMC, which would be required for them to have binding votes? This is a generic issue. I would have to cross-reference in detail the PMC and committer lists for ActiveMQ and Geronimo to be specific to this case. I do realize that there is overlap, but also others who are part of ActiveMQ and are not part of Geronimo. Is Geronimo prepared to welcome them as Committers on the Geronimo TLP and members of the Geronimo PMC? Related comment will go as a reply to David Blevins. --- Noel
[jira] Closed: (GERONIMO-609) geronimo.log can be closed whilst distributing an EAR if the application uses log4j
[ http://issues.apache.org/jira/browse/GERONIMO-609?page=all ] John Sisson closed GERONIMO-609: Fix Version: 1.1 (was: 1.2) Resolution: Won't Fix This problem can be avoided by using the following in an application's deployment plan: hidden-classes filterorg.apache.log4j/filter /hidden-classes So the application can use its own instance of log4j. geronimo.log can be closed whilst distributing an EAR if the application uses log4j --- Key: GERONIMO-609 URL: http://issues.apache.org/jira/browse/GERONIMO-609 Project: Geronimo Type: Bug Components: deployment Reporter: John Sisson Assignee: John Sisson Fix For: 1.1 The following stack trace shows the geronimo.log file being closed as a result of static code being executed in a session bean whilst the configuration is being stored. The EAR has a geronimo-application.xml file that contains a dependencies element that adds log4j as a dependency, to ensure the application (when it initialises its logging) does not interfere with geronimo's logging. Well, that was the plan, but I wasn't expecting to see the application's code being executed without using the dependencies it was configured with. Here is the stack trace: System Thread [RMI TCP Connection(7)-172.21.35.170] (Suspended (breakpoint at line 171 in org.apache.log4j.FileAppender)) org.apache.log4j.RollingFileAppender(org.apache.log4j.FileAppender).closeFile() line: 171 org.apache.log4j.RollingFileAppender(org.apache.log4j.FileAppender).reset() line: 302 org.apache.log4j.RollingFileAppender(org.apache.log4j.WriterAppender).close() line: 195 org.apache.log4j.helpers.AppenderAttachableImpl.removeAllAppenders() line: 132 org.apache.log4j.spi.RootCategory(org.apache.log4j.Category).removeAllAppenders() line: 879 org.apache.log4j.PropertyConfigurator.parseCategory(java.util.Properties, org.apache.log4j.Logger, java.lang.String, java.lang.String, java.lang.String) line: 594 org.apache.log4j.PropertyConfigurator.configureRootCategory(java.util.Properties, org.apache.log4j.spi.LoggerRepository) line: 500 org.apache.log4j.PropertyConfigurator.doConfigure(java.util.Properties, org.apache.log4j.spi.LoggerRepository) line: 406 org.apache.log4j.PropertyConfigurator.configure(java.util.Properties) line: 340 snip - application code com.blah.server.ejb.ServerConfigPvtBean.clinit() line: 93 java.io.ObjectStreamClass.hasStaticInitializer(java.lang.Class) line: not available [native method] java.io.ObjectStreamClass.computeDefaultSUID(java.lang.Class) line: 1557 java.io.ObjectStreamClass.access$100(java.lang.Class) line: 47 java.io.ObjectStreamClass$1.run() line: 173 java.security.AccessController.doPrivileged(java.security.PrivilegedAction) line: not available [native method] java.io.ObjectStreamClass.getSerialVersionUID() line: 170 java.io.ObjectStreamClass.writeNonProxy(java.io.ObjectOutputStream) line: 557 java.io.ObjectOutputStream.writeClassDescriptor(java.io.ObjectStreamClass) line: 591 java.io.ObjectOutputStream.writeNonProxyDesc(java.io.ObjectStreamClass, boolean) line: 1142 java.io.ObjectOutputStream.writeClassDesc(java.io.ObjectStreamClass, boolean) line: 1100 java.io.ObjectOutputStream.writeClass(java.lang.Class, boolean) line: 1082 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 996 java.io.ObjectOutputStream.defaultWriteFields(java.lang.Object, java.io.ObjectStreamClass) line: 1332 java.io.ObjectOutputStream.writeSerialData(java.lang.Object, java.io.ObjectStreamClass) line: 1304 java.io.ObjectOutputStream.writeOrdinaryObject(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1247 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1052 java.io.ObjectOutputStream.writeArray(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1224 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1050 java.io.ObjectOutputStream.defaultWriteFields(java.lang.Object, java.io.ObjectStreamClass) line: 1332 java.io.ObjectOutputStream.writeSerialData(java.lang.Object, java.io.ObjectStreamClass) line: 1304 java.io.ObjectOutputStream.writeOrdinaryObject(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1247 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1052 java.io.ObjectOutputStream.writeObject(java.lang.Object) line: 278 org.apache.geronimo.gbean.GBeanData.writeExternal(java.io.ObjectOutput) line: 132
RE: ActiveMQ Graduation From Incubator
David Blevins wrote: Lots of good stuff, thanks. :-) If you ask me what my opinion on OpenEJB's future or James' opinion on ActiveMQ's future, we'll both probably tell you TLP is a good goal eventually. We've more or less been running as TLPs in relation to Geronimo for the past two plus years already, just at Codehaus. We've seen how that plays out and we'd like to try a much more unified front for a while and see what shakes out. The Geronimo world is awkward and unbalanced. We have too tight integration with OpenEJB such that the standalone version of that completely disappeared [, and too little integration with ActiveMQ.] We're aren't successfully leveraging each other's communities to the fullest. All in all, we don't make decisions together and lean on each other as much as we could. How is merging the communities into the Geronimo TLP going to correct these problems? Is the Geronimo PMC prepared to add all of you as Committers on the TLP, and add all or most of you to the Geronimo PMC? Is this going to result in a single community, or more integrated, better, meeting place for multiple communities? If the latter, that would indicate to me that you really should be a TLP. See Henri's e-mails for a fuller discussion of Federation. And what about community growth? When TLPs have sub-projects, how do they go about building up each sub-project? How quick would the target PMC be to grant TLP karma and PMC status to people interested in working on just one of these disjoint projects? Or would it have disjoint karma, and a smaller number of people with binding votes? See Henri's and Robert's comments on these issues. I'd really like to see all our projects rolled up, balanced out, then split up again along possibly different lines with potentially more standalone pieces than we see now. So you see putting everything together in Geronimo as a first step towards a significant reorganization, with multiple TLPs? TLP is a good goal, but I really see value in the journey. So do I. The question appears to be where/how to take that journey. :-) --- Noel
Re: ActiveMQ Graduation From Incubator
Noel J. Bergman wrote: James Strachan wrote: What other issues are there? A number of infrastucture issues. Votes from the Incubator PMC and Geronimo PMC. To do that responsibly, I'd say that we would want to see communities having demonstrated that they understand how to practice as an ASF community. Such things are subjective, and typically have taken some time. Looking at the historical record: Derby took a year; Nutch took 5 months; JaxME and jUDDI took 6 months; JDO took 7 months. Those are just a few projects that have graduated to another TLP, and every community is different, but ActiveMQ and ServiceMix haven't been in the Incubator for 3 months, and are still moving over their infrastructure. Anyone see a need to rush to judgment? I don't see any rush here. Is it not a natural question to ask what else is left to do? Is there a compelling reason to keep this in the incubator if there is no real need other than historical precedence of previous podlings' matriculation? There were concrete reasons for the duration of their incubation. If they are the same issues as AMQ, then let's focus on those concrete issues. Regards, Alan
Re: ActiveMQ Graduation From Incubator
Noel J. Bergman wrote: Alan D. Cabrera wrote: I only see infrastructure issues in your list of concerns that would prevent the graduation of ActiveMQ. Look again, but also at comments from Dims, Henri and others. At the moment, only Dims has taken the time to enumerate a list of concerns. Henri and the others have provided well thought out points on the definition of umbrella projects and whether AMQ should be a TLP or subproject; these not really being impediments to graduation but the necessary discourse about the final disposition of AMQ when it graduates that I was looking for when I initially sent out my email. You express an opinion that it should be a TLP but mention that it has a long way to go before it's ready for that. Can you enumerate what remains, aside from the infrastructure issues See my reply to Dain. And I do feel that some of it does come down to being able to convey a subjective confidence to the Incubator PMC that the community really does "get it" regarding ASF principles and practices. And that is supposed to happen before, not after, a community leaves the Incubator. There are a number of definitions for the word "subjective". If subjective means that your concerns may be peculiar to yourself, can you not explicitly state what you'd like to see? If you are unable to communicate what those are, we may not unable to address them. Is that fair to the AMQ community? If AMQ has less inspiring aspirations and was to initially land as a sub-project I am not sure how much difference there ought to be, but some of that comes down to the landing PMC. I do have a concern an issue of fairness. Consider David Blevin's well-stated views, including "We've more or less been running as TLPs [for] the past two plus years already." So if we have some community that has been autonomous, and it becomes part of another TLP within the ASF, how fair would it be for the members of that community to lose their decision making ability? I would say not, so are they going to be made part of the destination PMC, which would be required for them to have binding votes? This is a generic issue. I would have to cross-reference in detail the PMC and committer lists for ActiveMQ and Geronimo to be specific to this case. I do realize that there is overlap, but also others who are part of ActiveMQ and are not part of Geronimo. Is Geronimo prepared to welcome them as Committers on the Geronimo TLP and members of the Geronimo PMC? Related comment will go as a reply to David Blevins. If I take away the list of infrastructure issues, I only see the need to have a thorough discussion as to where AMQ will land when it graduates. Once this settles down and we, hopefully, reach a consensus we will be ready to vote, imho. Regards, Alan
Re: svn commit: r386059 - in /geronimo/site: ./ docs/ docs/redirects/ lib/ wikimesh/activemq-site/ wikimesh/servicemix-site/ xdocs/ xdocs/redirects/ xdocs/stylesheets/
Jacek Laskowski wrote: 2006/3/15, [EMAIL PROTECTED] [EMAIL PROTECTED]: Author: jsisson Date: Wed Mar 15 03:53:51 2006 New Revision: 386059 ... Added: geronimo/site/lib/commons-collections-3.1.jar (with props) geronimo/site/lib/commons-lang-2.1.jar (with props) geronimo/site/lib/jdom-1.0.jar (with props) geronimo/site/lib/oro-2.0.8.jar (with props) geronimo/site/lib/werken-xpath-0.9.4.jar (with props) What are the jars for? It looks very weird in the age of Maven, doesn't it? ;) Jacek -- Jacek Laskowski http://www.laskowski.org.pl I was waiting for you to comment :-) Yes it is ugly and should be reworked to use Maven. Yesterday I discovered that the JIRA link on the geronimo web page was broken. I thought, oh, that will only take me 5 mins to fix... For some reason simple things always turn into something complicated.. When I went to check in the html files generated by velocity I found that they had both crlfs and lfs causing a checkin of the files to fail with an error saying the file has inconsistent line endings ( I am on Windows xp). After further digging there was a bug in velocity that was fixed in the current development version (we were using an old 1.5 dev version) that has some additional dependency requirements. So I updated the lib dir with the mandatory dependencies according the the dependencies doco in the velocity development version. I got some class not found exceptions before I added the dependencies, so some new ones have been introduced. Much time was spent chasing this and I didn't have the time to throw maven into the mix as well just to get a broken link on the site working :-) Regards, John
Re: m2 : security module
Anita, Do you still have problems with this module ? If so, can you please send the files you have thus far changed. Cheers Prasad On 3/15/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Comments inline --- Prasad Kashyap [EMAIL PROTECTED] wrote: The following line seems to be the culprit. gbean.setAttribute(baseDirectory, .); You may already have got the system property basedir and used it in the line above. M2 builds run the tests in the same jvm. So the following props set in an earlier BasicServerInfo object is left behind. org.apache.geronimo.home.dir org.apache.geronimo.server.dir. Are you also having problems running surefire-plugin with forkmode=once? Try to unset those too before you begin the test. Cheers Prasaf On 3/14/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Anita, The path doesn't look right. Where's the module name in that path ? D:\anita\geronimo\geronimo-1.1\.\src\test-data\data\users.properties Seems like user.dir property is being used instead of basedir. At first, I also thought that this path was the culprit. But the same path is used in maven1 build and the other m2 build and the properties file is found. The following appears on the console just before the java-io.FileNotFoundException. ERROR [Socket Connection: /127.0.0.1:4242 - /127.0.0.1:1580] Properties File Lo gin Module - data load failed java.io.FileNotFoundException Thnaks Anita Cheers Prasad On 3/14/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Hi, I am trying to debug a strange problem in security module (rev 385723). The module builds fine with maven1 build. It builds fine with m2 from 'security' directory. When I build from the top level directory using mvn -Dmodule=security clean test I get build failures. I have attached the report for ConfigurationEntryTest. The main cause of failures in three tests is : ERROR [main] Properties File Login Module - data load failed java.io.FileNotFoundException: D:\anita\geronimo\geronimo-1.1\.\src\test-data\data\users.properties (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at java.io.FileInputStream.init(FileInputStream.java:66) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.jav a:156) at java.net.URL.openStream(URL.java:913) any ideas? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-1725) Module migration to Maven 2: client-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1725?page=comments#action_12370632 ] Prasad Kashyap commented on GERONIMO-1725: -- The geronimo-dependency-plugin processes those dependencies that are tagged with the geronimo.dependency element. It writes those deps into the geronimo-service.xml file for runtime use by the config classloader. However, the future (use) of the geronimo-dependency-plugin is in question as described in http://issues.apache.org/jira/browse/GERONIMO-1677. As suggested there, we may have to commit the created geronimo-service.xml into svn for all such modules that uses the dependency-plugin. Module migration to Maven 2: client-builder --- Key: GERONIMO-1725 URL: http://issues.apache.org/jira/browse/GERONIMO-1725 Project: Geronimo Type: Sub-task Versions: 1.x Reporter: Jacek Laskowski Assignee: Prasad Kashyap Attachments: pom.xml It's a task to help keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: daytrader benchmark results
Maxim Berkultsev wrote: Hi Matt, thanks a lot for the reply. A few more questions... The Y-Axis represents transactions per second. What is this value - is it a general magnitude like time or is it related to the type of request which is under study, (i.e. number of JDBCRead transactions per second)? All the TPS metrics were gathered from the client. The goal was to get the server to 100% CPU utilization. Before your reply I suppose that Web Server Manager portlet was used to perform monitoring, please see the post http://www.mail-archive.com/dev@geronimo.apache.org/msg18979.html No, the results are based on external requests per second by the client. Not by the servlet mentioned in the article. So the question is - do you use any additional client application (not included in Daytrader), which provides workload for Geronimo? I use a load driver call WebSphere Studio Simulator. This is a tool that I have had setup on my test environment for some time. At some point I'd like to move to JMeter or some other load driver but I found the Java based load generators take too much compute resource so right now I'm using a C based one. Thank you. -- Best regards, Maxim Berkultsev, Intel Middleware Products Division Matt Hogstrom wrote: Hi Maxim, Comments inline... Maxim Berkultsev wrote: Hello all, I've looked through Daytrader workload results and analysis for Geronimo published at http://www-1.ibm.com/support/docview.wss?uid=swg27006724 For the bar diagrams, which show Geronimo and 'target' server indicators, immediate questions are: - what is the measure unit for values in Y-axis? The Y-Axis represents transactions per second. - how are the values for 'target' performance received? One problem with performance measurments is that they typically incite many people to claim victory or cry foul depending on the results. This is also complicated by the fact that many commercial products have a no benchmark publish clause in their licenses. In order to have something to compare Geronimo to as well as avoid the inevitable fallout of naming a comparison point I did a series of measurments on other Open Source and commercial AppServer products. I thook these results and created the competitive target metric. The competitive target metric is simply my estimation of a respectable performance measurement. Meaning, as we achieve that metric one should be happy with the results. Note that these numbers are pretty old. I have a new set of data that I've been saying will be out for a while. I guess its time to actually make that happen. So, for purposes of consumption I would wait a few days for the new report to surface. We'll post it on our site. Also, could someone clarify if the performance data was collected on a client or a server side? All the TPS metrics were gathered from the client. The goal was to get the server to 100% CPU utilization. Also, if you guys are willing we could use some of the newer Potomac 3.6Ghzchips:)
Re: ActiveMQ Graduation From Incubator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan D. Cabrera wrote: I don't see any rush here. I think your initial 'what do we need to work on in order to eventually graduate?' message got interpreted by some - -- probably myself included -- as a 'what are the last items to check off so we can graduate?' message. And from there emotions flared. Sorry to say, I think Dain's comment: I understand this concern and agree with the solution, but we should remember that AMQ entered the incubator before this was a rule, so I for one didn't think it appled to them, since they are so close to graduation. unluckily came at the perfect time to reinforce the wrong message. Is it not a natural question to ask what else is left to do? It absolutely is. Is there a compelling reason to keep this in the incubator if there is no real need other than historical precedence of previous podlings' matriculation? No. But that's the wrong question. 'Is there a real need to keep this in the incubator, and, if so, what is it?' - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBRBjiw5rNPMCpn3XdAQL6lQP+Pa7TWNs6BO57HAbSkeerPFS3k7ZRfqRV U/MyaPM2iiCaaXQaIhEBdJrXC/tlT3SKOOgJ9KzxZyfBJkC/9Vu77z35LgI+uIEq Dt+2/rQvU6EeENYiz0eN6RG1RhthHBfremhM1ONr/SMND35QaxZQQIAycm4zBS0h guuwMdwjxxY= =ZQYY -END PGP SIGNATURE-
[jira] Created: (GERONIMO-1746) Updates to Logger through Log Manager portlet under Console are not reflected in the server
Updates to Logger through Log Manager portlet under Console are not reflected in the server --- Key: GERONIMO-1746 URL: http://issues.apache.org/jira/browse/GERONIMO-1746 Project: Geronimo Type: Bug Components: console, Logging Versions: 1.0 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Fix For: 1.2 Changes made to the logger through Log Manager portlet are not reflected in the server. Through the admin console, I have changed the Config File from server-log4j.properties to a different file. The change is written to config.xml . Inspite of this new file name in config.xml, upon restart, the server still uses server-log4j.properties . Restarting the server after deleting server-log4j.properties logged the following error to console window. log4j:ERROR Could not read configuration file from URL [file:/C:/geronimo-1.0/va r/log/server-log4j.properties]. java.io.FileNotFoundException: C:\geronimo-1.0\var\log\server-log4j.properties ( The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(Unknown Source) at java.io.FileInputStream.init(Unknown Source) at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source) at sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown So urce) at java.net.URL.openStream(Unknown Source) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurato r.java:424) at org.apache.geronimo.system.logging.log4j.URLConfigurator.doConfigure( URLConfigurator.java:117) at org.apache.geronimo.system.logging.log4j.URLConfigurator.configure(UR LConfigurator.java:44) at org.apache.geronimo.system.logging.log4j.Log4jService.reconfigure(Log 4jService.java:518) at org.apache.geronimo.system.logging.log4j.Log4jService.doStart(Log4jSe rvice.java:561) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:537) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:208) at org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans( Configuration.java:315) at org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f 4b4a9b.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: 178) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: 173) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:286) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:82) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:404) log4j:ERROR Ignoring configuration file [file:/C:/geronimo-1.0/var/log/server-lo g4j.properties]. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
