Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
This should be fixed now plus some other things I've found (i.e. licenses). Jarek On 10/27/07, Donald Woods <[EMAIL PROTECTED]> wrote: > I believe there a couple samples still using > org.apache.geronimo.applications instead of the new > org.apache.geronimo.samples groupId > > -Donald > > Paul McMahan wrote: > > Jarek helped on GERONIMO-2784 by moving the samples from server/trunk to > > samples/trunk. Now I would like to deploy those samples to the ASF > > snapshot repo so they can still be downloaded/installed from Geronimo's > > plugin catalog.This notification starts a 3 day lazy consensus timer > > for the PMC before I will deploy the snapshots to their new location in > > the ASF snapshot repo.Up until now the samples have been voted on > > and deployed concurrently with the server.See the JIRA for details. > > https://issues.apache.org/jira/browse/GERONIMO-2784 > > > > Best wishes, > > Paul > > > >
Re: Icons in web console disappeared
Jacek, I believe this is due to the implementation of the plugable admin console in trunk, but you'd have to ask Paul for the specifics on that, as it's kind of his baby. -Erik On 10/27/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > > Hi, > > What happened to the nice-looking icons next to administration menus > in webconsole of 2.1-SNAPSHOT? They're in 2.0.2. > > Jacek > > -- > Jacek Laskowski > http://www.JacekLaskowski.pl > -- Erik B. Craig
Messages about Derby while undeploying JPA app with PostgreSQL datasource
Hi, While undeploying an app with JPA that's configured with PostgreSQL-based datasource (JTA mode) Geronimo spits the following: 23:53:12,515 INFO [JDBC] OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your o penjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 23:53:12,515 INFO [JDBC] Using dictionary class "org.apache.openjpa.jdbc.sql.DerbyDictionary" (Apache Derby 10.3.1.4 - (561794) ,Apache Derby Embedded JDBC Driver 10.3.1.4 - (561794)). Why is that? The app doesn't touch Derby at all. Its startup is clean as it should be: Geronimo startup complete 22:34:48,796 INFO [config] Configuring Service(id=Default Stateless Container, type=Container, provider-id=Default Stateless Container) 22:34:48,796 INFO [config] Configuring Service(id=Default Stateful Container, type=Container, provider-id=Default Stateful Container) 22:34:48,796 INFO [config] Configuring Service(id=Default BMP Container, type=Container, provider-id=Default BMP Container) 22:34:48,796 INFO [config] Configuring Service(id=Default CMP Container, type=Container, provider-id=Default CMP Container) 22:34:48,796 INFO [config] Configuring app: pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear 22:34:49,000 INFO [OpenEJB] Auto-deploying ejb TicketServiceBean: EjbDeployment(deployment-id=TicketServiceMDB.jar/TicketServiceBean) 22:34:49,406 INFO [config] Loaded Module: pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear 22:34:52,390 INFO [Enhance] You have enabled runtime enhancement, but have not specified the set of persistent classes. OpenJPA must look for metadata for every loaded class, which mi ght increase class load times significantly. 22:34:54,171 INFO [config] Configuring Service(id=Default MDB Container, type=Container, provider-id=Default MDB Container) 22:34:56,187 INFO [startup] Assembling app: c:\geronimo\var\temp\geronimo-deploymentUtil63712.jar 22:34:56,250 INFO [startup] Jndi(name=TicketServiceMDB.jar/TicketServiceBean) --> Ejb(deployment-id=TicketServiceMDB.jar/TicketServiceBean) 22:34:56,437 INFO [startup] Created Ejb(deployment-id=TicketServiceMDB.jar/TicketServiceBean, ejb-name=TicketServiceBean, container=jms-resources.jms-resources-javax.jms.MessageListene r) 22:34:56,437 INFO [startup] Deployed Application(path=c:\geronimo\var\temp\geronimo-deploymentUtil63712.jar) Upon running the app causes OpenJPA to print the following: 22:36:11,718 INFO [Runtime] Starting OpenJPA 1.0.0 22:36:11,812 INFO [JDBC] Using dictionary class "org.apache.openjpa.jdbc.sql.PostgresDictionary". and that's it, so all appears to be set up correctly. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Icons in web console disappeared
Hi, What happened to the nice-looking icons next to administration menus in webconsole of 2.1-SNAPSHOT? They're in 2.0.2. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
On Oct 27, 2007, at 6:56 AM, Donald Woods wrote: Paul McMahan wrote: On Oct 26, 2007, at 12:55 PM, David Jencks wrote: On Oct 26, 2007, at 9:34 AM, Paul McMahan wrote: This jetspeed integration is coming along nicely! Very promising work. Instead of introducing a MBE that automatically configures the webapp for jetspeed based on the presence of WEB-INF/portlet.xml can we look into allowing jetspeed to handle its own deployment via placement in its hot deploy directory? When a war is placed in that directory jetspeed processes the portlets internally and then handles deploying the war to the app server. i.e. the portal recognizes the WAR as a special kind of app and handles the extra deployment steps, not the application server. I think that what Prasad is doing is a better way :-) (which is why I suggested it). How would a portlet app plugin work with hot deploy? imho magic hot deploy directories are really out of line with the whole geronimo modularity philosophy and I would support removing the hot deploy functionality we have (well, I know that wont happen, but I'd still support it). I really didn't mean to focus on the issue of hot vs. cold deployment. I'm mainly wondering whether or not, in general, Geronimo should try to encapsulate or otherwise replace Jetspeed's deployment functionality. In addition to hot deploy, Jetspeed also provides a pretty complete maven plugin for managing the portal and deploying portlet applications. I bet it also provides some type of admin UI for deploying portlet applications. As a Jetspeed user I would expect the existing deployment mechanisms to all continue working in Geronimo. As a Geronimo developer I would like to take advantage of Jetspeed's deployment functionality as much as possible and avoid sensitivities to changes in their architecture going forward. Utilizing Jetspeed's hot deploy directory is only one idea for how to accomplish these goals, maybe not the best one. OTOH, using a MBE to subvert Jetspeed's normal deployment processes seems contrary to those goals. But maybe I am misunderstanding how you suggested to implement this. I was hoping that the pluto portlet app deployment would work in the same way with an MBE. While the portlet spec is pretty complete for application design there currently is no specification for deployment within a portal. In the absence of a spec Pluto implemented deployment in a pretty clever way that is heavily based on standard webapp deployment and therefore very portable across servlet containers without extra configuration. So an MBE for Pluto isn't necessarily required, but I can see where a MBE for translating portlet.xml entries into web.xml might be helpful (GERONIMO-3252). Meanwhile there is a Maven plugin for that. I have a hunch that trying reverse that paradigm or somehow wrapper the deployment responsibilities of jetspeed from within an MBE could prove to be confusing to jetspeed users, difficult to implement correctly, and very sensitive to the jetspeed version. And like Donald pointed out it would interfere with other portal apps that might be deployed in Geronimo like Liferay, uPortal, Pluto (the admin console), etc. I think we should look into selecting the portal to deploy to based on something in the geronimo plan if we really need to support multiple portals running at once. If we don't, building a portlet app into a plugin for a specific portal could be handled by specifying the desired portal MBE car in the plugin's pom. The admin console needs to be lightweight and portable so it is based on Pluto. The Jetspeed MBE (as currently designed) would interfere with the deployment of admin console extensions. Adding something to the Geronimo plan to activate the Jetspeed MBE instead of just looking for a WEB-INF/portlet.xml sounds like a reasonable solution. Let's pursue that approach. +1 as I see many situations where the Pluto Admin Console will still be used even when Jetspeed or Liferay are installed. I haven't looked into exactly how the admin console plugins get added to the admin console but if they are geronimo plugins they have already gone through the deployment process and there is no chance for the jetspeed MBE to see them as the deployment machinery is not activated at all when a plugin is installed. thanks david jencks -Donald Maybe it's unavoidable, but if possible I hope we can avoid creating plugins that are sensitive to the Portal vendor. e.g. for one portal app I hope we don't require four plugins: myapp-jetty-jetspeed myapp-jetty-pluto myapp-tomcat-jetspeed myapp-tomcat-pluto Best wishes, Paul
Re: TCK access
On Oct 27, 2007, at 5:13 AM, Kevan Miller wrote: On Oct 26, 2007, at 11:57 PM, Alan D. Cabrera wrote: I think that Geir has to ACK that the paperwork was completed. Has he done so? I don't see an ACK on our tck list. I recall that Tim had a lot of problems getting the NDA acked. Geir, Do you have an NDA on file for Jay McHugh? If not, what's the best way for him to get this to you? He may not be reading this list intently. I'll forward to the TCK list. Regards, Alan
[Notice] Creating branch of Devtools maven-plugins
The 1.0-SNAPSHOT code in devtools/maven-plugins/trunk was not released as part of the Eclipse Plugin 2.0.0 release (and is only used at build time), so I'm going to start the release process, as the J2G code depends on these files too. -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: Promoting GShell to a real subproject
Good explanation. +1 to making it a subproject. -Donald Kevan Miller wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan smime.p7s Description: S/MIME Cryptographic Signature
[jira] Closed: (GERONIMO-411) Add Hash Password Rewrite to File Realm
[
https://issues.apache.org/jira/browse/GERONIMO-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods closed GERONIMO-411.
-
Resolution: Fixed
Fix Version/s: (was: 2.0.x)
2.0.2
Resolved by GERONIMO-2925
> Add Hash Password Rewrite to File Realm
> ---
>
> Key: GERONIMO-411
> URL: https://issues.apache.org/jira/browse/GERONIMO-411
> Project: Geronimo
> Issue Type: Improvement
> Components: security
>Affects Versions: 1.0-M2, 1.2
>Reporter: Aaron Mulder
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.1, 2.0.2
>
> Attachments: properties-realm.patch
>
>
> It would be nice if the properties file realm could rewrite your properties
> file with hashed passwords when it reads it. We would need to be able to
> recognize hashed vs. unhashed entries and perhaps even different algorithms.
> Perhaps it could go like this:
> user1=plaintext
> user2=MD5{...}
> user3=SHA1{...}
> Anyway, the idea is that this could be a reasonably secure alternative, but
> you still wouldn't need to manually hash things to add or update entries --
> just put a plain text entry in and the next time the server reads the file it
> would hash it for you.
> I guess we'd need to synchronize on the hash operation to avoid threading
> problems if multiple apps or whatever use the same properties file, but it
> shouldn't be bad if we only rewrite the file if we find any plain text
> entries.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3560) SMTPTransport.isConnected() returns true after close() is called
[ https://issues.apache.org/jira/browse/GERONIMO-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3560. - Resolution: Fixed Completed: At revision: 589098 in javamail/trunk/geronimo-javamail_1.4. > SMTPTransport.isConnected() returns true after close() is called > > > Key: GERONIMO-3560 > URL: https://issues.apache.org/jira/browse/GERONIMO-3560 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: mail >Affects Versions: 2.0.2, 2.0.x, 2.1 >Reporter: Vamsavardhana Reddy >Assignee: Vamsavardhana Reddy > Fix For: 2.0.x, 2.1 > > > SMTPTransport.isConnected() returns true after close() is called. This is > because closeServerConnection() is closing the socket connection but not > setting the connection status to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
Paul McMahan wrote: On Oct 26, 2007, at 12:55 PM, David Jencks wrote: On Oct 26, 2007, at 9:34 AM, Paul McMahan wrote: This jetspeed integration is coming along nicely! Very promising work. Instead of introducing a MBE that automatically configures the webapp for jetspeed based on the presence of WEB-INF/portlet.xml can we look into allowing jetspeed to handle its own deployment via placement in its hot deploy directory? When a war is placed in that directory jetspeed processes the portlets internally and then handles deploying the war to the app server. i.e. the portal recognizes the WAR as a special kind of app and handles the extra deployment steps, not the application server. I think that what Prasad is doing is a better way :-) (which is why I suggested it). How would a portlet app plugin work with hot deploy? imho magic hot deploy directories are really out of line with the whole geronimo modularity philosophy and I would support removing the hot deploy functionality we have (well, I know that wont happen, but I'd still support it). I really didn't mean to focus on the issue of hot vs. cold deployment. I'm mainly wondering whether or not, in general, Geronimo should try to encapsulate or otherwise replace Jetspeed's deployment functionality. In addition to hot deploy, Jetspeed also provides a pretty complete maven plugin for managing the portal and deploying portlet applications. I bet it also provides some type of admin UI for deploying portlet applications. As a Jetspeed user I would expect the existing deployment mechanisms to all continue working in Geronimo. As a Geronimo developer I would like to take advantage of Jetspeed's deployment functionality as much as possible and avoid sensitivities to changes in their architecture going forward. Utilizing Jetspeed's hot deploy directory is only one idea for how to accomplish these goals, maybe not the best one. OTOH, using a MBE to subvert Jetspeed's normal deployment processes seems contrary to those goals. But maybe I am misunderstanding how you suggested to implement this. I was hoping that the pluto portlet app deployment would work in the same way with an MBE. While the portlet spec is pretty complete for application design there currently is no specification for deployment within a portal. In the absence of a spec Pluto implemented deployment in a pretty clever way that is heavily based on standard webapp deployment and therefore very portable across servlet containers without extra configuration. So an MBE for Pluto isn't necessarily required, but I can see where a MBE for translating portlet.xml entries into web.xml might be helpful (GERONIMO-3252). Meanwhile there is a Maven plugin for that. I have a hunch that trying reverse that paradigm or somehow wrapper the deployment responsibilities of jetspeed from within an MBE could prove to be confusing to jetspeed users, difficult to implement correctly, and very sensitive to the jetspeed version. And like Donald pointed out it would interfere with other portal apps that might be deployed in Geronimo like Liferay, uPortal, Pluto (the admin console), etc. I think we should look into selecting the portal to deploy to based on something in the geronimo plan if we really need to support multiple portals running at once. If we don't, building a portlet app into a plugin for a specific portal could be handled by specifying the desired portal MBE car in the plugin's pom. The admin console needs to be lightweight and portable so it is based on Pluto. The Jetspeed MBE (as currently designed) would interfere with the deployment of admin console extensions. Adding something to the Geronimo plan to activate the Jetspeed MBE instead of just looking for a WEB-INF/portlet.xml sounds like a reasonable solution. Let's pursue that approach. +1 as I see many situations where the Pluto Admin Console will still be used even when Jetspeed or Liferay are installed. -Donald Maybe it's unavoidable, but if possible I hope we can avoid creating plugins that are sensitive to the Portal vendor. e.g. for one portal app I hope we don't require four plugins: myapp-jetty-jetspeed myapp-jetty-pluto myapp-tomcat-jetspeed myapp-tomcat-pluto Best wishes, Paul smime.p7s Description: S/MIME Cryptographic Signature
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
I believe there a couple samples still using org.apache.geronimo.applications instead of the new org.apache.geronimo.samples groupId -Donald Paul McMahan wrote: Jarek helped on GERONIMO-2784 by moving the samples from server/trunk to samples/trunk. Now I would like to deploy those samples to the ASF snapshot repo so they can still be downloaded/installed from Geronimo's plugin catalog.This notification starts a 3 day lazy consensus timer for the PMC before I will deploy the snapshots to their new location in the ASF snapshot repo.Up until now the samples have been voted on and deployed concurrently with the server.See the JIRA for details. https://issues.apache.org/jira/browse/GERONIMO-2784 Best wishes, Paul smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r588726 - in /geronimo/samples/trunk/samples: jsp-examples/jsp-examples-jetty/src/plan/ jsp-examples/jsp-examples-tomcat/src/plan/ jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF
Shouldn't the groupId be org.apache.geronimo.samples instead of org.apache.geronimo.applications, to match the existing samples and directory name? -Donald [EMAIL PROTECTED] wrote: Author: gawor Date: Fri Oct 26 11:02:00 2007 New Revision: 588726 URL: http://svn.apache.org/viewvc?rev=588726&view=rev Log: more cleanup (updated module ids, and removed old plans) Removed: geronimo/samples/trunk/samples/jsp-examples/jsp-examples-jetty/src/plan/ geronimo/samples/trunk/samples/jsp-examples/jsp-examples-tomcat/src/plan/ geronimo/samples/trunk/samples/servlet-examples/servlet-examples-jetty/src/plan/ geronimo/samples/trunk/samples/servlet-examples/servlet-examples-tomcat/src/plan/ Modified: geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml Modified: geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml URL: http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml?rev=588726&r1=588725&r2=588726&view=diff == --- geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml (original) +++ geronimo/samples/trunk/samples/jsp-examples/jsp-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml Fri Oct 26 11:02:00 2007 @@ -23,8 +23,8 @@ - org.apache.geronimo.applications.examples - geronimo-jsp-examples + org.apache.geronimo.applications + jsp-examples-war 2.1-SNAPSHOT Modified: geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml URL: http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml?rev=588726&r1=588725&r2=588726&view=diff == --- geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml (original) +++ geronimo/samples/trunk/samples/ldap-sample-app/ldap-sample-app-war/src/main/webapp/WEB-INF/geronimo-web.xml Fri Oct 26 11:02:00 2007 @@ -20,9 +20,9 @@ http://geronimo.apache.org/xml/ns/j2ee/web-1.2";> - samples - LDAP_Sample - 1.2 + org.apache.geronimo.applications + ldap-sample-app-war + 2.1-SNAPSHOT /LDAP_Sample Modified: geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml URL: http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml?rev=588726&r1=588725&r2=588726&view=diff == --- geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml (original) +++ geronimo/samples/trunk/samples/servlet-examples/servlet-examples-war/src/main/webapp/WEB-INF/geronimo-web.xml Fri Oct 26 11:02:00 2007 @@ -23,8 +23,8 @@ - org.apache.geronimo.applications.examples - geronimo-servlet-examples + org.apache.geronimo.applications + servlet-examples-war 2.1-SNAPSHOT smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMO-3560) SMTPTransport.isConnected() returns true after close() is called
SMTPTransport.isConnected() returns true after close() is called Key: GERONIMO-3560 URL: https://issues.apache.org/jira/browse/GERONIMO-3560 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: mail Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 SMTPTransport.isConnected() returns true after close() is called. This is because closeServerConnection() is closing the socket connection but not setting the connection status to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: TCK access
On Oct 26, 2007, at 11:57 PM, Alan D. Cabrera wrote: I think that Geir has to ACK that the paperwork was completed. Has he done so? I don't see an ACK on our tck list. I recall that Tim had a lot of problems getting the NDA acked. Geir, Do you have an NDA on file for Jay McHugh? If not, what's the best way for him to get this to you? --kevan
[jira] Created: (GERONIMO-3559) assembly replaces rather than extends config.xml
assembly replaces rather than extends config.xml Key: GERONIMO-3559 URL: https://issues.apache.org/jira/browse/GERONIMO-3559 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: car-maven-plugin Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 Anita noticed that the assembly process is leaving out the stuff from the framework assembly config.xml when constructing e.g. geronimo-jetty-javaee config.xml. It's supposed to add stuff for the added plugins, not just start over. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Running Multiple Server Instances
Yup, there is some kind of bug in the assembly step. The config for these is present in the geronimo-framework config.xml and the assembly mechanism is supposed to extend this with the added plugins but it seems to be replacing it. I opened GERONIMO-3559. I assigned it to myself because otherwise I will forget to look at it but if anyone else wants to take a look please feel free. Many thanks for noticing this! david jencks On Oct 26, 2007, at 7:02 PM, Anita Kulshreshtha wrote: Sorry, for the keyboard malfunction.. --- Anita Kulshreshtha <[EMAIL PROTECTED]> wrote: Unless I have missed something, we have lost the convenience of running multiple instances of Geronimo by using a non zero PortOffset. This is because the generated config.xml does not carry the configurable attributes of rmi-namimg and j2ee-security. Adding these by hand is very cumbersome and error prone. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
