[jira] Commented: (GERONIMO-4395) EmployeeDatasource and jdbc/EmployeeDatasource create the same files under $geronimo_install_dir/repository/console/dbpool directory

[Jack Cai (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645424#action_12645424
 ] 

Jack Cai commented on GERONIMO-4395:


I guess this is just a convention. Ivan's solution might not be good when 
commands are used to create the datasource and the user expects the name 
unchanged. I'd say the current design is OK, as long as we can improve the 
error message.


> EmployeeDatasource and jdbc/EmployeeDatasource create the same files under 
> $geronimo_install_dir/repository/console/dbpool directory
> 
>
> Key: GERONIMO-4395
> URL: https://issues.apache.org/jira/browse/GERONIMO-4395
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1.3
> Environment: Any platform
>Reporter: viola.lu
>Priority: Minor
> Attachments: Geronimo-4395.patch
>
>
> Steps:
> 1.Login geronimo, go to database pool, create a "EmployeeDatasource" 
> datasource with any db type.
> 2.create another "jdbc/EmployeeDatasource" datasource with any db type. But 
> some read error display that
> EmployeeDatasource has existed in database pool.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Updates to Geronimo 2.2 documentation

[wei zhang]

Hi all,

Recently we have seen updates to the Geronimo 2.2 doc.

We have been studying the Geronimo 2.2 release roadmap and analyzing
what should be added/changed to the doc. We'll soon add some skeleton
topics based on our understanding and analysis of the new/changed
features. We'll definitely need help from the community to add more
flesh and blood to the doc.

Thanks.

[BUILD] trunk: Failed for Revision: 711789

[gawor]

Geronimo Revision: 711789 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081106/build-0300.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081106
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 44 minutes 53 seconds
[INFO] Finished at: Thu Nov 06 03:51:28 EST 2008
[INFO] Final Memory: 406M/1024M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081106/logs-0300-tomcat/test.log
 
 
Booting Geronimo Kernel (in Java 1.5.0_12)...
Module  1/75 org.apache.geronimo.framework/gshell-framework/2.2-SNAPSHOT/car
  started in   .000s
Module  2/75 org.apache.geronimo.framework/gshell-geronimo/2.2-SNAPSHOT/car 
  started in   .000s
Module  3/75 org.apache.geronimo.framework/gshell-remote/2.2-SNAPSHOT/car   
  started in   .001s
Module  4/75 org.apache.geronimo.framework/j2ee-system/2.2-SNAPSHOT/car 
  started in   .000s
Module  5/75 org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car   
  started in   .000s
Module  6/75 org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car  
  started in   .263s
Module  7/75 org.apache.geronimo.configs/sharedlib/2.2-SNAPSHOT/car 
  started in   .012s
Module  8/75 org.apache.geronimo.framework/transformer-agent/2.2-SNAPSHOT/car   
  started in   .000s
Module  9/75 
org.apache.geronimo.plugins.classloaders/geronimo-javaee-deployment_1.1MR3_spec/2.2-SNAPSHOT/car
 started in   .000s
Module 10/75 org.apache.geronimo.framework/plugin/2.2-SNAPSHOT/car  
  started in   .889s
Module 11/75 org.apache.geronimo.framework/xmlbeans/2.2-SNAPSHOT/car
  started in   .000s
Module 12/75 
org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car  
 started in   .396s
Module 13/75 org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car   
  started in   .297s
Module 14/75 org.apache.geronimo.configs/j2ee-server/2.2-SNAPSHOT/car   
  started in   .060s
Module 15/75 org.apache.geronimo.configs/transaction/2.2-SNAPSHOT/car   
  started in   .272s
Module 16/75 
org.apache.geronimo.framework/server-security-config/2.2-SNAPSHOT/car   
 started in   .061s
Module 17/75 org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car
  started in   .002s
Module 18/75 
org.apache.geronimo.plugins.classloaders/geronimo-schema-jee_5/2.2-SNAPSHOT/car 
 started in   .000s
Module 19/75 org.apache.geronimo.configs/webservices-common/2.2-SNAPSHOT/car
  started in   .000s
Module 20/75 org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car   
  started in  2.161s
Module 21/75 org.apache.geronimo.configs/remote-deploy-tomcat/2.2-SNAPSHOT/car  
  started in   .326s
Module 22/75 
org.apache.geronimo.plugins.classloaders/xbean-finder/2.2-SNAPSHOT/car  
 started in   .000s
Module 23/75 org.apache.geronimo.configs/j2ee-deployer/2.2-SNAPSHOT/car 
  started in   .237s
Module 24/75 org.apache.geronimo.configs/connector-deployer/2.2-SNAPSHOT/car
  started in   .144s
Module 25/75 org.apache.geronimo.configs/tomcat6-deployer/2.2-SNAPSHOT/car  
  started in   .102s
Module 26/75 org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car   
  started in   .011s
Module 27/75 org.apache.geronimo.configs/hot-deployer/2.2-SNAPSHOT/car  
  started in   .529s
Module 28/75 org.apache.geronimo.configs/welcome-tomcat/2.2-SNAPSHOT/car
  started in   .095s
Module 29/75 org.apache.geronimo.configs/dojo-legacy-tomcat/2.2-SNAPSHOT/car
  started in   .065s
Module 30/75 org.apache.geronimo.configs/spring/2.2-SNAPSHOT/car
  started in   .000s
Module 31/75 org.apache.geronimo.plugins/pluto-support/2.2-SNAPSHOT/car

change log4j ConversionPattern to ISO8601

[Juergen Weber]

Not worth a JIRA: I think, the default  log4j ConversionPattern in
server-log4j.properties should be changed from ABSOLUTE to ISO8601 to have
complete dates in the log.

"Hm, was it today or yesterday this happened?"

http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/helpers/ISO8601DateFormat.html

Thanks,
Juergen

-- 
View this message in context: 
http://www.nabble.com/change-log4j-ConversionPattern-to-ISO8601-tp20357904s134p20357904.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

Re: Run Geronimo as a Windows service

[Jack Cai]

Thanks a lot Donald!

So if we make this as a plugin (well, it's really a windows exe), we will
not be able to install it to the bin directory, right? If this is the case,
then it might not be conveniet for the users to control the service using
command line.

Another option is to create different assembly configuration for different
OS. This is very easy to achieve by adding more pom.xml to the assemblies
directory. This can also help to eliminate *.sh for Windows assemblies and
*.bat for Unix/Linux assemblies. But I guess creating OS-specific build is
something that Geronimo has been avoiding to do?

- Jack Cai


2008/11/4 Donald Woods <[EMAIL PROTECTED]>

> Sounds like a good feature to consider for 2.2.
>
> Maybe we could offer it as an optional plugin, since the current zip/tar
>  files are per assembly, which means you would be including it for
> Unix/Linux/Mac users too.  It would also allow us to offer a JSW 3.2.0 (BSD
> licensed) version of the plugin, for users who wanted it instead of the
> procrun implementation.
>
>
>
> -Donald
>
>
> Jack Cai wrote:
>
>> Hi all,
>>
>> I learnt that some of our users are interested in running Geronimo as a
>> Windows service. Although there is already an option provided by the Java
>> Service Wrapper, they are more interested in seeing something similar to
>> what is provided by Tomcat. I searched the mail achive and found this old
>> discussion [1], which didn't reach a decision. Provided that we can easily
>> take the technology from Tomcat [2], I'm keen to implement this for
>> Geronimo. The advantage of using Apache Commons procrun is that -
>>
>> 1. Out-of-box experience, no need to download and install a third party
>> component;
>> 2. Tray icon that further improves usability.
>>
>> Eventually we would think to provide this "run as a service" capability
>> for Linux/Unix platforms, but Windows would be a good start. What do others
>> think? I'd volunteer to do this job if you think it's worth doing.
>>
>> -Jack Cai
>>
>> [1]
>> http://www.nabble.com/forum/ViewPost.jtp?post=591936&framed=y&skin=134 <
>> http://www.nabble.com/forum/ViewPost.jtp?post=591936&framed=y&skin=134>
>> [2] http://commons.apache.org/daemon/procrun.html
>>
>>

[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.

[Vincent MATHON (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645446#action_12645446
 ] 

Vincent MATHON commented on GERONIMO-3907:
--

I agree that exceptions on the server side should not be thrown to the client 
side since such exceptions types might not be known by the client. However, for 
unit testing purpose, it is useful to attach the root cause to the 
RollBackException. I have modified a few lines in 
org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the root 
cause in case of RollBackException and it works for my unit testing purpose (I 
have not enough background on the java transaction architecture topic to submit 
a patch for production). It would be great to define a configuration parameter 
that permits to provide the root cause to the client and keep the current 
behaviour that does not by default.

> Persistence Exception is not visible/lost for client. 
> --
>
> Key: GERONIMO-3907
> URL: https://issues.apache.org/jira/browse/GERONIMO-3907
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: persistence
>Affects Versions: 2.0.2, 2.1
> Environment: Linux, Windows
>Reporter: Ralf Baumhof
>Assignee: David Jencks
>Priority: Blocker
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> I am trying an insert on a table. The Entity class is wrong annotated, one 
> column was renamed in the table. Then the following situation occurs.  
> The call to persist(entity) is successfully, no exception is thrown. On 
> leaving the ejb container and returning to tomact a commit is performed (it's 
> a managed datasource, so container performs commit). This leads to the insert 
> on database. This insert fails, a rollback is performed. On return to the JSF 
> bean no exception can be seen by the bean. In the same class i have got a 
> query method. If i replace the call to persist with the call to the query 
> method everything works ok. The exception is thrown and is visible at the 
> client site. 
> This is the geronimo console output. The last line comes from the JSB bean 
> which reports a successful insert.
> 11:58:04,390 WARN  [Transaction] Unexpected exception from beforeCompletion; 
> transaction will roll back
>  
> org.apache.openjpa.persistence.PersistenceException: The transaction has been 
> rolled back.  See the nested exceptions for details on the errors that 
> occurred.
> at 
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107)
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954)
> at 
> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852)
> at 
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770)
> at 
> org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514)
> at 
> org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499)
> at 
> org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
> at 
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257)
> at 
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245)
> at 
> org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141)
> at 
> org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75)
> at 
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233)
> at 
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
> at 
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
> at 
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
> at 
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
> at 
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321)
> at 
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
> at $Proxy75.anlegenBenutzer(Unknown Source)
> at 
> de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

[jira] Created: (GERONIMO-4396) Fail to remote deploy war file using command: deploy --uri deployer:geronimo:jmx:// deploy /cviewer.war

[viola.lu (JIRA)]

Fail to remote deploy war file using command: deploy --uri 
deployer:geronimo:jmx:// deploy 
/cviewer.war
--

 Key: GERONIMO-4396
 URL: https://issues.apache.org/jira/browse/GERONIMO-4396
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 2.1.3
 Environment: OS:Windows
Reporter: viola.lu


Pre-requisites :
1.Start the geronimo Server on remote machine. Note: Make sure the geronimo  
Server running on remote machine is running on rmi port 1099.
 2.Edit config-substitutions.properties in geronimo _HOME/var/config and 
edit  RemoteDeployHostname=the ip address of the remote machine.
Procedure :
>From the local machine , goto the location  and execute the 
>below command .
deploy --uri deployer:geronimo:jmx:// deploy 
/cviewer.war
Provide the  and  for remote geronimo server.
Below messages on your local machine console.
"Uploading 1 file(s) to server
File upload complete (Server: OK)
1 file(s) transferred to server.  Resuming deployment operation.

java.io.filenotfound exception

c:/geronimo/var/tmp/cviewer.war


can't depoly cviewer to remote server 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4395) EmployeeDatasource and jdbc/EmployeeDatasource create the same files under $geronimo_install_dir/repository/console/dbpool directory

[Lin Sun (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645486#action_12645486
 ] 

Lin Sun commented on GERONIMO-4395:
---

I think I like the current impl better.   Having a random datasource name 
generated can be a big usability issue as this name would be needed to be 
referred in the resource ref in geronimo plans.

Also, I think this is a very rare case.   Can you submit a patch to improve the 
error message?

Lin

> EmployeeDatasource and jdbc/EmployeeDatasource create the same files under 
> $geronimo_install_dir/repository/console/dbpool directory
> 
>
> Key: GERONIMO-4395
> URL: https://issues.apache.org/jira/browse/GERONIMO-4395
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1.3
> Environment: Any platform
>Reporter: viola.lu
>Priority: Minor
> Attachments: Geronimo-4395.patch
>
>
> Steps:
> 1.Login geronimo, go to database pool, create a "EmployeeDatasource" 
> datasource with any db type.
> 2.create another "jdbc/EmployeeDatasource" datasource with any db type. But 
> some read error display that
> EmployeeDatasource has existed in database pool.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Run Geronimo as a Windows service

[David Jencks]

On Nov 6, 2008, at 3:45 AM, Jack Cai wrote:


Thanks a lot Donald!

So if we make this as a plugin (well, it's really a windows exe), we  
will not be able to install it to the bin directory, right? If this  
is the case, then it might not be conveniet for the users to control  
the service using command line.



You can build a plugin that unpacks something to the bin directory on  
installation.  The geronimo-boilerplate plugin (under assemblies) does  
nothing else.  Most or all of the *-deployer plugins unpack a schema  
into the schema directory.  You end up with 2 copies of the stuff in  
the server (one in the car, one in the unpacked location) but I  
haven't worried about this.



Another option is to create different assembly configuration for  
different OS. This is very easy to achieve by adding more pom.xml to  
the assemblies directory. This can also help to eliminate *.sh for  
Windows assemblies and *.bat for Unix/Linux assemblies. But I guess  
creating OS-specific build is something that Geronimo has been  
avoiding to do?


I would prefer to avoid this complication.

thanks
david jencks



- Jack Cai


2008/11/4 Donald Woods <[EMAIL PROTECTED]>
Sounds like a good feature to consider for 2.2.

Maybe we could offer it as an optional plugin, since the current zip/ 
tar  files are per assembly, which means you would be including it  
for Unix/Linux/Mac users too.  It would also allow us to offer a JSW  
3.2.0 (BSD licensed) version of the plugin, for users who wanted it  
instead of the procrun implementation.




-Donald


Jack Cai wrote:
Hi all,

I learnt that some of our users are interested in running Geronimo  
as a Windows service. Although there is already an option provided  
by the Java Service Wrapper, they are more interested in seeing  
something similar to what is provided by Tomcat. I searched the mail  
achive and found this old discussion [1], which didn't reach a  
decision. Provided that we can easily take the technology from  
Tomcat [2], I'm keen to implement this for Geronimo. The advantage  
of using Apache Commons procrun is that -


1. Out-of-box experience, no need to download and install a third  
party component;

2. Tray icon that further improves usability.

Eventually we would think to provide this "run as a service"  
capability for Linux/Unix platforms, but Windows would be a good  
start. What do others think? I'd volunteer to do this job if you  
think it's worth doing.


-Jack Cai

[1] http://www.nabble.com/forum/ViewPost.jtp?post=591936&framed=y&skin=134 
 


[2] http://commons.apache.org/daemon/procrun.html

[jira] Created: (GERONIMODEVTOOLS-529) Investigate removing older versions of the GEP plugins/features from our Eclipse update site on Apache

[Tim McConnell (JIRA)]

Investigate removing older versions of the GEP plugins/features from our 
Eclipse update site on Apache
--

 Key: GERONIMODEVTOOLS-529
 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-529
 Project: Geronimo-Devtools
  Issue Type: Improvement
Affects Versions: 2.2.0, 2.1.4
Reporter: Tim McConnell
Assignee: Tim McConnell
 Fix For: 2.2.0, 2.1.4




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4396) Fail to remote deploy war file using command: deploy --uri deployer:geronimo:jmx:// deploy /cviewer.war

[Jarek Gawor (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645499#action_12645499
 ] 

Jarek Gawor commented on GERONIMO-4396:
---

Did you modify the config-substitutions.properties file before or after 
starting the server? 


> Fail to remote deploy war file using command: deploy --uri 
> deployer:geronimo:jmx:// deploy 
> /cviewer.war
> --
>
> Key: GERONIMO-4396
> URL: https://issues.apache.org/jira/browse/GERONIMO-4396
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.1.3
> Environment: OS:Windows
>Reporter: viola.lu
>
> Pre-requisites :
> 1.Start the geronimo Server on remote machine. Note: Make sure the geronimo  
> Server running on remote machine is running on rmi port 1099.
>  2.Edit config-substitutions.properties in geronimo _HOME/var/config and 
> edit  RemoteDeployHostname=the ip address of the remote machine.
> Procedure :
> From the local machine , goto the location  and execute the 
> below command .
> deploy --uri deployer:geronimo:jmx:// deploy 
> /cviewer.war
> Provide the  and  for remote geronimo server.
> Below messages on your local machine console.
> "Uploading 1 file(s) to server
> File upload complete (Server: OK)
> 1 file(s) transferred to server.  Resuming deployment operation.
> java.io.filenotfound exception
> c:/geronimo/var/tmp/cviewer.war
> can't depoly cviewer to remote server 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-3316) warn but don't prevent deployment if an ear's manifest cps are messed up, and provide more info on where.

[Joe Bohn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joe Bohn reassigned GERONIMO-3316:
--

Assignee: Joe Bohn  (was: David Jencks)

> warn but don't prevent deployment if an ear's manifest cps are messed up, and 
> provide more info on where.
> -
>
> Key: GERONIMO-3316
> URL: https://issues.apache.org/jira/browse/GERONIMO-3316
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6, 2.0-M7, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.1, 2.1.1, 
> 2.1.2, 2.1.3, 2.1.4, 2.2
>Reporter: David Jencks
>Assignee: Joe Bohn
> Fix For: 2.1.4, 2.2
>
>
> DeploymentContext.getCompleteManifestClassPath figures out the whole set of 
> jars in an ear in a modules classpath.  If somethings missing it throws an 
> exception and prevents deployment.  We need a switch to be more lenient, and 
> we need to provide more info when there's a problem on which jar has the 
> problem and how we found it.
> Thanks to David Harbige on the user list for pointing out that this is a big 
> usability problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Geronimo v2.2 discussion

[Joe Bohn]

Looks like discussion on this thread has died down a bit but the clock 
is still ticking ... New Years will be here all too soon and IIUC we're 
trying to beat that clock!!



Some things in addition to what you've listed (I'll update the wiki with 
these too):

- There are a number of snapshots still in use:
  - OpenEJB
  - Axis2
  - Axiom
  - xBean
  - wadi
  - j2ee-connector spec
  - jaspi spec
  - servlet spec
  - concurrent spec
  - geronimo jaspi component
  - XmlSchema
  - woden*
  - jspc-compiler
  - and various maven plugins.
  Some of these may be just as simple as using a released version but 
others may require that we get releases from these projects (or push 
releases of those that we control).  The latter will slow us down.  I'll 
start working on removing these.
- Genesis.  I see you've already upgraded to the newly released 1.5 ... 
but there's been some talk about Genesis 2.0.  I'm fine with 1.5 but if 
folks think we need 2.0 then we need to get moving on that.
- I guess we'll have to either release a number of the plugins again or 
figure out some compatibility solution as we did for 2.1.3+.  Ideally, 
we should think about compatibility ahead of time even if we find we 
need to release some (or all) of the plugins again.  I'm specifically 
thinking of samples, server-repo, daytrader, etc...  I don't think these 
need to be concurrent with 2.2 but we need to make sure we have a plan 
that doesn't require server changes before we release the 2.2 server.
- I'm a bit worried about the TCK implications (which you've already 
mentioned).  There will be a number of issues supporting Java SE6 as 
well as some issues that I know have been out there for a while.  I 
think it will make our life easier to focus exclusively on SE6.


I've been assuming all along that you are planning to be the release 
manager for 2.2 Donald.  Is that correct?  I can help as well if you 
want to share the burden (and if nobody objects).


Joe



Donald Woods wrote:

OK, looks like we're making good progress towards a 2.2 release.
http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.2+Release+Roadmap 



Is everyone still thinking we can get 2.2 out this year (say branching 
on 11/21 with a mid-December release target)?


Seems that the major items left are:
 - Upgrade to ActiveMQ 5.1/5.2
 - EJB Portlet
 - Use GShell for all commands (and upgrade to latest version)
 - Include new TranQL connectors for Oracle RAC, MS SQL and Informix
 - Remove the old Dojo 0.4.3 usage
 - Portlets for Farm/Clustering support?
 - TCK on Java SE 5 and 6 (or do we only certify on Java SE 6?)


-Donald


Hernan Cunico wrote:

Hi All,
We kinda started to have some discussion some time ago but couldn't 
find any hit on nabble so not sure were we left it.


I added a Geronimo v2.2 Roadmap <../GMOxDEV/geronimo-v22-roadmap.html> 
page at the top of the Development section in the wiki front page, 
http://cwiki.apache.org/geronimo/ so we can resume the discussion and 
collect all our thoughts in one place. (edit access is limited to 
committers/contributors though)


Does anybody already have a list?

Cheers!
Hernan

[Heads up] SSH server in java

[Guillaume Nodet]

Over the past days, I've been working on a implementing a SSH server
in java to replace to gshell remoting bits.
The project is currently hosted at google code:
  http://code.google.com/p/sshd/

This project is based on Mina and the current status is that the ssh
protocol is in a working state, but there are still a lots of things
to iron.
I've been able to connect using openssh 5.0 and 5.1 and also jsch
(from which i borrowed from code btw) and launch an /bin/sh shell and
issue a few commands.
I'd be happy if any committer is interested to work on that to give
him commits rights on the project.

-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: Run Geronimo as a Windows service

[Kevan Miller]

On Nov 4, 2008, at 9:58 AM, Donald Woods wrote:

BTW - Since you have a CLA on file, I just added your 2 ids  
(caijunj, greensight) to the geronimo-contributor group in JIRA,  
which will allow you to assign items to yourself to work on.


Minor point of law -- an ICLA need not be a pre-requisite to being  
added to the geronimo-contributor group. An ICLA is needed for write  
access to our WIKI and, of course, commit rights to our SVN.


--kevan

[jira] Commented: (GERONIMO-4396) Fail to remote deploy war file using command: deploy --uri deployer:geronimo:jmx:// deploy /cviewer.war

[viola.lu (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645678#action_12645678
 ] 

viola.lu commented on GERONIMO-4396:


yes, i modify the local machine:
2. Edit config-substitutions.properties in geronimo _HOME/var/config and edit 
RemoteDeployHostname=the ip address of the remote machine.

Should i do some extra configuration in remote machine?Thanks

> Fail to remote deploy war file using command: deploy --uri 
> deployer:geronimo:jmx:// deploy 
> /cviewer.war
> --
>
> Key: GERONIMO-4396
> URL: https://issues.apache.org/jira/browse/GERONIMO-4396
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.1.3
> Environment: OS:Windows
>Reporter: viola.lu
>
> Pre-requisites :
> 1.Start the geronimo Server on remote machine. Note: Make sure the geronimo  
> Server running on remote machine is running on rmi port 1099.
>  2.Edit config-substitutions.properties in geronimo _HOME/var/config and 
> edit  RemoteDeployHostname=the ip address of the remote machine.
> Procedure :
> From the local machine , goto the location  and execute the 
> below command .
> deploy --uri deployer:geronimo:jmx:// deploy 
> /cviewer.war
> Provide the  and  for remote geronimo server.
> Below messages on your local machine console.
> "Uploading 1 file(s) to server
> File upload complete (Server: OK)
> 1 file(s) transferred to server.  Resuming deployment operation.
> java.io.filenotfound exception
> c:/geronimo/var/tmp/cviewer.war
> can't depoly cviewer to remote server 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4396) Fail to remote deploy war file using command: deploy --uri deployer:geronimo:jmx:// deploy /cviewer.war

[Jarek Gawor (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645681#action_12645681
 ] 

Jarek Gawor commented on GERONIMO-4396:
---

If server A is the remote machine and server B is the local machine, you only 
have to update the config-substitutions.properties file of server A with the 
public ip of the server A. There is no need to update the 
config-substitutions.properties file of the local (B) server. 




> Fail to remote deploy war file using command: deploy --uri 
> deployer:geronimo:jmx:// deploy 
> /cviewer.war
> --
>
> Key: GERONIMO-4396
> URL: https://issues.apache.org/jira/browse/GERONIMO-4396
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.1.3
> Environment: OS:Windows
>Reporter: viola.lu
>
> Pre-requisites :
> 1.Start the geronimo Server on remote machine. Note: Make sure the geronimo  
> Server running on remote machine is running on rmi port 1099.
>  2.Edit config-substitutions.properties in geronimo _HOME/var/config and 
> edit  RemoteDeployHostname=the ip address of the remote machine.
> Procedure :
> From the local machine , goto the location  and execute the 
> below command .
> deploy --uri deployer:geronimo:jmx:// deploy 
> /cviewer.war
> Provide the  and  for remote geronimo server.
> Below messages on your local machine console.
> "Uploading 1 file(s) to server
> File upload complete (Server: OK)
> 1 file(s) transferred to server.  Resuming deployment operation.
> java.io.filenotfound exception
> c:/geronimo/var/tmp/cviewer.war
> can't depoly cviewer to remote server 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Geronimo v2.2 discussion

[Donald Woods]

Thanks for chiming in.  If you can start removing some of the snapshots, 
that would be great.


I hadn't volunteered to be the RM yet, as I'll only have about 2 days a 
week to focus on a 2.2 release and I don't have TCK access (which is 
going to be a major factor for when we can get 2.2 out), but if you're 
willing to help, I'd be glad to jump in and be co-release manager with you!


I'd like to see us drive towards cutting a 2.2 release branch by 
mid-December and having the 2.2 Server, GEP and updated Docs released by 
mid-January.




-Donald


Joe Bohn wrote:
Looks like discussion on this thread has died down a bit but the clock 
is still ticking ... New Years will be here all too soon and IIUC we're 
trying to beat that clock!!



Some things in addition to what you've listed (I'll update the wiki with 
these too):

- There are a number of snapshots still in use:
  - OpenEJB
  - Axis2
  - Axiom
  - xBean
  - wadi
  - j2ee-connector spec
  - jaspi spec
  - servlet spec
  - concurrent spec
  - geronimo jaspi component
  - XmlSchema
  - woden*
  - jspc-compiler
  - and various maven plugins.
  Some of these may be just as simple as using a released version but 
others may require that we get releases from these projects (or push 
releases of those that we control).  The latter will slow us down.  I'll 
start working on removing these.
- Genesis.  I see you've already upgraded to the newly released 1.5 ... 
but there's been some talk about Genesis 2.0.  I'm fine with 1.5 but if 
folks think we need 2.0 then we need to get moving on that.
- I guess we'll have to either release a number of the plugins again or 
figure out some compatibility solution as we did for 2.1.3+.  Ideally, 
we should think about compatibility ahead of time even if we find we 
need to release some (or all) of the plugins again.  I'm specifically 
thinking of samples, server-repo, daytrader, etc...  I don't think these 
need to be concurrent with 2.2 but we need to make sure we have a plan 
that doesn't require server changes before we release the 2.2 server.
- I'm a bit worried about the TCK implications (which you've already 
mentioned).  There will be a number of issues supporting Java SE6 as 
well as some issues that I know have been out there for a while.  I 
think it will make our life easier to focus exclusively on SE6.


I've been assuming all along that you are planning to be the release 
manager for 2.2 Donald.  Is that correct?  I can help as well if you 
want to share the burden (and if nobody objects).


Joe



Donald Woods wrote:

OK, looks like we're making good progress towards a 2.2 release.
http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.2+Release+Roadmap 



Is everyone still thinking we can get 2.2 out this year (say branching 
on 11/21 with a mid-December release target)?


Seems that the major items left are:
 - Upgrade to ActiveMQ 5.1/5.2
 - EJB Portlet
 - Use GShell for all commands (and upgrade to latest version)
 - Include new TranQL connectors for Oracle RAC, MS SQL and Informix
 - Remove the old Dojo 0.4.3 usage
 - Portlets for Farm/Clustering support?
 - TCK on Java SE 5 and 6 (or do we only certify on Java SE 6?)


-Donald


Hernan Cunico wrote:

Hi All,
We kinda started to have some discussion some time ago but couldn't 
find any hit on nabble so not sure were we left it.


I added a Geronimo v2.2 Roadmap 
<../GMOxDEV/geronimo-v22-roadmap.html> page at the top of the 
Development section in the wiki front page, 
http://cwiki.apache.org/geronimo/ so we can resume the discussion and 
collect all our thoughts in one place. (edit access is limited to 
committers/contributors though)


Does anybody already have a list?

Cheers!
Hernan

[DISCUSS] Only Support Java SE 6 with Geronimo 2.2

[Donald Woods]

The time has come to make the hard decision -

Do we only build and certify Geronimo 2.2 on the Sun 1.6.0 JDK and drop 
support for running on Java SE 5?


Pros:
- Reduce testing effort to one version of Java
- Allows us to use the JAXB 2.1, JAX-WS 2.1 and wsgen tools in the JDK, 
instead of shipping those jars in our assemblies (and removes some more 
Sun RI from our assemblies)  :-)

- Keeps us current on the latest Java release
- All major platforms have a Java SE 6 solution:
  - Sun provided 1.6.0 for Windows, Solaris, Linux on Intel/AMD
  - MacOS 10.5.x provides 1.6.0_07
  - openSUSE 11.0/11.1 users can install Sun 1.6.0_10 from build repos
  - Ubuntu 7.04 and later users can install Sun 1.6.0 from net repos
  - Fedora 9/10 comes with OpenJDK 6, but users can install Sun 1.6.0
  - IBM provides 1.6.0 SR2 for AIX, pLinux, zLinux, zOS, ...

Cons:
- Users will have to upgrade to Java SE 6 to run Geronimo 2.2
- Will require us to maintain the 2.1 branch during 2009 for any users 
who want to stay on Java SE 5


I'm for moving to a Java SE 6 only runtime for Geronimo 2.2.


-Donald

Re: Updates to Geronimo 2.2 documentation

[Donald Woods]

Thanks for the update, but please try to keep everyone in the loop (like 
 by creating a Doc Plan roadmap/todos/status under the 2.2 Roadmap 
page) and work towards incremental updates, instead of infrequent drops 
of large changes.  By keeping everyone involved in planned doc changes, 
you'll get more feedback and help from the community and hopefully won't 
end up owning all the burden like others have in the past...



-Donald


wei zhang wrote:

Hi all,

Recently we have seen updates to the Geronimo 2.2 doc.

We have been studying the Geronimo 2.2 release roadmap and analyzing
what should be added/changed to the doc. We'll soon add some skeleton
topics based on our understanding and analysis of the new/changed
features. We'll definitely need help from the community to add more
flesh and blood to the doc.

Thanks.

Re: change log4j ConversionPattern to ISO8601

[Donald Woods]

If you don't want this request to get lost, please open a JIRA and 
assign the Fix versions to 2.1.4 and 2.2.



-Donald


Juergen Weber wrote:

Not worth a JIRA: I think, the default  log4j ConversionPattern in
server-log4j.properties should be changed from ABSOLUTE to ISO8601 to have
complete dates in the log.

"Hm, was it today or yesterday this happened?"

http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/helpers/ISO8601DateFormat.html

Thanks,
Juergen

Re: [jira] Commented: (GERONIMO-4395) EmployeeDatasource and jdbc/EmployeeDatasource create the same files under $geronimo_install_dir/repository/console/dbpool directory

[Ivan]

Yes, a random artifact id may be less readable.But giving an error message
may make the uesr feel confusion, actually, the database pool name is OK, it
is different from any existing one, but the deployment failure is caused by
that an unique artifact id is needed.
I have another suggestion, after the user inputs the db pool name, and on
the second wizard page, show the user what the artifact id will be used. The
default artifact id would be replace all the slash in the dbpool name with
an underscore.
For example, if the db pool name is jdbc/TestDB, the default artifact id
would be jdbc_TestDB, we will check that whether the default artifact id has
been used, if it does, we generate a new artifact id, like jdbc_TestDB_1,
 or we just use the default one, and show it on the page, so that the user
has the opportunity to change it.
Thanks for any comment !


2008/11/6 Lin Sun (JIRA) <[EMAIL PROTECTED]>

>
>[
> https://issues.apache.org/jira/browse/GERONIMO-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645486#action_12645486]
>
> Lin Sun commented on GERONIMO-4395:
> ---
>
> I think I like the current impl better.   Having a random datasource name
> generated can be a big usability issue as this name would be needed to be
> referred in the resource ref in geronimo plans.
>
> Also, I think this is a very rare case.   Can you submit a patch to improve
> the error message?
>
> Lin
>
> > EmployeeDatasource and jdbc/EmployeeDatasource create the same files
> under $geronimo_install_dir/repository/console/dbpool directory
> >
> 
> >
> > Key: GERONIMO-4395
> > URL: https://issues.apache.org/jira/browse/GERONIMO-4395
> > Project: Geronimo
> >  Issue Type: Bug
> >  Security Level: public(Regular issues)
> >  Components: databases
> >Affects Versions: 2.1.3
> > Environment: Any platform
> >Reporter: viola.lu
> >Priority: Minor
> > Attachments: Geronimo-4395.patch
> >
> >
> > Steps:
> > 1.Login geronimo, go to database pool, create a "EmployeeDatasource"
> datasource with any db type.
> > 2.create another "jdbc/EmployeeDatasource" datasource with any db type.
> But some read error display that
> > EmployeeDatasource has existed in database pool.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>


-- 
Ivan