date:20060125

I want to add a field that marks bugs w/ a regression flag so that we 
can track tests that used to pass.  Currently people just exclude the 
tests or, worse, comment them out in the code.


Thoughts?


Regards,
Alan

Re: Poll: Resolve configId Versions for 1.0.1


On 1/24/2006 11:52 AM, Aaron Mulder wrote:


[X] Change all configIds to 1.0 even though it's the 1.0.1 release
[ ] Change all references to use no version and make that work
[ ] Something else (please explain)
 




Regards,
Alan

Maven reports build error on OpenEJB

2006-01-25 Thread Philip Mark DONAGHY

Geronimo build fails with this message when running, 'maven -o new -Dmaven.test.skip=true'  geronimo/openejb/modules/pkgen-builder/target/classes/schemaorg_apache_xmlbeans not found.  
		 Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez la version beta.

Re: v1.x Installer comments - Long

2006-01-25 Thread Matt Hogstrom




David Jencks wrote:





On Jan 25, 2006, at 2:48 PM, Joe Bohn wrote:



I agree with Dave on the issue of multiple containers.  We had many  
discussions on this list concerning the number of containers in an  
image.  The result was that we agreed to deliver 2 different  
assemblies rather than having multiple containers in one assembly.   
If that was the decision for the assemblies then I would think it  
makes sense to do the same in the installer.




+1 One container per instance will satisfy 99% of the users I suspect.

I also agree with Dave that we should revisit the issue of  presenting 
the list of components twice: once to include them in  the image and 
once to activate them in the runtime.  I doubt that  most users would 
understand this distinction when initially  installing Geronimo.  Most 
other packages consider the activation/ inactivation of components to 
be post-install setup and choose the  defaults that make the most 
sense.  In our case I would expect that  all components selected 
during install would be active by default.



I think that is what we have now.  I don't see why we shouldn't let  
people turn them off if they want to.


I think for now we should dump them all to disk and then allow them to assemble 
the user.  I don't think were sophisticated enough yet to help users understand 
the difference.  One can refer to them as options available for later 
configuration (disk bloat) and options for runtime configuration (memory bloat). 
  I'd leave it simple for now.




david jencks



Joe

Dave Colasurdo wrote:


Erik Daughtrey wrote:


Dave, Thanks for the comments...

I made comments below.  Would you create installer component  JIRAs 
for the items that make sense?



Yep.  BTW, has it been decided if the installer is a 1.0.1 or 1.1  item?


 On Thursday 19 January 2006 17:02, Dave Colasurdo wrote:

Looks like the Installer has made quite a bit of progress.   Thanks 
Erik!!


I'd like to suggest a few Usabality changes to the current  
installer..
I'm sure you are already aware of many of these and have plans  to 
update
them.  Just wanted to provide some input based on my first  
impression.

BTW, I've attempted to provide input based on my thoughts on how  this
would be perceived from the perspective of a first time user.

*Package Selection Panel*
1)The available selections are really a hierarchy
  -Server
  --J2EE Features
  ---Jetty Web Container
  Jetty Sample Applications

  ---Tomcat Web Container
  Tomcat Sample Applications


Does Izpack allow you to capture the hierarchy graphically?



Not that I've seen.  It looks like it's strictly a list box.


If not, anyway to insert padding to the front of entries to show  the
hierarchy to the user?  I think this would be a better solution  
than the



Inserting spaces is something worth trying.


I experimented with inserting spaces in front of the pack names  and it
seemed to work fine. As expected, this also requires that all  
references
to the pack name in geronimo-izpack.xml, izpack-process.xml and  
izpack-user-input.xml need to be updated.  This results in a panel  
that seems to show the hierarchy visually.  Though adding the  spaces 
for each element in the xml files is a real hack and does  seem 
troublesome. There should be an easier way to accomplish this  
without  unnaturally padding or creating a custom panel.  I'll  post 
a question on this subject on the izpack mailing list.



"Dependencies" box and would more clearly convey the relationship
between selections.  Also, we should remove the dependencies box  
and the



I don't think it's possible to remove the dependencies box and  keep 
the overall look and feel.


Will also post this on the izpack mailing list.  Are they  responsive to
suggestions?

other righthand box that contains the Logo.  The description box  
should



I agree that the 2nd graphic is redundant at this point.   However, 
one thing we have not explored is the fact that the  graphic on the 
right is actually different for each pack although  for now each is 
a distinct instance of the same bitmap.  There is  the potential to 
enhance each bitmap - possibly by making the  Geronimo image subdued 
while overlaying something related to the  pack.  I have not tried 
removing the graphic, but I don't think  it's possible to remove it 
and keep this look and feel.


be located directly to the right of the main selection box OR  
below it

on the left.



I doubt that this is easy to change.  We can look into making  some 
of these changes in more detail at some point.  Anything is  
actually possible depending on the capabilities of IzPack itself  
and how much we're willing to diverge the Geronimo installer from  
the IzPack codebase.  It may actually be possible to make some of  
the changes without changing IzPack, but based on what I know  right 
now, I don't think so.
We've already diverged from the IzPack codebase and we need to  
factor these changes into IzPack as w

Re: Licensing of some files included in the Geronimo IzPack installer assembly (included by the IzPack installer)

2006-01-25 Thread Matt Hogstrom

Great research John.  Do you think we should defer the installer to 1.1 given 
these issues?  It would certainly make a bigger splash I think.  Erik, thoughts?


Matt

John Sisson wrote:

Hi Erik,

There appears there are some issues with the licensing of some files in 
the installer JAR file for the upcoming Geronimo 1.0.1 release.


Although the IzPack installer itself is supposed to be under an ASF 2 
license, it appears that the generated Geronimo installer JAR contains 
some files that may not be under the ASF 2 license or compatible with 
the ASF 2 license.


There are two groups of files/libraries that are included that are 
potentially suspect:


1) A number of images are included in the installer JAR in the /img 
directory.  The IzPack installer history page ( 
http://www.izforge.com/izpack/index.php?page=history ) says that the 
3.5.0 version switched to the Crystal icons from KDE 3.2.  I found that 
some of the images in the installer jar binary match images (e.g. 
ascii.png and bookmark.png) from "Crystal SVG for Linux" download on 
http://www.everaldo.com/crystal.html .  Some images also looked the same 
but differed in a binary comparison (maybe I am comparing a different 
version of the icons).  A google of crystal icons reveals (from various 
discussions) that they are under a LGPL license.  So the use of the 
icons is not suitable in ASF projects.


This issue should probably be raised with the IzPack project.  It may 
take a while for the IzPack project or ourselves to obtain images from 
another source that are suitable replacements.


2) Liquid look and feel files under the package com\birosoft\liquid . 
The liquidlnf project's page displays a LGPL license ( 
https://liquidlnf.dev.java.net/ ).
Removing the following lines from the geronimo-izpack.xml file prevented 
the liquid files being included.

 

  Therefore the liquid LGPL issue appears to be solvable.

The removal of the laf configuration the geronimo-izpack.xml file does 
not affect the images that are in the jar under the /img directory.



FYI: Henry Yandell confirmed that the NanoXML files in the installer JAR 
under the package net\n3\nanoxml under a zlib/libpng License are 
compatible with the ASF 2 license. ( 
http://nanoxml.cyberelf.be/download.html ).


Regards,

John

[jira] Updated: (GERONIMO-1503) keystore generated by KeyStore portlet could not be used to add either Jetty or Tomcat HTTPS Listeners

 [ http://issues.apache.org/jira/browse/GERONIMO-1503?page=all ]

Aaron Mulder updated GERONIMO-1503:
---

Component: security
   Tomcat
   web
  Version: (was: 1.0-M5)
   (was: 1.0.1)
   (was: 1.1)

> keystore generated by KeyStore portlet could not be used to add either Jetty 
> or Tomcat HTTPS Listeners
> --
>
>  Key: GERONIMO-1503
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1503
>  Project: Geronimo
> Type: Bug
>   Components: console, security, Tomcat, web
> Versions: 1.0
>  Environment: WinXP, Sun JDK 1.4.2_08
> Reporter: Vamsavardhana Reddy
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1503.patch
>
> ssl-keystore-1 generated by KeyStore portlet could not be used to add either 
> Jetty or Tomcat HTTPS Listeners.  Steps to regenerate this error.
> 1. Start Geronimo server
> 2. Using KeyStore portlet in Geronimo Console, generate keypair.  
> ("ssl-keystore-1" file is created in this step)
> 3. Using WebServers portlet, add a new HTTPS Listener.  Enter 
> "var/security/ssl-keystore-1" in the keystore field in this step.
> The new HTTPS Listener fails to start.
> The following exception is logged when attempting to add a Jetty HTTPS 
> Listener.
> 21:20:05,942 WARN  [SslListener] EXCEPTION
> java.security.UnrecoverableKeyException: Cannot recover key
> at sun.security.provider.KeyProtector.recover(KeyProtector.java:301)
> at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:120)
> at java.security.KeyStore.getKey(KeyStore.java:289)
> at com.sun.net.ssl.internal.ssl.X509KeyManagerImpl.(DashoA12275)
> at 
> com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl.engineInit(DashoA12275)
> at javax.net.ssl.KeyManagerFactory.init(DashoA12275)
> at org.mortbay.http.SslListener.createFactory(SslListener.java:262)
> at org.mortbay.http.SslListener.newServerSocket(SslListener.java:283)
> at org.mortbay.util.ThreadedServer.open(ThreadedServer.java:477)
> at 
> org.apache.geronimo.jetty.connector.JettyConnector.doStart(JettyConnector.java:233)
> at 
> org.apache.geronimo.jetty.connector.HTTPSConnector.doStart(HTTPSConnector.java:128)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.jetty.JettyWebConnector$$EnhancerByCGLIB$$e76cef7.startRecursive()
> at 
> org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:143)
> at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
> at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at 
> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
> at 
> org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
> at 
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
> at org.apache.pluto.port

[jira] Commented: (GERONIMO-1503) keystore generated by KeyStore portlet could not be used to add either Jetty or Tomcat HTTPS Listeners

[ 
http://issues.apache.org/jira/browse/GERONIMO-1503?page=comments#action_12364036
 ] 

Aaron Mulder commented on GERONIMO-1503:


Does this patch fix the Jetty problem that if an empty String is specified it 
is treated as null (and presumably does not work)?  Also, is there a change 
needed to the Keystore portlet to use the new GBean parameter?  Bottom line, 
after applying the patch, can the keystore generated by the portlet be used by 
both Tomcat and Jetty HTTPS connectors?  Thanks.

> keystore generated by KeyStore portlet could not be used to add either Jetty 
> or Tomcat HTTPS Listeners
> --
>
>  Key: GERONIMO-1503
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1503
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0, 1.0-M5, 1.0.1, 1.1
>  Environment: WinXP, Sun JDK 1.4.2_08
> Reporter: Vamsavardhana Reddy
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1503.patch
>
> ssl-keystore-1 generated by KeyStore portlet could not be used to add either 
> Jetty or Tomcat HTTPS Listeners.  Steps to regenerate this error.
> 1. Start Geronimo server
> 2. Using KeyStore portlet in Geronimo Console, generate keypair.  
> ("ssl-keystore-1" file is created in this step)
> 3. Using WebServers portlet, add a new HTTPS Listener.  Enter 
> "var/security/ssl-keystore-1" in the keystore field in this step.
> The new HTTPS Listener fails to start.
> The following exception is logged when attempting to add a Jetty HTTPS 
> Listener.
> 21:20:05,942 WARN  [SslListener] EXCEPTION
> java.security.UnrecoverableKeyException: Cannot recover key
> at sun.security.provider.KeyProtector.recover(KeyProtector.java:301)
> at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:120)
> at java.security.KeyStore.getKey(KeyStore.java:289)
> at com.sun.net.ssl.internal.ssl.X509KeyManagerImpl.(DashoA12275)
> at 
> com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl.engineInit(DashoA12275)
> at javax.net.ssl.KeyManagerFactory.init(DashoA12275)
> at org.mortbay.http.SslListener.createFactory(SslListener.java:262)
> at org.mortbay.http.SslListener.newServerSocket(SslListener.java:283)
> at org.mortbay.util.ThreadedServer.open(ThreadedServer.java:477)
> at 
> org.apache.geronimo.jetty.connector.JettyConnector.doStart(JettyConnector.java:233)
> at 
> org.apache.geronimo.jetty.connector.HTTPSConnector.doStart(HTTPSConnector.java:128)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.jetty.JettyWebConnector$$EnhancerByCGLIB$$e76cef7.startRecursive()
> at 
> org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:143)
> at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
> at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at 
> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
> at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
> at 
> org.apache.pluto.P

Licensing of some files included in the Geronimo IzPack installer assembly (included by the IzPack installer)

2006-01-25 Thread John Sisson


Hi Erik,

There appears there are some issues with the licensing of some files in 
the installer JAR file for the upcoming Geronimo 1.0.1 release.


Although the IzPack installer itself is supposed to be under an ASF 2 
license, it appears that the generated Geronimo installer JAR contains 
some files that may not be under the ASF 2 license or compatible with 
the ASF 2 license.


There are two groups of files/libraries that are included that are 
potentially suspect:


1) A number of images are included in the installer JAR in the /img 
directory.  The IzPack installer history page ( 
http://www.izforge.com/izpack/index.php?page=history ) says that the 
3.5.0 version switched to the Crystal icons from KDE 3.2.  I found that 
some of the images in the installer jar binary match images (e.g. 
ascii.png and bookmark.png) from "Crystal SVG for Linux" download on 
http://www.everaldo.com/crystal.html .  Some images also looked the same 
but differed in a binary comparison (maybe I am comparing a different 
version of the icons).  A google of crystal icons reveals (from various 
discussions) that they are under a LGPL license.  So the use of the 
icons is not suitable in ASF projects.


This issue should probably be raised with the IzPack project.  It may 
take a while for the IzPack project or ourselves to obtain images from 
another source that are suitable replacements.


2) Liquid look and feel files under the package com\birosoft\liquid . 
The liquidlnf project's page displays a LGPL license ( 
https://liquidlnf.dev.java.net/ ).
Removing the following lines from the geronimo-izpack.xml file prevented 
the liquid files being included.

 

  Therefore the liquid LGPL issue appears to be solvable.

The removal of the laf configuration the geronimo-izpack.xml file does 
not affect the images that are in the jar under the /img directory.



FYI: Henry Yandell confirmed that the NanoXML files in the installer JAR 
under the package net\n3\nanoxml under a zlib/libpng License are 
compatible with the ASF 2 license. ( 
http://nanoxml.cyberelf.be/download.html ).


Regards,

John

[jira] Resolved: (GERONIMO-1468) FileSystemRepository#listUris() produces wrong URI array when the repository contains a malformed entry

 [ http://issues.apache.org/jira/browse/GERONIMO-1468?page=all ]
 
Aaron Mulder resolved GERONIMO-1468:


Resolution: Fixed
 Assign To: Aaron Mulder

> FileSystemRepository#listUris() produces wrong URI array when the repository 
> contains a malformed entry
> ---
>
>  Key: GERONIMO-1468
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1468
>  Project: Geronimo
> Type: Bug
>   Components: console, core
> Versions: 1.0
> Reporter: Kristian Koehler
> Assignee: Aaron Mulder
>  Fix For: 1.0.1, 1.1
>  Attachments: FileSystemRepository.patch
>
> Hi
> if the local repository under /repository contains files with 
> malformed filenames the method listURIs returns a wrong array which crashes 
> the AdminConsole with a NPE. This happens when in several places (e.g. Common 
> Libraries, Database Pools).
> The attached patch fixes this issue.
> Kristian

-- 
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] Updated: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally

2006-01-25 Thread anita kulshreshtha (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1035?page=all ]

anita kulshreshtha updated GERONIMO-1035:
-

Attachment: tomcat-builder.patch

Added webservice servlet Gbeans

> tomcat integration should wrap each servlet indiviudally
> 
>
>  Key: GERONIMO-1035
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1035
>  Project: Geronimo
> Type: New Feature
>   Components: Tomcat
> Versions: 1.0-M5
>  Environment: All
> Reporter: anita kulshreshtha
> Assignee: Jeff Genender
>  Fix For: 1.1
>  Attachments: geronimo-stats-1.1-SNAPSHOT.war, management.patch, stats.zip, 
> tomcat-builder.patch, tomcat-builder.patch, tomcat.patch
>
> TomcatModuleBuilder should wrap each servlet specified in the deployment 
> descriptor individually. This is needed by JSR-77 and for gathering tomcat 
> internal statistics.   

-- 
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: v1.x Installer comments - Long



On Jan 25, 2006, at 2:48 PM, Joe Bohn wrote:



I agree with Dave on the issue of multiple containers.  We had many  
discussions on this list concerning the number of containers in an  
image.  The result was that we agreed to deliver 2 different  
assemblies rather than having multiple containers in one assembly.   
If that was the decision for the assemblies then I would think it  
makes sense to do the same in the installer.


I also agree with Dave that we should revisit the issue of  
presenting the list of components twice: once to include them in  
the image and once to activate them in the runtime.  I doubt that  
most users would understand this distinction when initially  
installing Geronimo.  Most other packages consider the activation/ 
inactivation of components to be post-install setup and choose the  
defaults that make the most sense.  In our case I would expect that  
all components selected during install would be active by default.


I think that is what we have now.  I don't see why we shouldn't let  
people turn them off if they want to.


david jencks



Joe

Dave Colasurdo wrote:

Erik Daughtrey wrote:

Dave, Thanks for the comments...

I made comments below.  Would you create installer component  
JIRAs for the items that make sense?


Yep.  BTW, has it been decided if the installer is a 1.0.1 or 1.1  
item?

 On Thursday 19 January 2006 17:02, Dave Colasurdo wrote:

Looks like the Installer has made quite a bit of progress.   
Thanks Erik!!


I'd like to suggest a few Usabality changes to the current  
installer..
I'm sure you are already aware of many of these and have plans  
to update
them.  Just wanted to provide some input based on my first  
impression.
BTW, I've attempted to provide input based on my thoughts on how  
this

would be perceived from the perspective of a first time user.

*Package Selection Panel*
1)The available selections are really a hierarchy
  -Server
  --J2EE Features
  ---Jetty Web Container
  Jetty Sample Applications

  ---Tomcat Web Container
  Tomcat Sample Applications


Does Izpack allow you to capture the hierarchy graphically?


Not that I've seen.  It looks like it's strictly a list box.

If not, anyway to insert padding to the front of entries to show  
the
hierarchy to the user?  I think this would be a better solution  
than the


Inserting spaces is something worth trying.
I experimented with inserting spaces in front of the pack names  
and it
seemed to work fine. As expected, this also requires that all  
references
to the pack name in geronimo-izpack.xml, izpack-process.xml and  
izpack-user-input.xml need to be updated.  This results in a panel  
that seems to show the hierarchy visually.  Though adding the  
spaces for each element in the xml files is a real hack and does  
seem troublesome. There should be an easier way to accomplish this  
without  unnaturally padding or creating a custom panel.  I'll  
post a question on this subject on the izpack mailing list.

"Dependencies" box and would more clearly convey the relationship
between selections.  Also, we should remove the dependencies box  
and the


I don't think it's possible to remove the dependencies box and  
keep the overall look and feel.
Will also post this on the izpack mailing list.  Are they  
responsive to

suggestions?
other righthand box that contains the Logo.  The description box  
should


I agree that the 2nd graphic is redundant at this point.   
However, one thing we have not explored is the fact that the  
graphic on the right is actually different for each pack although  
for now each is a distinct instance of the same bitmap.  There is  
the potential to enhance each bitmap - possibly by making the  
Geronimo image subdued while overlaying something related to the  
pack.  I have not tried removing the graphic, but I don't think  
it's possible to remove it and keep this look and feel.


be located directly to the right of the main selection box OR  
below it

on the left.


I doubt that this is easy to change.  We can look into making  
some of these changes in more detail at some point.  Anything is  
actually possible depending on the capabilities of IzPack itself  
and how much we're willing to diverge the Geronimo installer from  
the IzPack codebase.  It may actually be possible to make some of  
the changes without changing IzPack, but based on what I know  
right now, I don't think so.
We've already diverged from the IzPack codebase and we need to  
factor these changes into IzPack as we move forward or we may run  
into problems related to these changes later as IzPack itself  
diverges.  I'm struggling a little with this at this point given  
that IzPack is a generalized installer and some of the changes  
made are specific to Geronimo.  I tried to keep the changes  
separated, but our requirements are reflected in code I wanted to  
keep generalized anyway. I don't want to boil the ocean, but I'd  
also like to minimize problems occurri

RE: Trouble building the Jetspeed2 Geronimo integration

2006-01-25 Thread Philip Mark DONAGHY

From what I can see the builder is null because the plan is null. Because the planFile is of type application-1.0 and not deployment-1.0.I am also seeking a jetspeed-geronimo-2.1-dev.jar that I don't see in the patch. Philip Mark DONAGHY <[EMAIL PROTECTED]> a écrit : I have encountered a problem while attempting to usethe patches submitted tohttps://issues.apache.org/jira/browse/JS2-444I'm using,Maven 1.1-beta-2Jetspeed2 Revision: 372190Geronimo Revision: 372191$ cd app-servers/geronimo$ maven multiproject:installThe build fails with the error,[echo] Running car:install forgeronimo-jetspeed-jetty76 [main] ERRORorg.apache.geronimo.plugin.packaging.PackageBuilder -org.apache.geronimo.common.DeploymentException: Cannotdeploy
the requested application module(planFile=/home/phil/20051223/opensource/svnProjects/jetspeed-2/app-servers/geronimo/jetty-config/target/plan/plan.xml,moduleFile=/home/phil/.maven/repository/org.apache.portals.jetspeed-2/ears/geronimo-jetspeed-2.1-dev.ear)org.apache.geronimo.common.DeploymentException: Cannotdeploy the requested application module(planFile=/home/phil/20051223/opensource/svnProjects/jetspeed-2/app-servers/geronimo/jetty-config/target/plan/plan.xml,moduleFile=/home/phil/.maven/repository/org.apache.portals.jetspeed-2/ears/geronimo-jetspeed-2.1-dev.ear)I have determined that the builder on line 235 ofo.a.g.deployment.Deployer is null. But I don't know why.___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et
l'international.Téléchargez sur http://fr.messenger.yahoo.com
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez la version beta.

[jira] Updated: (GERONIMO-1037) Clicking on "uninstall" link in Applications management pages deletes the configuration without any confirmation from user

 [ http://issues.apache.org/jira/browse/GERONIMO-1037?page=all ]

Aaron Mulder updated GERONIMO-1037:
---

Assign To: (was: Matt Hogstrom)

> Clicking on "uninstall" link in Applications management pages deletes the 
> configuration without any confirmation from user
> --
>
>  Key: GERONIMO-1037
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1037
>  Project: Geronimo
> Type: Improvement
>   Components: console
> Versions: 1.0-M5
> Reporter: Vamsavardhana Reddy
> Priority: Trivial
>  Fix For: 1.1
>  Attachments: fix.txt, jmsserver.patch, normal.jsp
>
> Clicking on uninstall link in Applications Management pages deletes the 
> configuration without giving a second chance to the user to confirm or cancel 
> the uninstall operation.  Asking for user confirmation will definitely 
> prevent accidental uninstallation of  wrong configuration.  This can be 
> achieved by handling the onClick event of the corresponding link.
> File to be updated:
>  
> applications/console-standard/src/webapp/WEB-INF/view/configmanager/normal.jsp
> Add onClick="return confirm('Are you sure you want to uninstall 
> ${configInfo.configID}?');" to the the link conrresponsding to "Uninstall" 
> operation.

-- 
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: Trouble building the Jetspeed2 Geronimo integration

sorry, we added another configuration to geronimo yesterday and I  
haven't had a chance to update the JS2-444 patch.


I don't think the J2 part of the patch works after Randy's fix of  
JS2-473.  I updated my j2 patch but am having problems on tomcat.  It  
seems to work fine on jetty, but that won't help you much until I can  
update the patch.  Let me know if you want me to send it to you  
directly.


Anyway the missing part of the geronimo patch is thus:

=== jetty-config/project.properties
==
--- jetty-config/project.properties (revision 4948)
+++ jetty-config/project.properties (local)
@@ -21,7 +21,7 @@
maven.multiproject.type=car
-geronimo.packaging.deploymentConfig=geronimo/geronimo-gbean-deployer/ 
${geronimo_version}/car,geronimo/j2ee-deployer/${geronimo_version}/ 
car,geronimo/jetty-deployer/${geronimo_version}/car,geronimo/axis- 
deployer/${geronimo_version}/car,geronimo/openejb-deployer/$ 
{geronimo_version}/car,org.apache.portals.jetspeed-2/geronimo- 
jetspeed-security-builder-config/${pom.currentVersion}/car
+geronimo.packaging.deploymentConfig=geronimo/geronimo-gbean-deployer/ 
${geronimo_version}/car,geronimo/j2ee-deployer/${geronimo_version}/ 
car,geronimo/client-deployer/${geronimo_version}/car,geronimo/axis- 
deployer/${geronimo_version}/car,geronimo/openejb-deployer/$ 
{geronimo_version}/car,org.apache.portals.jetspeed-2/geronimo- 
jetspeed-security-builder-config/${pom.currentVersion}/car,geronimo/ 
jetty-deployer/${geronimo_version}/car
geronimo.packaging.moduleFile=${maven.repo.local}/ 
org.apache.portals.jetspeed-2/ears/geronimo-jetspeed-$ 
{pom.currentVersion}.ear

=== tomcat-config/project.properties
==
--- tomcat-config/project.properties(revision 4948)
+++ tomcat-config/project.properties(local)
@@ -21,7 +21,7 @@
maven.multiproject.type=car
-geronimo.packaging.deploymentConfig=geronimo/geronimo-gbean-deployer/ 
${geronimo_version}/car,geronimo/j2ee-deployer/${geronimo_version}/ 
car,geronimo/tomcat-deployer/${geronimo_version}/car,geronimo/axis- 
deployer/${geronimo_version}/car,geronimo/openejb-deployer/$ 
{geronimo_version}/car,org.apache.portals.jetspeed-2/geronimo- 
jetspeed-security-builder-config/${pom.currentVersion}/car
+geronimo.packaging.deploymentConfig=geronimo/geronimo-gbean-deployer/ 
${geronimo_version}/car,geronimo/j2ee-deployer/${geronimo_version}/ 
car,geronimo/tomcat-deployer/${geronimo_version}/car,geronimo/client- 
deployer/${geronimo_version}/car,geronimo/axis-deployer/$ 
{geronimo_version}/car,geronimo/openejb-deployer/${geronimo_version}/ 
car,org.apache.portals.jetspeed-2/geronimo-jetspeed-security-builder- 
config/${pom.currentVersion}/car,geronimo/tomcat-deployer/$ 
{geronimo_version}/car
geronimo.packaging.moduleFile=${maven.repo.local}/ 
org.apache.portals.jetspeed-2/ears/geronimo-jetspeed-$ 
{pom.currentVersion}.ear


thanks
david jencks


On Jan 25, 2006, at 2:06 PM, Philip Mark DONAGHY wrote:


I have encountered a problem while attempting to use
the patches submitted to
https://issues.apache.org/jira/browse/JS2-444

I'm using,
Maven 1.1-beta-2
Jetspeed2 Revision: 372190
Geronimo Revision: 372191

$ cd app-servers/geronimo
$ maven multiproject:install

The build fails with the error,

[echo] Running car:install for
geronimo-jetspeed-jetty
76 [main] ERROR
org.apache.geronimo.plugin.packaging.PackageBuilder  -
org.apache.geronimo.common.DeploymentException: Cannot
deploy the requested application module
(planFile=/home/phil/20051223/opensource/svnProjects/jetspeed-2/app- 
servers/geronimo/jetty-config/target/plan/plan.xml,
moduleFile=/home/phil/.maven/repository/ 
org.apache.portals.jetspeed-2/ears/geronimo-jetspeed-2.1-dev.ear)

org.apache.geronimo.common.DeploymentException: Cannot
deploy the requested application module
(planFile=/home/phil/20051223/opensource/svnProjects/jetspeed-2/app- 
servers/geronimo/jetty-config/target/plan/plan.xml,
moduleFile=/home/phil/.maven/repository/ 
org.apache.portals.jetspeed-2/ears/geronimo-jetspeed-2.1-dev.ear)


I have determined that the builder on line 235 of
o.a.g.deployment.Deployer is null. But I don't know why.








__ 
_
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez  
les tarifs exceptionnels pour appeler la France et l'international.

Téléchargez sur http://fr.messenger.yahoo.com

[jira] Updated: (GERONIMO-1037) Clicking on "uninstall" link in Applications management pages deletes the configuration without any confirmation from user

 [ http://issues.apache.org/jira/browse/GERONIMO-1037?page=all ]

Aaron Mulder updated GERONIMO-1037:
---

Fix Version: (was: 1.0.1)

Alan *is* the release manager!

> Clicking on "uninstall" link in Applications management pages deletes the 
> configuration without any confirmation from user
> --
>
>  Key: GERONIMO-1037
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1037
>  Project: Geronimo
> Type: Improvement
>   Components: console
> Versions: 1.0-M5
> Reporter: Vamsavardhana Reddy
> Assignee: Matt Hogstrom
> Priority: Trivial
>  Fix For: 1.1
>  Attachments: fix.txt, jmsserver.patch, normal.jsp
>
> Clicking on uninstall link in Applications Management pages deletes the 
> configuration without giving a second chance to the user to confirm or cancel 
> the uninstall operation.  Asking for user confirmation will definitely 
> prevent accidental uninstallation of  wrong configuration.  This can be 
> achieved by handling the onClick event of the corresponding link.
> File to be updated:
>  
> applications/console-standard/src/webapp/WEB-INF/view/configmanager/normal.jsp
> Add onClick="return confirm('Are you sure you want to uninstall 
> ${configInfo.configID}?');" to the the link conrresponsding to "Uninstall" 
> operation.

-- 
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-1542) Console portlets should validate all formatted values (numbers, etc.)

Console portlets should validate all formatted values (numbers, etc.)
-

 Key: GERONIMO-1542
 URL: http://issues.apache.org/jira/browse/GERONIMO-1542
 Project: Geronimo
Type: Bug
  Components: console  
Versions: 1.0
Reporter: Aaron Mulder
 Fix For: 1.x


Right now the "new" console portlets don't really have any good validation 
mechanism.  The JMS portlet is better than average in this regard in that it 
can send you back to the previous page if it notices an error on submit (and it 
uses this in a couple places to check for required values), but even then 
there's no standard way to render error messages for the page or for individual 
fields.

Ideally we might find a good portlet web framework to use that supports 
validation, but in the mean time, we should think about finding some 
general-purpose solution for the console portlets.

-- 
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-1336) Setting the Max PoolSize on a DataBase pool with invalid information does not yield an error message and silently fails

[ 
http://issues.apache.org/jira/browse/GERONIMO-1336?page=comments#action_12364032
 ] 

Aaron Mulder commented on GERONIMO-1336:


Joe, could you adjust the patch to not submit the form if there's an error (so 
the user can review the stuff) and also to validate that the max size is 
greater than the min size if both values are present?  Thanks.

> Setting the Max PoolSize on a DataBase pool with invalid information does not 
> yield an error message and silently fails
> ---
>
>  Key: GERONIMO-1336
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1336
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0-M5
> Reporter: Matt Hogstrom
> Assignee: Matt Hogstrom
> Priority: Minor
>  Fix For: 1.1, 1.0.1
>  Attachments: DBPoolValidate.patch
>
> When attempting a set of the SystemDatabase pool to a negative value the save 
> command executes and gives the appearance that the change was made.  At least 
> there is no information that indicates it failed.  The following error is 
> logged in the geronimo.log.  The Console should detect this error and inform 
> the user that an invalid value was specified.
> 13:38:37,813 ERROR [DatabasePoolPortlet] Unable to save connection pool
> java.lang.IllegalArgumentException: Max size must be positive, not -1
> at 
> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.setPartitionMaxSize(AbstractSinglePoolConnectionInterceptor.java:149)
> at 
> org.apache.geronimo.connector.outbound.connectionmanagerconfig.SinglePool.setPartitionMaxSize(SinglePool.java:143)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.setPartitionMaxSize(AbstractConnectionManager.java:104)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager$$FastClassByCGLIB$$80012030.invoke()
> 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.GBeanAttribute.setValue(GBeanAttribute.java:403)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:698)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:683)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.setAttribute(RawInvoker.java:53)
> at 
> org.apache.geronimo.kernel.basic.RawSetAttributeInvoker.invoke(RawSetAttributeInvoker.java:36)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.connector.outbound.ConnectionManagerContainer$$EnhancerByCGLIB$$813b4258.setPartitionMaxSize()
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:940)
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:337)
> at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
> at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)

-- 
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] Resolved: (GERONIMO-1379) Login Error page does not include updates to remove table and include About link

 [ http://issues.apache.org/jira/browse/GERONIMO-1379?page=all ]
 
Aaron Mulder resolved GERONIMO-1379:


Fix Version: 1.1
 Resolution: Fixed
  Assign To: Aaron Mulder  (was: Joe Bohn)

patch applied -- thanks!

> Login Error page does not include updates to remove table and include About 
> link
> 
>
>  Key: GERONIMO-1379
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1379
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0
>  Environment: Win XP , IE / Firefox
> Reporter: Joe Bohn
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: 1.1, 1.0.1
>  Attachments: LoginErrorGUI.patch
>
> When the login page was updated to remove the links that are now on the 
> welcome page, update the banner, and add in the icon and link in the banner 
> for the About information the login error page was not updated.

-- 
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-1194) Installer should only install packs(features) selected at install time

 [ http://issues.apache.org/jira/browse/GERONIMO-1194?page=all ]
 
David Jencks closed GERONIMO-1194:
--

Fix Version: 1.0.1
 Resolution: Fixed

The installer now installs all the jars, but only the configs that you select.  
Erik is going to open a new issue for installing only the jars needed by the 
actually installed configs.

> Installer should only install packs(features) selected at install time
> --
>
>  Key: GERONIMO-1194
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1194
>  Project: Geronimo
> Type: Improvement
>   Components: installer
> Versions: 1.0
>  Environment: Maven, installer runtime
> Reporter: erik daughtrey
> Assignee: David Jencks
>  Fix For: 1.1, 1.0.1
>  Attachments: installer-ph2-trunk.patch.gz
>
> DJ: The installer currently works by installing everything in a full
> geronimo install, and not starting the pieces you don't want.  This is
> rather unsatisfactory unless you sell disk space.  The geronimo
> assembly is moving to use of the packaging and assembly plugins, and we
> can leverage that with the installer.  What I am thinking of is
> including a maven repository inside  the installer jar that includes
> everything from a full geronimo install with everything, including all
> the .car files for the configurations.  Then  we can imitate or use the
> assembly plugin to copy the configuration dependencies into the install
> target and install the actual configurations.

-- 
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-1537) Installer - IzPack assembly does not qualify plugin version for code copied to installer assembly for use at install time

 [ http://issues.apache.org/jira/browse/GERONIMO-1537?page=all ]
 
David Jencks closed GERONIMO-1537:
--

Fix Version: 1.0.1
 1.1
 Resolution: Fixed
  Assign To: David Jencks

Applied with 1436.
Does not work on trunk due to missing client-deployer configuration.

branch 1.0:
Sendingassemblies/j2ee-installer/project.xml
Sendingetc/project.properties
Sendingplugins/geronimo-assembly-plugin/plugin.jelly
Sendingplugins/geronimo-assembly-plugin/project.xml
Transmitting file data 
Committed revision 372353.   
openejb 2.0 branch:
Checking in etc/project.properties;
new revision: 1.66.2.9; previous revision: 1.66.2.8

trunk:
Sendingassemblies/j2ee-installer/project.xml
Sendingetc/project.properties
Sendingplugins/geronimo-assembly-plugin/plugin.jelly
Sendingplugins/geronimo-assembly-plugin/project.xml
Transmitting file data 
Committed revision 372354. 
openejb 2.1: 
Checking in etc/project.properties;
new revision: 1.74; previous revision: 1.73 

> Installer - IzPack assembly does not qualify plugin version for code copied 
> to installer assembly for use at install time
> -
>
>  Key: GERONIMO-1537
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1537
>  Project: Geronimo
> Type: Bug
>   Components: installer
> Versions: 1.0.1, 1.1
> Reporter: erik daughtrey
> Assignee: David Jencks
>  Fix For: 1.0.1, 1.1
>  Attachments: installer-qualify-config-code-version.patch
>
> The installer uses the geronimo-assembly-plugin java code at install time to 
> install the configurations.
> Currently all plugin jars are incorrectly copied to the installer which may 
> lead to incorrect behavior.

-- 
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-1536) Installer - j2ee-installer assembly project.xml fix

 [ http://issues.apache.org/jira/browse/GERONIMO-1536?page=all ]
 
David Jencks closed GERONIMO-1536:
--

Fix Version: 1.0.1
 1.1
 Resolution: Fixed

Applied with 1437.
Does not work on trunk due to missing client-deployer configuration.

branch 1.0:
Sendingassemblies/j2ee-installer/project.xml
Sendingetc/project.properties
Sendingplugins/geronimo-assembly-plugin/plugin.jelly
Sendingplugins/geronimo-assembly-plugin/project.xml
Transmitting file data 
Committed revision 372353.   
openejb 2.0 branch:
Checking in etc/project.properties;
new revision: 1.66.2.9; previous revision: 1.66.2.8

trunk:
Sendingassemblies/j2ee-installer/project.xml
Sendingetc/project.properties
Sendingplugins/geronimo-assembly-plugin/plugin.jelly
Sendingplugins/geronimo-assembly-plugin/project.xml
Transmitting file data 
Committed revision 372354. 
openejb 2.1: 
Checking in etc/project.properties;
new revision: 1.74; previous revision: 1.73 

> Installer - j2ee-installer assembly project.xml fix
> ---
>
>  Key: GERONIMO-1536
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1536
>  Project: Geronimo
> Type: Bug
>   Components: installer
> Versions: 1.0.1, 1.1
> Reporter: erik daughtrey
> Assignee: David Jencks
>  Fix For: 1.0.1, 1.1
>  Attachments: installer-fix-project-var.patch
>
> Project XML incorrectly refers to ${Sample.Database.Pool} variable rather
> than ${J2EE.Features} pack variable.

-- 
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] Resolved: (GERONIMO-1535) Error in security realm portlet

 [ http://issues.apache.org/jira/browse/GERONIMO-1535?page=all ]
 
Aaron Mulder resolved GERONIMO-1535:


Resolution: Duplicate

Same as the DB pool problem (fixed) in GERONIMO-1467

> Error in security realm portlet
> ---
>
>  Key: GERONIMO-1535
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1535
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0
> Reporter: Aaron Mulder
>  Fix For: 1.0.1, 1.1

>
> 7:09:31,937 ERROR [SecurityRealmPortlet] Unable to render portlet
> ava.lang.NullPointerException
>at 
> org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortle
> .loadDriverJARList(SecurityRealmPortlet.java:610)
>at 
> org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortle
> .renderConfigure(SecurityRealmPortlet.java:529)
>at 
> org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortle
> .doView(SecurityRealmPortlet.java:236)

-- 
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] Resolved: (GERONIMO-1525) Error in DB Pool Portlet

 [ http://issues.apache.org/jira/browse/GERONIMO-1525?page=all ]
 
Aaron Mulder resolved GERONIMO-1525:


Resolution: Fixed

I think it is more likely that this was related to GERONIMO-1467, but either 
way it should be fixed.

> Error in DB Pool Portlet
> 
>
>  Key: GERONIMO-1525
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1525
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0
> Reporter: Aaron Mulder
>  Fix For: 1.0.1, 1.1

>
> 23:50:24,343 ERROR [[DBWizard]] Servlet.service() for servlet DBWizard threw 
> exception java.lang.NullPointerException
>at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:809)
>at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:334)
> Reporter notes this may be related to GERONIMO-1421

-- 
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-1421) DB portlet failure in Tomcat only

[ 
http://issues.apache.org/jira/browse/GERONIMO-1421?page=comments#action_12364019
 ] 

Aaron Mulder commented on GERONIMO-1421:


Random Google search found 
http://www.blooberry.com/indexdot/html/topics/urlencoding.htm which suggests 
that perhaps Pluto should be encoding values like ; that it puts in a URL, but 
I really am not sure.

Added a workaround to encode the value in the portlet, though that's pretty 
lame.

> DB portlet failure in Tomcat only
> -
>
>  Key: GERONIMO-1421
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1421
>  Project: Geronimo
> Type: Bug
>   Components: console, Tomcat
> Versions: 1.0
> Reporter: Aaron Mulder
>  Fix For: 1.1

>
>  - create a new database pool using the DB portlet
>  - select the "Derby Embedded" type
>  - pick the derby or derby-client JAR
>  - give it a new or existing database name
>  - add ;create=true to the end of the generated URL
>  - click test
> This procedure works in the Jetty build but does not work in the Tomcat 
> build.  In Tomcat, it just redirects to the main screen for that portlet 
> without any error message.  The database is actually created (visible in the 
> DB Manager portlet).  This does not happen if you remove ;create=true from 
> the URL and use an existing database.

-- 
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: v1.x Installer comments - Long

2006-01-25 Thread Joe Bohn



I agree with Dave on the issue of multiple containers.  We had many 
discussions on this list concerning the number of containers in an 
image.  The result was that we agreed to deliver 2 different assemblies 
rather than having multiple containers in one assembly.  If that was the 
decision for the assemblies then I would think it makes sense to do the 
same in the installer.


I also agree with Dave that we should revisit the issue of presenting 
the list of components twice: once to include them in the image and once 
to activate them in the runtime.  I doubt that most users would 
understand this distinction when initially installing Geronimo.  Most 
other packages consider the activation/inactivation of components to be 
post-install setup and choose the defaults that make the most sense.  In 
our case I would expect that all components selected during install 
would be active by default.


Joe

Dave Colasurdo wrote:

Erik Daughtrey wrote:


Dave, Thanks for the comments...

I made comments below.  Would you create installer component JIRAs for 
the items that make sense?




Yep.  BTW, has it been decided if the installer is a 1.0.1 or 1.1 item?


 On Thursday 19 January 2006 17:02, Dave Colasurdo wrote:

Looks like the Installer has made quite a bit of progress.  Thanks 
Erik!!


I'd like to suggest a few Usabality changes to the current installer..
I'm sure you are already aware of many of these and have plans to update
them.  Just wanted to provide some input based on my first impression.
BTW, I've attempted to provide input based on my thoughts on how this
would be perceived from the perspective of a first time user.

*Package Selection Panel*
1)The available selections are really a hierarchy
  -Server
  --J2EE Features
  ---Jetty Web Container
  Jetty Sample Applications

  ---Tomcat Web Container
  Tomcat Sample Applications


Does Izpack allow you to capture the hierarchy graphically?


Not that I've seen.  It looks like it's strictly a list box.


If not, anyway to insert padding to the front of entries to show the
hierarchy to the user?  I think this would be a better solution than the


Inserting spaces is something worth trying.



I experimented with inserting spaces in front of the pack names and it
seemed to work fine. As expected, this also requires that all references
to the pack name in geronimo-izpack.xml, izpack-process.xml and 
izpack-user-input.xml need to be updated.  This results in a panel that 
seems to show the hierarchy visually.  Though adding the spaces for each 
element in the xml files is a real hack and does seem troublesome. There 
should be an easier way to accomplish this without  unnaturally padding 
or creating a custom panel.  I'll post a question on this subject on the 
izpack mailing list.



"Dependencies" box and would more clearly convey the relationship
between selections.  Also, we should remove the dependencies box and the


I don't think it's possible to remove the dependencies box and keep 
the overall look and feel.



Will also post this on the izpack mailing list.  Are they responsive to
suggestions?


other righthand box that contains the Logo.  The description box should


I agree that the 2nd graphic is redundant at this point.  However, one 
thing we have not explored is the fact that the graphic on the right 
is actually different for each pack although for now each is a 
distinct instance of the same bitmap.  There is the potential to 
enhance each bitmap - possibly by making the Geronimo image subdued 
while overlaying something related to the pack.  I have not tried 
removing the graphic, but I don't think it's possible to remove it and 
keep this look and feel.



be located directly to the right of the main selection box OR below it
on the left.


I doubt that this is easy to change.  We can look into making some of 
these changes in more detail at some point.  Anything is actually 
possible depending on the capabilities of IzPack itself and how much 
we're willing to diverge the Geronimo installer from the IzPack 
codebase.  It may actually be possible to make some of the changes 
without changing IzPack, but based on what I know right now, I don't 
think so.
We've already diverged from the IzPack codebase and we need to factor 
these changes into IzPack as we move forward or we may run into 
problems related to these changes later as IzPack itself diverges.  
I'm struggling a little with this at this point given that IzPack is a 
generalized installer and some of the changes made are specific to 
Geronimo.  I tried to keep the changes separated, but our requirements 
are reflected in code I wanted to keep generalized anyway. I don't 
want to boil the ocean, but I'd also like to minimize problems 
occurring from the two distinct dev paths as much as possible.  
Graphical look and feel changes might be less painful to push back 
into IzPack, but it's still a little worrisome.




I like the way the dependant boxes interact (turnin

[jira] Commented: (GERONIMO-1421) DB portlet failure in Tomcat only

[ 
http://issues.apache.org/jira/browse/GERONIMO-1421?page=comments#action_12364018
 ] 

Aaron Mulder commented on GERONIMO-1421:


Entered Tomcat 5 bug 38390: 
http://issues.apache.org/bugzilla/show_bug.cgi?id=38390

> DB portlet failure in Tomcat only
> -
>
>  Key: GERONIMO-1421
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1421
>  Project: Geronimo
> Type: Bug
>   Components: console, Tomcat
> Versions: 1.0
> Reporter: Aaron Mulder
>  Fix For: 1.1

>
>  - create a new database pool using the DB portlet
>  - select the "Derby Embedded" type
>  - pick the derby or derby-client JAR
>  - give it a new or existing database name
>  - add ;create=true to the end of the generated URL
>  - click test
> This procedure works in the Jetty build but does not work in the Tomcat 
> build.  In Tomcat, it just redirects to the main screen for that portlet 
> without any error message.  The database is actually created (visible in the 
> DB Manager portlet).  This does not happen if you remove ;create=true from 
> the URL and use an existing database.

-- 
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

build failure (CRLF) in trunk on Win XP

2006-01-25 Thread Joe Bohn

I'm still getting build failures on WinXP when preparing the CRLF
endings (using trunk). Is anybody else still seeing these problems?

John Sission, you indicated that you thought this was fixed in
GERONIMO-1465. It seems better ... I used to fail something like
80-90% of the time and now it's more like 50%. However, it seems to
still be a problem. Any other thoughts?

Here is the command that I'm using to build:
maven -o new -Dmaven.test.skip=true -Dmaven.itest.skip=true

And here is the result:
assemble:package-assembly:
[echo] Preparing CRLF line endings in text based files for zip
distribution
[zip] Building zip:
C:\geronimo\assemblies\j2ee-tomcat-server\target\geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip
[echo] Preparing LF line endings in text based files for tar.gz
distribution

BUILD FAILED
File.. C:\geronimo\maven.xml
Element... maven:reactor
Line.. 63
Column -1
Unable to obtain goal [multiproject:install-callback] -- C:\Documents
and
Settings\Administrator\.maven\cache\geronimo-assembly-plugin-1.1.5\plugin.jelly:339:-1:
java.io.FileNotFoundException:
C:\geronimo\assemblies\j2ee-tomcat-server\target\geronimo-1.1-SNAPSHOT\config-store\34\daytrader-web-1.1-SNAPSHOT.war\docs\glossary.html
(Access is denied)

Total time : 25 minutes 20 seconds
Finished at : Wednesday, January 25, 2006 5:17:20 PM EST

After the build fails it appears that this file doesn't even exist.

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: CORBA incubation proposal

2006-01-25 Thread Ash

Hello,  I would like to contribute to this project. Please let me know what I can do to get involved.Thanks,AshOn 1/25/06, Trieloff, Carl
 <[EMAIL PROTECTED]> wrote:The IONA contributions will be a full working version of
ORB and transport - the work will be on XML Schema <-> IDLtooling and integration, which I believe there are guys thatcan do that quickly from the Celtix base. IONA contributionswill be a full working set to start from. Once we have a vote I
will get the code out.Hope that helpsCarl.-Original Message-From: Kresten Krab Thorup (Trifork) [mailto:[EMAIL PROTECTED]]Sent: Wednesday, January 25, 2006 8:54 AM
To: dev@geronimo.apache.orgSubject: Re: CORBA incubation proposalOn Jan 18, 2006, at 11:39 PM, Alan D. Cabrera wrote:> Here is the incubation proposal
>> http://wiki.apache.org/incubator/CorbaProposal>> Does anyone have any comments before we vote on it?>>Here's a short note on our status.
I've uploaded our RMI/IIOP mapping to JIRA (GERONIMO-1539) ascontribution for the proposed geronimo/corba subproject.  This is ourimplementation of javax.rmi.CORBA.ValueHandler and friends.   A primefeature of this is that it has an efficient implementation of
Util.copyObjects, that we use for inter-ejb invocations to get copysemantics for local invocations on remote interfaces (it avoidscopying java.lang.String, and immutable subclasses of java.lang.Number).
We are still working on the CORBA implementation, and we're currently3 people on the project.  Our current estimate on remaining work issomething like 1200 hours of effective work.  With this perspecive,we're looking forward to see IONAs contribution to see if we can cut
down that estimate somehow.  Hopefully that will be the case.Happy to hear that IONA is joining the project -- we can't wait toget started on Yoko.  Right now, with the proposal up in the air, anddetails of IONAs contribution still missing, we're somewhat in a
limbo since we don't want to duplicate something we can get fromIONAs stuff.  Also -- our lack of access to svn severely hurts ourperformance, so we hope that the Yoko project can be underway soon.Please everyone: let's get this project rolling asap.
Kresten

Re: New Geronimo Website

2006-01-25 Thread Bruce Snyder

On 1/17/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
> +1 for Hernans idea on organizing the content.
>
> How are we going to do that?? move the content from confluence over here or
> provide a link to confluence.
> Besides are we going to maintain the same structure as we have now in the
> confluence site?

I have not even thought about how to incorporate the other content.
What I'd like to do is convert the current site into a Maven site
first, and then convert the rest of the site to use the new
stylesheets.

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Castor (http://castor.org/)

[jira] Updated: (GERONIMO-1541) Unable to deploy applications in new Minimal and WEB-JMS assemblies

2006-01-25 Thread Joe Bohn (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1541?page=all ]

Joe Bohn updated GERONIMO-1541:
---

Geronimo Info: [Patch Available]

> Unable to deploy applications in new Minimal and WEB-JMS assemblies
> ---
>
>  Key: GERONIMO-1541
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1541
>  Project: Geronimo
> Type: Bug
>   Components: deployment, general
> Versions: 1.1
>  Environment: Win XP (but affects all)
> Reporter: Joe Bohn
> Assignee: Joe Bohn
>  Attachments: deployj2ee.patch
>
> When attempting to deploy an application into either the new 
> minimal-tomcat-server  or web-jms-tomcat-server assemblies we receive the 
> following error: 
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> javax/enterprise/deploy/spi/status/ProgressListener
> at 
> org.apache.geronimo.deployment.cli.DeployTool.(DeployTool.java:68)
> This appears to be because the j2ee deployment jar 
> (geronimo-j2ee-deployment_1.1_spec-1.0.jar) wasn't placed in the lib 
> directory.

-- 
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] Resolved: (GERONIMO-1426) DatabasePoolPortlet gets NPE when saving

 [ http://issues.apache.org/jira/browse/GERONIMO-1426?page=all ]
 
Aaron Mulder resolved GERONIMO-1426:


Resolution: Fixed
 Assign To: Aaron Mulder

Attempt to fix this by substituting %20 for spaces in URL to RAR that the 
console uses for deployment.  I tested this on Linux and it worked OK, but it 
also didn't have the problem described with URLs with spaces in the name.  If 
someone could test this fix on Windows that would be great.

> DatabasePoolPortlet gets NPE when saving
> 
>
>  Key: GERONIMO-1426
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1426
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0
>  Environment: Windows XP, MySQL Connector 3.1.12, MySQL 5.0, JDK 1.4.2
> Reporter: Cary Clark
> Assignee: Aaron Mulder
>  Fix For: 1.0.1, 1.1

>
> From a clean Geronimo 1.0 install:
> * Log in to console
> * add mysql-connector-java-3.1.12-bin.jar as a Common Library
> Group: mysql
> Artifact: mysql-connector-java-3.1.12
> Version: bin
> Type: jar
> * Go to Database Pools, click "Using the Geronimo database pool wizard"
> Name of Database Pool:: CPPool
>  Database Type:  MySQL
> *  Click Next
> JDBC Driver Class: JDBC Driver Class:
>Driver JAR: 
>   DB User Name: cpdb
>  DB Password: cpdbuser
>Port:  3306
>   Host:  localhost
>  Database: cpdb
> * Click Next
>  JDBC Connect URL:  jdbc:mysql://localhost:3306/cpdb
>   Driver Status:  Loaded Successfully
>  Pool Min Size: 10
>  Pool Max Size: 15
>Blocking Timeout: NO VALUE ENTERED...assuming default
> Idle Timeout:  NO VALUE ENTERED...assuming default
> * Click Test Connection, then Show Plan OR click Skip Test and Show Plan to 
> get the following stack trace:
> 16:24:04,137 ERROR [DatabasePoolPortlet] Unable to save connection pool
> java.lang.NullPointerException
>   at sun.misc.URLClassPath$3.run(URLClassPath.java:312)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at sun.misc.URLClassPath.getLoader(URLClassPath.java:309)
>   at sun.misc.URLClassPath.getLoader(URLClassPath.java:286)
>   at sun.misc.URLClassPath.findResource(URLClassPath.java:137)
>   at java.net.URLClassLoader$2.run(URLClassLoader.java:352)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findResource(URLClassLoader.java:349)
>   at java.lang.ClassLoader.getResource(ClassLoader.java:787)
>   at 
> org.apache.geronimo.deployment.tools.loader.AbstractDeployable.(AbstractDeployable.java:57)
>   at 
> org.apache.geronimo.deployment.tools.loader.ConnectorDeployable.(ConnectorDeployable.java:37)
>   at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:813)
>   at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:339)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>   at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
>   at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
>   at 
> org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
>   at 
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
>   at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.

[jira] Updated: (GERONIMO-1541) Unable to deploy applications in new Minimal and WEB-JMS assemblies

2006-01-25 Thread Joe Bohn (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1541?page=all ]

Joe Bohn updated GERONIMO-1541:
---

Attachment: deployj2ee.patch

Patch created from the root directory of trunk on WinXP.

> Unable to deploy applications in new Minimal and WEB-JMS assemblies
> ---
>
>  Key: GERONIMO-1541
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1541
>  Project: Geronimo
> Type: Bug
>   Components: deployment, general
> Versions: 1.1
>  Environment: Win XP (but affects all)
> Reporter: Joe Bohn
> Assignee: Joe Bohn
>  Attachments: deployj2ee.patch
>
> When attempting to deploy an application into either the new 
> minimal-tomcat-server  or web-jms-tomcat-server assemblies we receive the 
> following error: 
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> javax/enterprise/deploy/spi/status/ProgressListener
> at 
> org.apache.geronimo.deployment.cli.DeployTool.(DeployTool.java:68)
> This appears to be because the j2ee deployment jar 
> (geronimo-j2ee-deployment_1.1_spec-1.0.jar) wasn't placed in the lib 
> directory.

-- 
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

Trouble building the Jetspeed2 Geronimo integration

2006-01-25 Thread Philip Mark DONAGHY

I have encountered a problem while attempting to use
the patches submitted to
https://issues.apache.org/jira/browse/JS2-444

I'm using,
Maven 1.1-beta-2
Jetspeed2 Revision: 372190
Geronimo Revision: 372191

$ cd app-servers/geronimo
$ maven multiproject:install

The build fails with the error,

[echo] Running car:install for
geronimo-jetspeed-jetty
76 [main] ERROR
org.apache.geronimo.plugin.packaging.PackageBuilder  -
org.apache.geronimo.common.DeploymentException: Cannot
deploy the requested application module
(planFile=/home/phil/20051223/opensource/svnProjects/jetspeed-2/app-servers/geronimo/jetty-config/target/plan/plan.xml,
moduleFile=/home/phil/.maven/repository/org.apache.portals.jetspeed-2/ears/geronimo-jetspeed-2.1-dev.ear)
org.apache.geronimo.common.DeploymentException: Cannot
deploy the requested application module
(planFile=/home/phil/20051223/opensource/svnProjects/jetspeed-2/app-servers/geronimo/jetty-config/target/plan/plan.xml,
moduleFile=/home/phil/.maven/repository/org.apache.portals.jetspeed-2/ears/geronimo-jetspeed-2.1-dev.ear)

I have determined that the builder on line 235 of
o.a.g.deployment.Deployer is null. But I don't know why.








___ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs 
exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com

[jira] Commented: (GERONIMO-1540) Fix security vulnerability in jsp-examples

[ 
http://issues.apache.org/jira/browse/GERONIMO-1540?page=comments#action_12364012
 ] 

Dave Colasurdo commented on GERONIMO-1540:
--

The original warfile that I've attached seems to work fine on my machine (and 
another) though appears to be corrupted when I re-download it from JIRA.  It 
seems the JIRA system is having problems and I am receiving lots of garbled 
info when viewing items.   Not yet certain  if the two issues are related 
though please hold off on publishing the war until the issue is resolved.
Thanks..
-Dave-

> Fix security vulnerability in jsp-examples
> --
>
>  Key: GERONIMO-1540
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1540
>  Project: Geronimo
> Type: Bug
>   Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo
>  Attachments: geronimo-jsp-examples-tomcat-5.5.15-plus.war, jsp-examples.patch
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat 
> jsp-examples that are included in Geronimo.  It fails on both Jetty and 
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console.  That 
> problem is addressed in GERONIMO-1474.
>  

-- 
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: [VOTE] Yoko - A CORBA Server Sub-Project





On 1/25/2006 1:22 PM, Jacek Laskowski wrote:

  2006/1/25, Alan D. Cabrera <[EMAIL PROTECTED]>:
  
  
= PROJECT PROPOSAL =

Yoko, a CORBA Server.

  
  
Hi Alan,

As Dave stated, you're the clever men alive! I wish I had found it out
myself! ;) I like the name very much!

  
  
A set of leading vendors in this space are joining together to
contribute code and developer resources for this project.

  
  
Something is wrong with the sentence, but I can't find what part it
is. I think it should be 'develop' (a verb) rather than 'developer' (a
noun). I may easily be mistaken, too.

  
  
XMLShema based and can be bound to JAX-B,

  
  
XMLSchema

  
  
XMLBean, Geronimo, Tuscany or any implementation.

  
  
XMLBeans, Apache Geronimo

  
  
As a side benefit the XMLShema

  
   ^
XMLSchema

  
  
The CORBA Server will be a part of Geronimo and under heavy active
development.

  
  
I'm still uncertain if we're allowed to use 'The CORBA Server' in this
context. I'd rather write something along these lines: The server that
implements the CORBA specs... or alike.

Also, please use Apache Geronimo, which is the only proper name for the project.
  


Fixed.  This vote doesn't need to wait for us to resolve this issue. 
As a mater of fact, it can be one of its incubation tasks.


Regards,
Alan

Re: [VOTE] Yoko - A CORBA Server Sub-Project


heh heh

Is this a +1 or -1 vote?


Regards,
Alan

On 1/25/2006 12:33 PM, David Blevins wrote:

Yoko!  Is this just a clever way to confuse your wife so she doesn't  
know if your taking care of your daughter or hacking on code? :)


Alan Cabrera, I nominate you as the cleverest man alive.

-David


On Jan 25, 2006, at 11:37 AM, Alan D. Cabrera wrote:


= PROJECT PROPOSAL =

Yoko, a CORBA Server.

This proposal outlines the creation of a Geronimo sub-project  within 
the Apache Software Foundation.


= RATIONALE =

The current Apache Geronimo project (http://geronimo.apache.org/)  is 
in great need of a CORBA ORB that is not tied into a particular  
vendor's JVM and version.


This proposal is to build a compliant OMG CORBA server.

A set of leading vendors in this space are joining together to  
contribute code and developer resources for this project. We expect  
it to be a major success.


= INITIAL SOURCE =

IONA and Trifork will contribute core pieces of the source. IONA  
source will open source an
ORB and IIOP transport, and will provide the call chain utilizing  
Celtix jars. The project will
then expose the transport via a dynamic API that is XMLShema based  
and can be bound to JAX-B,
XMLBean, Geronimo, Tuscany or any implementation. As a side benefit  
the XMLShema API will also be able to support other transports and  
binding through configuration.


The developer community will take that code as input and produce  the 
best possible CORBA server.


= RESOURCES TO BE CREATED =

* SVN Repository
* Jira
* Mailing Lists
* Official Build Systems

= AVOIDING THE WARNING SIGNS =

== Orphaned products: ==

The CORBA Server will be a part of Geronimo and under heavy active  
development.


== Inexperience with open source: ==

Many of the current committers have experience working with open  
source projects and communities and the leaders of this project are  
long time ASF contributors. We do not expect any difficulty in  
executing under normal meritocracy rules.


== Homogenous developers: ==

There are developers from various companies: Chutnoon, IBM, IONA,  
LogicBlaze, Trifork, and Simula Labs.


== No ties to other Apache products: ==

The CORBA server intends to be a sub-project of Geronimo.  Other  
Apache projects such as Harmony could also use the ORB.


== A fascination with the Apache brand: ==

A CORBA ORB that is not tied to a particular vendor's JVM is  
critical for the Geronimo project.


The contributors are leading vendors in this space. There is no  risk 
of any of the usual warning signs of orphaned or abandoned code.


= Initial COMMITTERS =

* David Blevins (IBM) - Member of Geronimo PMC and Axis Committer
* Balaji Bravi (IONA), [EMAIL PROTECTED]
* Alan Cabrera (Simula Labs), [EMAIL PROTECTED] - Member of Geronimo  
PMC and Directory Committer

* Hiram Chirino (LogicBlaze)  - Member of Geronimo PMC
* Jeff Genender (Virtuas) - Member of Geronimo PMC
* Matt Hogstrom (IBM), [EMAIL PROTECTED] - Member of Geronimo PMC
* David Jencks (IBM) - Member of Geronimo PMC
* Anders Hessellund Jensen (Trifork), [EMAIL PROTECTED]
* Prasad Kosuru (IONA), [EMAIL PROTECTED]
* Lars Kühne (OpenORB), [EMAIL PROTECTED]
* Trustin Lee (1noon.com), [EMAIL PROTECTED] - Member of Directory  
PMC and Felix PPMC

* Rick McGuire (IBM), [EMAIL PROTECTED]
* Darren Middleman (IONA), [EMAIL PROTECTED]
* Edell Nolan (IONA), [EMAIL PROTECTED]
* Conrad O'Dea (IONA), [EMAIL PROTECTED]
* Dion Picco (IONA), [EMAIL PROTECTED]
* Andy Piper (BEA), [EMAIL PROTECTED]
* Jeppe Sommer (Trifork), [EMAIL PROTECTED]
* Adi Sakala (IONA), [EMAIL PROTECTED]
* Dain Sundstrom (IBM) [EMAIL PROTECTED] - Member of Geronimo PMC and  
JDO Committer

* Kresten Krab Thorup (Trifork), [EMAIL PROTECTED]
* David Weir (IONA), [EMAIL PROTECTED]

= PROPOSED APACHE SPONSOR =

The Geronimo PMC has voted to accept this project into the Geronimo  
project upon successful incubation.


= MENTORS =

* James Strachan

Re: [VOTE] Yoko - A CORBA Server Sub-Project


/me grumbles about this being a vote...

On 1/25/2006 12:20 PM, David Jencks wrote:

Could you correct the spelling of schema and add at least the apache  
emails of the committers missing emails?  Mine is [EMAIL PROTECTED]


Fixed on wiki.



What is the relationship between this and the trifork code just  
donated via Jira and the code we've been working on in the geronimo  
tree?


It will be brought in into the subproject.


Regards,
Alan

[jira] Created: (GERONIMO-1541) Unable to deploy applications in new Minimal and WEB-JMS assemblies

2006-01-25 Thread Joe Bohn (JIRA)

Unable to deploy applications in new Minimal and WEB-JMS assemblies
---

 Key: GERONIMO-1541
 URL: http://issues.apache.org/jira/browse/GERONIMO-1541
 Project: Geronimo
Type: Bug
  Components: deployment, general  
Versions: 1.1
 Environment: Win XP (but affects all)
Reporter: Joe Bohn
 Assigned to: Joe Bohn 


When attempting to deploy an application into either the new 
minimal-tomcat-server  or web-jms-tomcat-server assemblies we receive the 
following error: 

Exception in thread "main" java.lang.NoClassDefFoundError: 
javax/enterprise/deploy/spi/status/ProgressListener
at 
org.apache.geronimo.deployment.cli.DeployTool.(DeployTool.java:68)

This appears to be because the j2ee deployment jar 
(geronimo-j2ee-deployment_1.1_spec-1.0.jar) wasn't placed in the lib directory.

-- 
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] Resolved: (GERONIMO-1474) Cross site scripting vulnerabilites

 [ http://issues.apache.org/jira/browse/GERONIMO-1474?page=all ]
 
Aaron Mulder resolved GERONIMO-1474:


Resolution: Fixed
 Assign To: Aaron Mulder

Patch applied, thanks!

> Cross site scripting vulnerabilites
> ---
>
>  Key: GERONIMO-1474
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1474
>  Project: Geronimo
> Type: Bug
>   Components: console, security
> Versions: 1.0
> Reporter: Greg Wilkins
> Assignee: Aaron Mulder
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1474.patch
>
> Reported by oliver karow:
> The Web-Access-Log viewer does no filtering for html-/script-tags, and
> therefore allows attacks against the user of the admin-console:
> http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> Also reported:
> The first one is a classical cross-site scripting in the jsp-examples:
> http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')

-- 
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] Updated: (GERONIMO-1540) Fix security vulnerability in jsp-examples

 [ http://issues.apache.org/jira/browse/GERONIMO-1540?page=all ]

Dave Colasurdo updated GERONIMO-1540:
-

Geronimo Info: [Patch Available]

> Fix security vulnerability in jsp-examples
> --
>
>  Key: GERONIMO-1540
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1540
>  Project: Geronimo
> Type: Bug
>   Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo
>  Attachments: geronimo-jsp-examples-tomcat-5.5.15-plus.war, jsp-examples.patch
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat 
> jsp-examples that are included in Geronimo.  It fails on both Jetty and 
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console.  That 
> problem is addressed in GERONIMO-1474.
>  

-- 
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] Updated: (GERONIMO-1540) Fix security vulnerability in jsp-examples

 [ http://issues.apache.org/jira/browse/GERONIMO-1540?page=all ]

Dave Colasurdo updated GERONIMO-1540:
-

Attachment: jsp-examples.patch
geronimo-jsp-examples-tomcat-5.5.15-plus.war

> Fix security vulnerability in jsp-examples
> --
>
>  Key: GERONIMO-1540
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1540
>  Project: Geronimo
> Type: Bug
>   Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo
>  Attachments: geronimo-jsp-examples-tomcat-5.5.15-plus.war, jsp-examples.patch
>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat 
> jsp-examples that are included in Geronimo.  It fails on both Jetty and 
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console.  That 
> problem is addressed in GERONIMO-1474.
>  

-- 
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: [VOTE] Yoko - A CORBA Server Sub-Project

2006-01-25 Thread Jacek Laskowski

2006/1/25, Alan D. Cabrera <[EMAIL PROTECTED]>:
> = PROJECT PROPOSAL =
>
> Yoko, a CORBA Server.

Hi Alan,

As Dave stated, you're the clever men alive! I wish I had found it out
myself! ;) I like the name very much!

> A set of leading vendors in this space are joining together to
> contribute code and developer resources for this project.

Something is wrong with the sentence, but I can't find what part it
is. I think it should be 'develop' (a verb) rather than 'developer' (a
noun). I may easily be mistaken, too.

> XMLShema based and can be bound to JAX-B,

XMLSchema

> XMLBean, Geronimo, Tuscany or any implementation.

XMLBeans, Apache Geronimo

> As a side benefit the XMLShema
 ^
XMLSchema

> The CORBA Server will be a part of Geronimo and under heavy active
> development.

I'm still uncertain if we're allowed to use 'The CORBA Server' in this
context. I'd rather write something along these lines: The server that
implements the CORBA specs... or alike.

Also, please use Apache Geronimo, which is the only proper name for the project.

--
Jacek Laskowski
http://www.laskowski.org.pl

[jira] Commented: (GERONIMO-1540) Fix security vulnerability in jsp-examples

[ 
http://issues.apache.org/jira/browse/GERONIMO-1540?page=comments#action_12364003
 ] 

Dave Colasurdo commented on GERONIMO-1540:
--

The Tomcat team has fixed this in their open builds (but *not* in Tomcat 
5.5.15).  I've extracted the latest Tomcat source and built it to get the 
latest binary image of the jsp-examples.  

Tomcat info:
Path: .
URL: http://svn.apache.org/repos/asf/tomcat/current/tc5.5.x
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 372275
Node Kind: directory
Schedule: normal
Last Changed Author: remm
Last Changed Rev: 344145
Last Changed Date: 2005-11-14 10:19:03 -0500 (Mon, 14 Nov 2005)
Properties Last Updated: 2006-01-25 12:21:02 -0500 (Wed, 25 Jan 2006)

Also, merged our custom geronimo changes to the war file and change the 
geronimo build to pickup the new warfile.
I've provided a geronimo patch for the 1.0 branch and anupdated war file.
The attached warfile needs to get published to 
http://svn.apache.org/repository/geronimo-samples/wars/ prior to committing the 
patch.












> Fix security vulnerability in jsp-examples
> --
>
>  Key: GERONIMO-1540
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1540
>  Project: Geronimo
> Type: Bug
>   Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo

>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat 
> jsp-examples that are included in Geronimo.  It fails on both Jetty and 
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console.  That 
> problem is addressed in GERONIMO-1474.
>  

-- 
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] Updated: (GERONIMO-1540) Fix security vulnerability in jsp-examples

 [ http://issues.apache.org/jira/browse/GERONIMO-1540?page=all ]

Dave Colasurdo updated GERONIMO-1540:
-

Component: sample apps
  Version: 1.0.1
   1.1

> Fix security vulnerability in jsp-examples
> --
>
>  Key: GERONIMO-1540
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1540
>  Project: Geronimo
> Type: Bug
>   Components: sample apps
> Versions: 1.0.1, 1.1
> Reporter: Dave Colasurdo

>
> Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat 
> jsp-examples that are included in Geronimo.  It fails on both Jetty and 
> Tomcat.
> This can be reproduced with the following urls:
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
> http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> This JIRA does not address a related problem in the admin console.  That 
> problem is addressed in GERONIMO-1474.
>  

-- 
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-1540) Fix security vulnerability in jsp-examples

Fix security vulnerability in jsp-examples
--

 Key: GERONIMO-1540
 URL: http://issues.apache.org/jira/browse/GERONIMO-1540
 Project: Geronimo
Type: Bug
Reporter: Dave Colasurdo


Oliver Karow has reported a cross-site scripting vulnerability in the Tomcat 
jsp-examples that are included in Geronimo.  It fails on both Jetty and Tomcat.

This can be reproduced with the following urls:

http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')
http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)

This JIRA does not address a related problem in the admin console.  That 
problem is addressed in GERONIMO-1474.
 

-- 
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] Resolved: (GERONIMO-1467) DB pool portlet error when web session saved

 [ http://issues.apache.org/jira/browse/GERONIMO-1467?page=all ]
 
Aaron Mulder resolved GERONIMO-1467:


Resolution: Fixed
 Assign To: Aaron Mulder

> DB pool portlet error when web session saved
> 
>
>  Key: GERONIMO-1467
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1467
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.1, 1.0.1

>
> > 09:51:16,405 ERROR [ManagerBase] IOException while loading persisted
> > sessions: j 
> > ava.io.WriteAbortedException: writing aborted;
> > java.io.NotSerializableException: 
> > org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress
> > java.io.WriteAbortedException: writing aborted;
> > java.io.NotSerializableException 
> > :
> > org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress
> > at
> > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278)
> Also later in the e-mail thread:
> java.lang.NullPointerException
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750)
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderEdit(DatabasePoolPortlet.java:686)
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:619)
> at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250)

-- 
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: JIRA Mangled?

2006-01-25 Thread Bruce Snyder

On 1/25/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> Starting an hour or two ago, I'm having all kinds of trouble with JIRA
> bug pages showing up mangled.  Usually they come up with some text
> that clearly should be markup and then lay out wrong, or I get two
> whole copies of the bug content side by side, but one time a page came
> up looking like a text version of a binary file.  Both Safari and
> Firefox are doing the same thing for me, both on Mac and Linux.  For
> example:
>
> in the middle of http://issues.apache.org/jira/browse/GERONIMO-1450
>
> 200 OK
>

Yeah, I was getting the same thing. The shift-reload seems to be
working now whereas before it was not.

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Castor (http://castor.org/)

Re: [VOTE] Yoko - A CORBA Server Sub-Project

2006-01-25 Thread David Blevins

Yoko!  Is this just a clever way to confuse your wife so she doesn't  
know if your taking care of your daughter or hacking on code? :)


Alan Cabrera, I nominate you as the cleverest man alive.

-David


On Jan 25, 2006, at 11:37 AM, Alan D. Cabrera wrote:


= PROJECT PROPOSAL =

Yoko, a CORBA Server.

This proposal outlines the creation of a Geronimo sub-project  
within the Apache Software Foundation.


= RATIONALE =

The current Apache Geronimo project (http://geronimo.apache.org/)  
is in great need of a CORBA ORB that is not tied into a particular  
vendor's JVM and version.


This proposal is to build a compliant OMG CORBA server.

A set of leading vendors in this space are joining together to  
contribute code and developer resources for this project. We expect  
it to be a major success.


= INITIAL SOURCE =

IONA and Trifork will contribute core pieces of the source. IONA  
source will open source an
ORB and IIOP transport, and will provide the call chain utilizing  
Celtix jars. The project will
then expose the transport via a dynamic API that is XMLShema based  
and can be bound to JAX-B,
XMLBean, Geronimo, Tuscany or any implementation. As a side benefit  
the XMLShema API will also be able to support other transports and  
binding through configuration.


The developer community will take that code as input and produce  
the best possible CORBA server.


= RESOURCES TO BE CREATED =

* SVN Repository
* Jira
* Mailing Lists
* Official Build Systems

= AVOIDING THE WARNING SIGNS =

== Orphaned products: ==

The CORBA Server will be a part of Geronimo and under heavy active  
development.


== Inexperience with open source: ==

Many of the current committers have experience working with open  
source projects and communities and the leaders of this project are  
long time ASF contributors. We do not expect any difficulty in  
executing under normal meritocracy rules.


== Homogenous developers: ==

There are developers from various companies: Chutnoon, IBM, IONA,  
LogicBlaze, Trifork, and Simula Labs.


== No ties to other Apache products: ==

The CORBA server intends to be a sub-project of Geronimo.  Other  
Apache projects such as Harmony could also use the ORB.


== A fascination with the Apache brand: ==

A CORBA ORB that is not tied to a particular vendor's JVM is  
critical for the Geronimo project.


The contributors are leading vendors in this space. There is no  
risk of any of the usual warning signs of orphaned or abandoned code.


= Initial COMMITTERS =

* David Blevins (IBM) - Member of Geronimo PMC and Axis Committer
* Balaji Bravi (IONA), [EMAIL PROTECTED]
* Alan Cabrera (Simula Labs), [EMAIL PROTECTED] - Member of Geronimo  
PMC and Directory Committer

* Hiram Chirino (LogicBlaze)  - Member of Geronimo PMC
* Jeff Genender (Virtuas) - Member of Geronimo PMC
* Matt Hogstrom (IBM), [EMAIL PROTECTED] - Member of Geronimo PMC
* David Jencks (IBM) - Member of Geronimo PMC
* Anders Hessellund Jensen (Trifork), [EMAIL PROTECTED]
* Prasad Kosuru (IONA), [EMAIL PROTECTED]
* Lars Kühne (OpenORB), [EMAIL PROTECTED]
* Trustin Lee (1noon.com), [EMAIL PROTECTED] - Member of Directory  
PMC and Felix PPMC

* Rick McGuire (IBM), [EMAIL PROTECTED]
* Darren Middleman (IONA), [EMAIL PROTECTED]
* Edell Nolan (IONA), [EMAIL PROTECTED]
* Conrad O'Dea (IONA), [EMAIL PROTECTED]
* Dion Picco (IONA), [EMAIL PROTECTED]
* Andy Piper (BEA), [EMAIL PROTECTED]
* Jeppe Sommer (Trifork), [EMAIL PROTECTED]
* Adi Sakala (IONA), [EMAIL PROTECTED]
* Dain Sundstrom (IBM) [EMAIL PROTECTED] - Member of Geronimo PMC and  
JDO Committer

* Kresten Krab Thorup (Trifork), [EMAIL PROTECTED]
* David Weir (IONA), [EMAIL PROTECTED]

= PROPOSED APACHE SPONSOR =

The Geronimo PMC has voted to accept this project into the Geronimo  
project upon successful incubation.


= MENTORS =

* James Strachan

Re: [VOTE] Yoko - A CORBA Server Sub-Project

Could you correct the spelling of schema and add at least the apache  
emails of the committers missing emails?  Mine is [EMAIL PROTECTED]


What is the relationship between this and the trifork code just  
donated via Jira and the code we've been working on in the geronimo  
tree?


thanks
david jencks

On Jan 25, 2006, at 11:37 AM, Alan D. Cabrera wrote:


= PROJECT PROPOSAL =

Yoko, a CORBA Server.

This proposal outlines the creation of a Geronimo sub-project  
within the Apache Software Foundation.


= RATIONALE =

The current Apache Geronimo project (http://geronimo.apache.org/)  
is in great need of a CORBA ORB that is not tied into a particular  
vendor's JVM and version.


This proposal is to build a compliant OMG CORBA server.

A set of leading vendors in this space are joining together to  
contribute code and developer resources for this project. We expect  
it to be a major success.


= INITIAL SOURCE =

IONA and Trifork will contribute core pieces of the source. IONA  
source will open source an
ORB and IIOP transport, and will provide the call chain utilizing  
Celtix jars. The project will
then expose the transport via a dynamic API that is XMLShema based  
and can be bound to JAX-B,
XMLBean, Geronimo, Tuscany or any implementation. As a side benefit  
the XMLShema API will also be able to support other transports and  
binding through configuration.


The developer community will take that code as input and produce  
the best possible CORBA server.


= RESOURCES TO BE CREATED =

* SVN Repository
* Jira
* Mailing Lists
* Official Build Systems

= AVOIDING THE WARNING SIGNS =

== Orphaned products: ==

The CORBA Server will be a part of Geronimo and under heavy active  
development.


== Inexperience with open source: ==

Many of the current committers have experience working with open  
source projects and communities and the leaders of this project are  
long time ASF contributors. We do not expect any difficulty in  
executing under normal meritocracy rules.


== Homogenous developers: ==

There are developers from various companies: Chutnoon, IBM, IONA,  
LogicBlaze, Trifork, and Simula Labs.


== No ties to other Apache products: ==

The CORBA server intends to be a sub-project of Geronimo.  Other  
Apache projects such as Harmony could also use the ORB.


== A fascination with the Apache brand: ==

A CORBA ORB that is not tied to a particular vendor's JVM is  
critical for the Geronimo project.


The contributors are leading vendors in this space. There is no  
risk of any of the usual warning signs of orphaned or abandoned code.


= Initial COMMITTERS =

* David Blevins (IBM) - Member of Geronimo PMC and Axis Committer
* Balaji Bravi (IONA), [EMAIL PROTECTED]
* Alan Cabrera (Simula Labs), [EMAIL PROTECTED] - Member of Geronimo  
PMC and Directory Committer

* Hiram Chirino (LogicBlaze)  - Member of Geronimo PMC
* Jeff Genender (Virtuas) - Member of Geronimo PMC
* Matt Hogstrom (IBM), [EMAIL PROTECTED] - Member of Geronimo PMC
* David Jencks (IBM) - Member of Geronimo PMC
* Anders Hessellund Jensen (Trifork), [EMAIL PROTECTED]
* Prasad Kosuru (IONA), [EMAIL PROTECTED]
* Lars Kühne (OpenORB), [EMAIL PROTECTED]
* Trustin Lee (1noon.com), [EMAIL PROTECTED] - Member of Directory  
PMC and Felix PPMC

* Rick McGuire (IBM), [EMAIL PROTECTED]
* Darren Middleman (IONA), [EMAIL PROTECTED]
* Edell Nolan (IONA), [EMAIL PROTECTED]
* Conrad O'Dea (IONA), [EMAIL PROTECTED]
* Dion Picco (IONA), [EMAIL PROTECTED]
* Andy Piper (BEA), [EMAIL PROTECTED]
* Jeppe Sommer (Trifork), [EMAIL PROTECTED]
* Adi Sakala (IONA), [EMAIL PROTECTED]
* Dain Sundstrom (IBM) [EMAIL PROTECTED] - Member of Geronimo PMC and  
JDO Committer

* Kresten Krab Thorup (Trifork), [EMAIL PROTECTED]
* David Weir (IONA), [EMAIL PROTECTED]

= PROPOSED APACHE SPONSOR =

The Geronimo PMC has voted to accept this project into the Geronimo  
project upon successful incubation.


= MENTORS =

* James Strachan

[jira] Resolved: (GERONIMO-1450) Console usage plans use old namspace & parentId

 [ http://issues.apache.org/jira/browse/GERONIMO-1450?page=all ]
 
Aaron Mulder resolved GERONIMO-1450:


Resolution: Fixed

> Console usage plans use old namspace & parentId
> ---
>
>  Key: GERONIMO-1450
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1450
>  Project: Geronimo
> Type: Bug
>   Components: console, documentation
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1450.patch
>
> The usage pages in the console show deployment plans, and the namespaces in 
> those deployment plans don't have version numbers in them.  It's not 
> disastrous as we should convert those, but it'd be much better to fix them.
> Also, they have the wrong (o/a/g/Server) parentId, which is disastrous.

-- 
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-1450) Console usage plans use old namspace & parentId

2006-01-25 Thread Paul McMahan (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-1450?page=comments#action_12363997
 ] 

Paul McMahan commented on GERONIMO-1450:


I intend to submit a new patch for this issue when the 1.0.1 versioning 
discussion is resolved.

> Console usage plans use old namspace & parentId
> ---
>
>  Key: GERONIMO-1450
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1450
>  Project: Geronimo
> Type: Bug
>   Components: console, documentation
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1450.patch
>
> The usage pages in the console show deployment plans, and the namespaces in 
> those deployment plans don't have version numbers in them.  It's not 
> disastrous as we should convert those, but it'd be much better to fix them.
> Also, they have the wrong (o/a/g/Server) parentId, which is disastrous.

-- 
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-1450) Console usage plans use old namspace & parentId

[ 
http://issues.apache.org/jira/browse/GERONIMO-1450?page=comments#action_12363994
 ] 

Aaron Mulder commented on GERONIMO-1450:


I'm not convinced that we want to encourage people to use the new config ID 
format for their own stuff -- at least until we resolve the version issue.  And 
specifically relating to the patch, a user's application is not a CAR so we 
definitely wouldn't want to recommend they use a /car URI.  But the easiest 
solution is just to omit the parentId.  :)

> Console usage plans use old namspace & parentId
> ---
>
>  Key: GERONIMO-1450
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1450
>  Project: Geronimo
> Type: Bug
>   Components: console, documentation
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1450.patch
>
> The usage pages in the console show deployment plans, and the namespaces in 
> those deployment plans don't have version numbers in them.  It's not 
> disastrous as we should convert those, but it'd be much better to fix them.
> Also, they have the wrong (o/a/g/Server) parentId, which is disastrous.

-- 
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: JIRA Mangled?

2006-01-25 Thread Brian K. Wallace

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Aaron Mulder wrote:
> Starting an hour or two ago, I'm having all kinds of trouble with JIRA
> bug pages showing up mangled.  Usually they come up with some text
> that clearly should be markup and then lay out wrong, or I get two
> whole copies of the bug content side by side, but one time a page came
> up looking like a text version of a binary file.  Both Safari and
> Firefox are doing the same thing for me, both on Mac and Linux.  For
> example:
> 
> in the middle of http://issues.apache.org/jira/browse/GERONIMO-1450
> 
> 200 OK
> 
> 
Definitely a jira problem. [same in Firefox WinXP]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFD19UraCoPKRow/gARAil/AKCLsWQN6yuhlKbnwzbt80RPCVI2qwCgnIIy
2+GV+BdgJwaf/1NbeI6GhO0=
=kVxM
-END PGP SIGNATURE-

[jira] Commented: (GERONIMO-1539) RMI/IIOP implementation

2006-01-25 Thread Alan Cabrera (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-1539?page=comments#action_12363992
 ] 

Alan Cabrera commented on GERONIMO-1539:


The attachment seems to be corrupt.

> RMI/IIOP implementation
> ---
>
>  Key: GERONIMO-1539
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1539
>  Project: Geronimo
> Type: Task
>   Components: CORBA
> Reporter: Kresten Krab Thorup
> Assignee: Kresten Krab Thorup
>  Attachments: trifork-rmiiiop.tgz
>
> The attached tgz includes Triforks rmi/iiop implementation, which may be used 
> as a starting point for the Yoko projects's implementation hereof.  The code 
> doesn't compile as it is ripped right out of the Trifork T4 application 
> server.  (follow up email coming up)

-- 
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 Mangled?

2006-01-25 Thread Aaron Mulder

Starting an hour or two ago, I'm having all kinds of trouble with JIRA
bug pages showing up mangled.  Usually they come up with some text
that clearly should be markup and then lay out wrong, or I get two
whole copies of the bug content side by side, but one time a page came
up looking like a text version of a binary file.  Both Safari and
Firefox are doing the same thing for me, both on Mac and Linux.  For
example:

in the middle of http://issues.apache.org/jira/browse/GERONIMO-1450

200 OK

[VOTE] Yoko - A CORBA Server Sub-Project


= PROJECT PROPOSAL =

Yoko, a CORBA Server.

This proposal outlines the creation of a Geronimo sub-project within the 
Apache Software Foundation.


= RATIONALE =

The current Apache Geronimo project (http://geronimo.apache.org/) is in 
great need of a CORBA ORB that is not tied into a particular vendor's 
JVM and version.


This proposal is to build a compliant OMG CORBA server.

A set of leading vendors in this space are joining together to 
contribute code and developer resources for this project. We expect it 
to be a major success.


= INITIAL SOURCE =

IONA and Trifork will contribute core pieces of the source. IONA source 
will open source an
ORB and IIOP transport, and will provide the call chain utilizing Celtix 
jars. The project will
then expose the transport via a dynamic API that is XMLShema based and 
can be bound to JAX-B,
XMLBean, Geronimo, Tuscany or any implementation. As a side benefit the 
XMLShema API will also be able to support other transports and binding 
through configuration.


The developer community will take that code as input and produce the 
best possible CORBA server.


= RESOURCES TO BE CREATED =

* SVN Repository
* Jira
* Mailing Lists
* Official Build Systems

= AVOIDING THE WARNING SIGNS =

== Orphaned products: ==

The CORBA Server will be a part of Geronimo and under heavy active 
development.


== Inexperience with open source: ==

Many of the current committers have experience working with open source 
projects and communities and the leaders of this project are long time 
ASF contributors. We do not expect any difficulty in executing under 
normal meritocracy rules.


== Homogenous developers: ==

There are developers from various companies: Chutnoon, IBM, IONA, 
LogicBlaze, Trifork, and Simula Labs.


== No ties to other Apache products: ==

The CORBA server intends to be a sub-project of Geronimo.  Other Apache 
projects such as Harmony could also use the ORB.


== A fascination with the Apache brand: ==

A CORBA ORB that is not tied to a particular vendor's JVM is critical 
for the Geronimo project.


The contributors are leading vendors in this space. There is no risk of 
any of the usual warning signs of orphaned or abandoned code.


= Initial COMMITTERS =

* David Blevins (IBM) - Member of Geronimo PMC and Axis Committer
* Balaji Bravi (IONA), [EMAIL PROTECTED]
* Alan Cabrera (Simula Labs), [EMAIL PROTECTED] - Member of Geronimo PMC 
and Directory Committer

* Hiram Chirino (LogicBlaze)  - Member of Geronimo PMC
* Jeff Genender (Virtuas) - Member of Geronimo PMC
* Matt Hogstrom (IBM), [EMAIL PROTECTED] - Member of Geronimo PMC
* David Jencks (IBM) - Member of Geronimo PMC
* Anders Hessellund Jensen (Trifork), [EMAIL PROTECTED]
* Prasad Kosuru (IONA), [EMAIL PROTECTED]
* Lars Kühne (OpenORB), [EMAIL PROTECTED]
* Trustin Lee (1noon.com), [EMAIL PROTECTED] - Member of Directory PMC 
and Felix PPMC

* Rick McGuire (IBM), [EMAIL PROTECTED]
* Darren Middleman (IONA), [EMAIL PROTECTED]
* Edell Nolan (IONA), [EMAIL PROTECTED]
* Conrad O'Dea (IONA), [EMAIL PROTECTED]
* Dion Picco (IONA), [EMAIL PROTECTED]
* Andy Piper (BEA), [EMAIL PROTECTED]
* Jeppe Sommer (Trifork), [EMAIL PROTECTED]
* Adi Sakala (IONA), [EMAIL PROTECTED]
* Dain Sundstrom (IBM) [EMAIL PROTECTED] - Member of Geronimo PMC and JDO 
Committer

* Kresten Krab Thorup (Trifork), [EMAIL PROTECTED]
* David Weir (IONA), [EMAIL PROTECTED]


= PROPOSED APACHE SPONSOR =

The Geronimo PMC has voted to accept this project into the Geronimo 
project upon successful incubation.


= MENTORS =

* James Strachan

RE: CORBA incubation proposal

2006-01-25 Thread Trieloff, Carl

The IONA contributions will be a full working version of
ORB and transport - the work will be on XML Schema <-> IDL
tooling and integration, which I believe there are guys that
can do that quickly from the Celtix base. IONA contributions
will be a full working set to start from. Once we have a vote I
will get the code out.

Hope that helps
Carl.

-Original Message-
From: Kresten Krab Thorup (Trifork) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 25, 2006 8:54 AM
To: dev@geronimo.apache.org
Subject: Re: CORBA incubation proposal

On Jan 18, 2006, at 11:39 PM, Alan D. Cabrera wrote:

> Here is the incubation proposal
>
> http://wiki.apache.org/incubator/CorbaProposal
>
> Does anyone have any comments before we vote on it?
>
>

Here's a short note on our status.

I've uploaded our RMI/IIOP mapping to JIRA (GERONIMO-1539) as  
contribution for the proposed geronimo/corba subproject.  This is our  
implementation of javax.rmi.CORBA.ValueHandler and friends.   A prime  
feature of this is that it has an efficient implementation of  
Util.copyObjects, that we use for inter-ejb invocations to get copy  
semantics for local invocations on remote interfaces (it avoids  
copying java.lang.String, and immutable subclasses of java.lang.Number).

We are still working on the CORBA implementation, and we're currently  
3 people on the project.  Our current estimate on remaining work is  
something like 1200 hours of effective work.  With this perspecive,  
we're looking forward to see IONAs contribution to see if we can cut  
down that estimate somehow.  Hopefully that will be the case.

Happy to hear that IONA is joining the project -- we can't wait to  
get started on Yoko.  Right now, with the proposal up in the air, and  
details of IONAs contribution still missing, we're somewhat in a  
limbo since we don't want to duplicate something we can get from  
IONAs stuff.  Also -- our lack of access to svn severely hurts our  
performance, so we hope that the Yoko project can be underway soon.   
Please everyone: let's get this project rolling asap.

Kresten

Re: [VOTE] Documentation in Confluence, MoinMoin, or..

2006-01-25 Thread Jason Dillon

You know where the source is for the updated snippet library that is  
use on http://wiki.opensymphony.com?  Its got some integrated caching/ 
refreshing stuff.  Not sure that is needed anymore since you could  
just use {cache}, and the ?refresh=true to reload.


I played with the snippet a long time ago, but never really got it  
working... must have been user error.


--jason


On Jan 25, 2006, at 5:39 AM, James Strachan wrote:



On 23 Jan 2006, at 03:18, Geir Magnusson Jr wrote:
I'm also curious about how in-code documentation can be  
integrated, via something like Doxygen or -ish.


See the ${snippet} macro for how to combine the wiki with source  
code or test cases etc. We've used this massively throughout  
various codehaus projects in the past.

http://confluence.atlassian.com/display/CONFEXT/Snippet+Macro+Library

James
---
http://radio.weblogs.com/0112098/

[jira] Resolved: (GERONIMO-1387) Geronimo Console Applications portlets fail after starting app client.

 [ http://issues.apache.org/jira/browse/GERONIMO-1387?page=all ]
 
Aaron Mulder resolved GERONIMO-1387:


Fix Version: 1.1
 Resolution: Fixed
  Assign To: Aaron Mulder

Changed the JSP to omit the "start" link for J2EE application clients.

> Geronimo Console Applications portlets fail after starting app client.
> --
>
>  Key: GERONIMO-1387
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1387
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0
>  Environment: Windows JDK 1.4.2_08, Jetty version of 1.0 12182005 test 
> release.
> Reporter: Neal Sanche
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1387.patch
>
> Log into console, and click App Clients navigation link on left. The 
> daytrader-derby-jetty-streamer-client/1.0/car component is stopped. Click the 
> 'Start' link. The server will throw an exception:
> 22:57:55,161 ERROR [PortletFragment] Error in Portlet
> java.lang.IllegalStateException: More than one configuration mananger was 
> found
> in kernel
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.getConfigurationM
> anager(ConfigurationUtil.java:60)
> at 
> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView
> (ConfigManagerPortlet.java:203)
> at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250)
> at javax.portlet.GenericPortlet.render(GenericPortlet.java:178)
> at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218
> )
> at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at 
> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> at 
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428
> )
> at 
> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolde
> r.java:99)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> WebApplicationHandler.java:830)
> at 
> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170
> )
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
> WebApplicationHandler.java:821)
> at 
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati
> onHandler.java:471)
> at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
> at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke
> rImpl.java:120)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvoke
> rImpl.java:73)
> at 
> org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerI
> mpl.java:119)
> at 
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPo
> rtlet(PortletContainerWrapperImpl.java:70)
> at 
> org.apache.pluto.portalImpl.aggregation.PortletFragment.service(Portl
> etFragment.java:168)
> at 
> org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService
> (org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
> .java:322)
> Then from that point onward, the server will be unable to show any of the 
> following portlets:
> Application EARs
> Web App WARs
> EJB Jars
> J2EE Connectors
> App Clients
> System Modules
> Each of which will throw the above exception, or one remarkably similar.

-- 
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] Assigned: (GERONIMO-1536) Installer - j2ee-installer assembly project.xml fix

 [ http://issues.apache.org/jira/browse/GERONIMO-1536?page=all ]

David Jencks reassigned GERONIMO-1536:
--

Assign To: David Jencks

> Installer - j2ee-installer assembly project.xml fix
> ---
>
>  Key: GERONIMO-1536
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1536
>  Project: Geronimo
> Type: Bug
>   Components: installer
> Versions: 1.1, 1.0.1
> Reporter: erik daughtrey
> Assignee: David Jencks
>  Attachments: installer-fix-project-var.patch
>
> Project XML incorrectly refers to ${Sample.Database.Pool} variable rather
> than ${J2EE.Features} pack variable.

-- 
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: Poll: Resolve configId Versions for 1.0.1

2006-01-25 Thread Joe Bohn

I've used this approach on another project with some (although not 
perfect) success.  The benefit of the approach is that it allows a 
"using" component to specify a version of a component upon which it is 
dependent with certainty.  The dependent component then can make the 
call if it will be compatible with lower level versions of itself.

The tricky part gets to be what some components might consider to be 
compatible or not.  A change that seems safe can cause problems for some 
users.  This approach can be slightly extended to provide the "using" 
component with an additional attribute to indicate if it is willing to 
accept a "compatible" version or it if requires an exact match.

This may or may not be possible for the 1.0.1 release, but I think we 
will eventually have to consider something along these lines.

Joe

Paul McMahan wrote:
FWIW I responded to Aaron's earlier thread on this topic with an idea 
that would allow Geronimo 1.0.1 (and onward) to support applications 
that reference the Geronimo 1.0 components.   The idea is to basically 
add support for a new tag, , that we would add to 
Geronimo components as we bump their configIds.

So an application developed using Geronimo 1.0 that looks like this:

Would still work (unchanged) in Geronimo 1.0.1 because we would use the 
new tag as follows:

geronimo/j2ee-server/1.0/car

As we move on releasing more versions of Geronimo we continue to declare 
backwards compatibility by extending this tag:

geronimo/j2ee-server/1.0/car
geronimo/j2ee-server/1.0.1/car

This idea may be half baked, but in case there is some merit to it I 
wanted to chime in while there's still time.  During a brief chat on IRC 
one (valid) criticism is that the  tag might look 
pretty scary by the time we reach version, say, 3.4.17.  But that effect 
could be lessened by using the tag judiciously (perhaps only within 
major release boundaries) or by adding support for wildcards in the tag 
(i.e. making the Geronimo developers understand/use the special wildcard 
syntax, not the app developers ;-)

Best wishes,
Paul

On 1/25/06, *David Jencks* <[EMAIL PROTECTED] 
> wrote:

On Jan 24, 2006, at 5:50 PM, John Sisson wrote:

 > Aaron Mulder wrote:
 >> If you're deploying a JMS resource, whether at the top level of the
 >> server or as part of the application, isn't it best to put a
 >> parent of
 >> geronimo/activemq-broker/1.0/car?  I would certainly think so
 >> (definitely want the broker started before the app!).  The same may
 >> not be true for JDBC (if you're not using Derby), but I think it
 >> would
 >> be true for anything that ultimately depends on LDAP (such as a
 >> security relam) using the embedded Directory server.  I'm not so
sure
 >> about CORBA.  We dodged this on ServiceMix by separating that
out for
 >> the time being.  But we currently also have the issues in GBean
 >> names,
 >> so any GBeans with references to things like ServerInfo will also
 >> have
 >> the problem.
 >>
 >> I guess I might be willing to be dragged kicking and screaming into
 >> 1.0.1 without a fix for this, but I sure wouldn't feel good about
 >> it. This seems to me to be similar to changing our deployment plan
 >> schemas
 >> and saying "well, you know, the elements we removed weren't used
that
 >> much anyway."  I know if we were going to do that we'd have a
 >> converter in place so that old plans wouldn't actually break.
 >>
 >>
 > I also would prefer this issue being resolved in 1.0.1 (even if we
 > need to push the release back a bit).  Users should not have to
 > change their existing plans to use 1.0.1 .

I think it's unlikely we can find a solution that we will like that
will let plans with a hardcoded geronimo 1.0 version in them continue
to work.  What we might be able to do is find a way that we think
1.0.1 compatible plans will remain usable at least until 2.0 and
hopefully farther.

thanks
david jencks

 > John
 >> Thanks,
 >> Aaron
 >>
 >> On 1/24/06, David Jencks < [EMAIL PROTECTED]
> wrote:
 >>
 >>> On Jan 24, 2006, at 3:59 PM, Aaron Mulder wrote:
 >>>
 >>>
  On 1/24/06, Alan D. Cabrera < [EMAIL PROTECTED]
> wrote:

 > Why do the version numbers change for patches?  Shouldn't
this be
 > backward compatible?
 >
  That the first option in the poll -- to make the configIds
  retain the
  version number 1.0 even though the rest of the server marches
on to
  1.0.1.  Currently, the version for each configId is based on the
  Geronimo version number, so everything was incremented to
  1.0.1-SNAPSHOT (and ultimately 1.0.1 ) together.

  Howe

Re: CORBA incubation proposal

2006-01-25 Thread Kresten Krab Thorup (Trifork)


On Jan 18, 2006, at 11:39 PM, Alan D. Cabrera wrote:



Here is the incubation proposal

http://wiki.apache.org/incubator/CorbaProposal

Does anyone have any comments before we vote on it?




Here's a short note on our status.

I've uploaded our RMI/IIOP mapping to JIRA (GERONIMO-1539) as  
contribution for the proposed geronimo/corba subproject.  This is our  
implementation of javax.rmi.CORBA.ValueHandler and friends.   A prime  
feature of this is that it has an efficient implementation of  
Util.copyObjects, that we use for inter-ejb invocations to get copy  
semantics for local invocations on remote interfaces (it avoids  
copying java.lang.String, and immutable subclasses of java.lang.Number).


We are still working on the CORBA implementation, and we're currently  
3 people on the project.  Our current estimate on remaining work is  
something like 1200 hours of effective work.  With this perspecive,  
we're looking forward to see IONAs contribution to see if we can cut  
down that estimate somehow.  Hopefully that will be the case.


Happy to hear that IONA is joining the project -- we can't wait to  
get started on Yoko.  Right now, with the proposal up in the air, and  
details of IONAs contribution still missing, we're somewhat in a  
limbo since we don't want to duplicate something we can get from  
IONAs stuff.  Also -- our lack of access to svn severely hurts our  
performance, so we hope that the Yoko project can be underway soon.   
Please everyone: let's get this project rolling asap.


Kresten




smime.p7s
Description: S/MIME cryptographic signature

Re: Poll: Resolve configId Versions for 1.0.1

2006-01-25 Thread Paul McMahan

FWIW I responded to Aaron's earlier thread on this topic with an idea
that would allow Geronimo 1.0.1 (and onward) to support applications
that reference the Geronimo 1.0 components.   The idea is to
basically add support for a new tag, , that we
would add to Geronimo components as we bump their configIds.

So an application developed using Geronimo 1.0 that looks like this:


configId="MyApplication"
   parentId="geronimo/j2ee-server/1.0/car"
   xmlns="...">
Would still work (unchanged) in Geronimo 1.0.1 because we would use the new tag as follows:
configId="geronimo/j2ee-server/1.0.1/car"  xmlns="...">
    geronimo/j2ee-server/1.0/car


As we move on releasing more versions of Geronimo we continue to declare backwards compatibility by extending this tag:

configId="geronimo/j2ee-server/1.1/car"
  xmlns="...">
    
    geronimo/j2ee-server/1.0/car
    geronimo/j2ee-server/1.0.1/car
    


This idea may be half baked, but in case there is some merit to it I
wanted to chime in while there's still time.  During a brief chat
on
IRC one (valid) criticism is that the  tag
might look pretty scary by the time we reach version, say,
3.4.17.  But that effect could be lessened by using the tag
judiciously (perhaps only within major release boundaries) or by adding
support for wildcards in the tag (i.e. making the Geronimo developers
understand/use the special wildcard syntax, not the app developers ;-)

Best wishes,
PaulOn 1/25/06, David Jencks <[EMAIL PROTECTED]
> wrote:
On Jan 24, 2006, at 5:50 PM, John Sisson wrote:> Aaron Mulder wrote:>> If you're deploying a JMS resource, whether at the top level of the>> server or as part of the application, isn't it best to put a
>> parent of>> geronimo/activemq-broker/1.0/car?  I would certainly think so>> (definitely want the broker started before the app!).  The same may>> not be true for JDBC (if you're not using Derby), but I think it
>> would>> be true for anything that ultimately depends on LDAP (such as a>> security relam) using the embedded Directory server.  I'm not so sure>> about CORBA.  We dodged this on ServiceMix by separating that out for
>> the time being.  But we currently also have the issues in GBean>> names,>> so any GBeans with references to things like ServerInfo will also>> have>> the problem.>>
>> I guess I might be willing to be dragged kicking and screaming into>> 1.0.1 without a fix for this, but I sure wouldn't feel good about>> it. This seems to me to be similar to changing our deployment plan
>> schemas>> and saying "well, you know, the elements we removed weren't used that>> much anyway."  I know if we were going to do that we'd have a>> converter in place so that old plans wouldn't actually break.
> I also would prefer this issue being resolved in 1.0.1 (even if we> need to push the release back a bit).  Users should not have to> change their existing plans to use 1.0.1
.
I think it's unlikely we can find a solution that we will like thatwill let plans with a hardcoded geronimo 1.0 version in them continueto work.  What we might be able to do is find a way that we think

1.0.1 compatible plans will remain usable at least until 2.0 andhopefully farther.thanksdavid jencks> John>> Thanks,>> Aaron On 1/24/06, David Jencks <
[EMAIL PROTECTED]> wrote:> On Jan 24, 2006, at 3:59 PM, Aaron Mulder wrote:
>> On 1/24/06, Alan D. Cabrera <
[EMAIL PROTECTED]> wrote:> Why do the version numbers change for patches?  Shouldn't this be
> backward compatible?
> That the first option in the poll -- to make the configIds retain the version number 1.0 even though the rest of the server marches on to
 1.0.1.  Currently, the version for each configId is based on the Geronimo version number, so everything was incremented to 1.0.1-SNAPSHOT (and ultimately 1.0.1
) together.
 However, even if we select this as the short term (1.0.1) solution, I don't think it's a general solution.  I don't think people should have
 to change their plans to go from 1.0.x to 1.1x or even to 2.x unless we actually change the schemas in a non-backward-compatible way (and

 even if we did that we'd usually provide a converter to silently update a plan using the old format to the new format, but the schema converters don't currently touch embedded data like configIds).
 My 2 cents is that the long-term solution should somehow involve the version number being optional, so you can use it if you feel strongly
 about it (running big server farm, want to force everything to be identical) and omit it if you would prefer to maximize compatibility.
>>> I think we might be able to remove /car from the configId: it's
>>> optional IIUC in the maven format and I think we can always infer it>>> from the context.>> Making the version optional in plan references (parentId but not
>>> configId) might work.  If we do, we have to decide when the vers

[jira] Created: (GERONIMO-1539) RMI/IIOP implementation

2006-01-25 Thread Kresten Krab Thorup (JIRA)

RMI/IIOP implementation
---

 Key: GERONIMO-1539
 URL: http://issues.apache.org/jira/browse/GERONIMO-1539
 Project: Geronimo
Type: Task
  Components: CORBA  
Reporter: Kresten Krab Thorup
 Assigned to: Kresten Krab Thorup 
 Attachments: trifork-rmiiiop.tgz

The attached tgz includes Triforks rmi/iiop implementation, which may be used 
as a starting point for the Yoko projects's implementation hereof.  The code 
doesn't compile as it is ripped right out of the Trifork T4 application server. 
 (follow up email coming up)

-- 
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] Updated: (GERONIMO-1539) RMI/IIOP implementation

2006-01-25 Thread Kresten Krab Thorup (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1539?page=all ]

Kresten Krab Thorup updated GERONIMO-1539:
--

Attachment: trifork-rmiiiop.tgz

> RMI/IIOP implementation
> ---
>
>  Key: GERONIMO-1539
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1539
>  Project: Geronimo
> Type: Task
>   Components: CORBA
> Reporter: Kresten Krab Thorup
> Assignee: Kresten Krab Thorup
>  Attachments: trifork-rmiiiop.tgz
>
> The attached tgz includes Triforks rmi/iiop implementation, which may be used 
> as a starting point for the Yoko projects's implementation hereof.  The code 
> doesn't compile as it is ripped right out of the Trifork T4 application 
> server.  (follow up email coming up)

-- 
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: servicemix-web

2006-01-25 Thread Philip Dodds

Sounds like a good idea,  have you looked at using the izpack plugin for
maven to do an installer?

P

On 1/25/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>
> The tooling\servicemix-web module is used as a demo of ServiceMix
> integration in a web-app.
> I'd like to move it to the distribution so that users to not need to
> download all the sources and build it manually.
>
> Any thoughts ?
>
> Guillaume Nodet
>
>

servicemix-web

2006-01-25 Thread Guillaume Nodet

The tooling\servicemix-web module is used as a demo of ServiceMix 
integration in a web-app.
I'd like to move it to the distribution so that users to not need to 
download all the sources and build it manually.


Any thoughts ?

Guillaume Nodet

Re: [VOTE] Documentation in Confluence, MoinMoin, or..



On 23 Jan 2006, at 03:18, Geir Magnusson Jr wrote:
I'm also curious about how in-code documentation can be integrated,  
via something like Doxygen or -ish.


See the ${snippet} macro for how to combine the wiki with source code  
or test cases etc. We've used this massively throughout various  
codehaus projects in the past.

http://confluence.atlassian.com/display/CONFEXT/Snippet+Macro+Library

James
---
http://radio.weblogs.com/0112098/

Re: [VOTE] Documentation in Confluence, MoinMoin, or..


+1 Confluence

I'm now completely dependent on ${snippet} as well as loving its  
general ease of use.


On 20 Jan 2006, at 14:36, Rodent of Unusual Size wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Anyone with an interest in working with the documentation,
either directly or for some sort of postprocessing, please
vote here.  Unless there are problems, this vote will
close in one week, at 14h00 UTC on 27 January 2006.  At
that point, a two-thirds majority will be a clear indicator
of which way to go; any narrower majority will mean
opinions are still too divided.

Working documentation for Apache Geronimo should be kept in

[  ] Confluence
[  ] MoinMoin wiki
[  ] Other (explain)

This does not affect the need for 'solid' or released
documentation to be under source control.  This vote is
only to decide a single collaborative environment for
its development.
- --
#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

iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D
eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y
Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7
48uwYXnlh1c=
=1Dmb
-END PGP SIGNATURE-



James
---
http://radio.weblogs.com/0112098/

[jira] Updated: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally

2006-01-25 Thread anita kulshreshtha (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1035?page=all ]

anita kulshreshtha updated GERONIMO-1035:
-

Attachment: stats.zip
geronimo-stats-1.1-SNAPSHOT.war

This patch is for viewing the stats and is exactly same as for G-1293

> tomcat integration should wrap each servlet indiviudally
> 
>
>  Key: GERONIMO-1035
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1035
>  Project: Geronimo
> Type: New Feature
>   Components: Tomcat
> Versions: 1.0-M5
>  Environment: All
> Reporter: anita kulshreshtha
> Assignee: Jeff Genender
>  Fix For: 1.1
>  Attachments: geronimo-stats-1.1-SNAPSHOT.war, management.patch, stats.zip, 
> tomcat-builder.patch, tomcat.patch
>
> TomcatModuleBuilder should wrap each servlet specified in the deployment 
> descriptor individually. This is needed by JSR-77 and for gathering tomcat 
> internal statistics.   

-- 
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] Updated: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally

2006-01-25 Thread anita kulshreshtha (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1035?page=all ]

anita kulshreshtha updated GERONIMO-1035:
-

Attachment: tomcat.patch
tomcat-builder.patch
management.patch

This patch creates servlets Gbeans. Currently Gbeans only provide the stats. It 
includes patches for G-1293.

> tomcat integration should wrap each servlet indiviudally
> 
>
>  Key: GERONIMO-1035
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1035
>  Project: Geronimo
> Type: New Feature
>   Components: Tomcat
> Versions: 1.0-M5
>  Environment: All
> Reporter: anita kulshreshtha
> Assignee: Jeff Genender
>  Fix For: 1.1
>  Attachments: management.patch, tomcat-builder.patch, tomcat.patch
>
> TomcatModuleBuilder should wrap each servlet specified in the deployment 
> descriptor individually. This is needed by JSR-77 and for gathering tomcat 
> internal statistics.   

-- 
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: jms connection factory lookup from the standalone client



On 25 Jan 2006, at 00:36, David Jencks wrote:



On Jan 24, 2006, at 4:16 PM, Simon wrote:

This is j2se client (plain java). I thought as well that I can not  
get
connection factory from jndi outside container; However active-mq  
website
(http://www.activemq.org/Geronimo) says it is possible;  
(Apparently they
connect to the jms server for jndi lookup). But they gloss over  
the name of

the connection factory, and I could not make it work.


Look further in their documentation.  They have way to set up a  
local jndi context that gives you access to the stuff running in  
the current jvm.  I'm not sure but this may involve spring.  Asking  
on their list will get you better quality information :-)  AFAIK  
you are not going to be able to look up an AMQ connection factory  
remotely and pull it across the wire.


Agreed - its an in-JVM JNDI implementation that creates an in-JVM  
ConnectionFactory capable of communicating with a remote (or local)  
JMS broker

http://activemq.org/JNDI+Support

James
---
http://radio.weblogs.com/0112098/

Re: jms connection factory lookup from the standalone client

If you are in J2SE you can get a ConnectionFactory from JNDI using  
these instructions...


http://activemq.org/JNDI+Support


On 25 Jan 2006, at 00:16, Simon wrote:


This is j2se client (plain java). I thought as well that I can not get
connection factory from jndi outside container; However active-mq  
website
(http://www.activemq.org/Geronimo) says it is possible; (Apparently  
they
connect to the jms server for jndi lookup). But they gloss over the  
name of

the connection factory, and I could not make it work.

Simon


Is this a J2EE application client (using the client container) or a
"plain Java" standalone client?  If you have a J2SE client I don't
think there's any way to access JMS or JDBC resources in JNDI; for an
application client using the client container I believe you can
essentailly deploy the JMS resource group as part of your client
application deployment plan so it runs in the client environment, but
I haven't worked through this myself.

Thanks,
  Aaron

On 1/24/06, Simon <[EMAIL PROTECTED]> wrote:
I'm trying to lookup jms connection factory from the standalone  
client. I
can not figure out how to specify jms connection-factory jndi  
name in my
client. I looked at the active-mq website but their instructions  
did not

work for me. Any suggestions?

Simon







James
---
http://radio.weblogs.com/0112098/

RE: C++ Client: Character encoding

2006-01-25 Thread Mats Forslöf

Ok, thanks!

Regards,
Mats 

-Original Message-
From: Hiram Chirino [mailto:[EMAIL PROTECTED] 
Sent: den 24 januari 2006 17:58
To: activemq-dev@geronimo.apache.org
Subject: Re: C++ Client: Character encoding

Hi Matts,

We always use UTF-8

Regards,
Hiram

On Jan 24, 2006, at 10:11 AM, Mats Forslöf wrote:

> James,
>
> What character encodings are used within ActiveMQ on the Java side?  
> The default modified UTF-8 or other? We need to match this on the C+
> + client side.
>
> Regards,
> Mats

Re: Poll: Resolve configId Versions for 1.0.1