date:20060406

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

Dain Sundstrom updated GERONIMO-1277:
-

Assign To: (was: Dain Sundstrom)

Due to file length limitations on windows this will not be changed in the 
configId changes.

> Change group-id to org.apache.geronimo
> --
>
>  Key: GERONIMO-1277
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1277
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: buildsystem
> Versions: 1.0-M5
> Reporter: Dain Sundstrom
> Priority: Blocker
>  Fix For: 1.2

>
> We need to change our group-id to org.apache.geronimo before 1.0 comes out, 
> or else everyone's server will break when we do switch.  We must make this 
> switch when we convert to maven 2, so it is best to do it now.
> I will do this tomorrow.

-- 
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-191) Deployment of multiple modules into a single configuration

 [ http://issues.apache.org/jira/browse/GERONIMO-191?page=all ]
 
Dain Sundstrom closed GERONIMO-191:
---

Fix Version: 1.1
 (was: 1.2)
 Resolution: Won't Fix
  Assign To: Dain Sundstrom

We currently support synthetic ears to merge modules into an ear without an 
ear.  Also the internals of the deployment system support nested 
configurations, and merging configurations.  If someone wants more direct 
support from the deployment tools, please open a new issue.

> Deployment of multiple modules into a single configuration
> --
>
>  Key: GERONIMO-191
>  URL: http://issues.apache.org/jira/browse/GERONIMO-191
>  Project: Geronimo
> Type: Task

>   Components: deployment
> Versions: 1.0-M1
> Reporter: Dain Sundstrom
> Assignee: Dain Sundstrom
>  Fix For: 1.1

>
> Geronimo currently allows only a single module (ejb, war, rar) for each 
> configuration.  This is similar to ear support but would allow modules not in 
> an ear to be deployed together and multiple ears be allowed deployed as a 
> single unit.

-- 
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-289) WEB-INF/lib/* and WEB-INF/classes aren't on configuration class loader

 [ http://issues.apache.org/jira/browse/GERONIMO-289?page=all ]
 
Dain Sundstrom closed GERONIMO-289:
---

Fix Version: 1.1
 (was: 1.2)
 Resolution: Fixed

> WEB-INF/lib/* and WEB-INF/classes aren't on configuration class loader
> --
>
>  Key: GERONIMO-289
>  URL: http://issues.apache.org/jira/browse/GERONIMO-289
>  Project: Geronimo
> Type: Bug

>   Components: web
> Versions: 1.0-M2
> Reporter: Dain Sundstrom
>  Fix For: 1.1

>
> The libraries contained in a war WEB-INF/lib and classes in the 
> WEB-INF/classes directories are not added to the configuration classloader.  
> This has historically been a problem since this class loader is used to 
> resolve ejb-refs.  This means that war ejb-refs can only be used when 
> deploying an ear and the interface classes are available from another module 
> in the ear.  We could simply add libs and classes to the configuration class 
> loader, but it would make it impossible to isolate wars in the same 
> configuration.  This should be handled when we rewrite the 
> JettyConfigurationBuilder to add JSR 77 objects.

-- 
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: Cannot build 1.1 on Windows - long file paths

2006-04-06 Thread Prasad Kashyap

Now I have my project root at c:\apache and that was too deep for the
files in the target dir to be deleted.

How about, IF the clean:clean goal fails, moving the dir to be deleted
to say c:\tmp and then delete it from there ?


Cheers
Prasad.


On 4/6/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> I think we should be able to JAR up our generated stuff and that
> should get around the problem for now.  There will be some limit for
> user path lengths, but they don't have to use archive names like
> org.apache.geronimo/artifact/1.0-SNAPSHOT.ear/org.apache.geronimo.artifact-1.0-SNAPSHOT.war/...
>
> Thanks,
> Aaron
>
> On 4/6/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> > Man I hate Windows
> >
> > Anyway, if you have a real OS and list the files in an assembly, you
> > will see that the problem is caused by the combination of two
> > changes: we now keep configurations in the repository and we unpack
> > them. If you look closer you will see that the big offenders are
> > unpacked ears and wars.
> >
> > I believe the following are the longest paths in the server:
> >
> > (270)
> > geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty/1.1-
> > SNAPSHOT/daytrader-derby-jetty-1.1-SNAPSHOT.car/daytrader-web-1.1-
> > SNAPSHOT.war/META-INF/geronimo-generated/org/apache/geronimo/axis/
> > client/GenericServiceEndpointWrapper$$EnhancerByCGLIB$$36344d29.class
> > (264)
> > geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1-
> > SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console-
> > standard-1.1-SNAPSHOT.war/WEB-INF/classes/org/apache/geronimo/console/
> > databasemanager/wizard/DatabasePoolPortlet$ResourceAdapterParams.class
> >
> >
> > One thing to note here is that the longest paths are all classes
> > generated by Geronimo, nested classes in wars or compiled JSP pages.
> > Someone should look into makeing maven jar the latter two and
> > Geronimo should be creating jars when generating classes (actually we
> > should stop generating classes a head of time but that is another
> > story).
> >
> >
> >
> > Breaking down the longest path, we have:
> >
> > GeronimoName (22)
> >geronimo-1.1-SNAPSHOT
> > RepositoryPath (55)
> >repository/geronimo/daytrader-derby-jetty/1.1-SNAPSHOT
> > FileName (39)
> >daytrader-derby-jetty-1.1-SNAPSHOT.car
> > NestedPath (154)
> >daytrader-web-1.1-SNAPSHOT.war/META-INF/geronimo-generated/org/
> > apache/geronimo/axis/client/GenericServiceEndpointWrapper$
> > $EnhancerByCGLIB$$36344d29.class
> >
> >
> >
> > The first thing to note is if we simply replace "SNAPSHOT" with "0",
> > we drop 28 characters which makes the longest path 242; not enough
> > head room.  Of course, when we switch our groupId to the maven
> > standard org.apache.geronimo we eat up 20 more characters.  If we are
> > going to unpack war files there is very little we can do about the
> > NestedPath, so we have very few choices left.  If we simply combine
> > combine ${GeronimoName}/${FileName}/${NestedPath} we are up to 115
> > characters leaving only 41 characters for anything else, but when you
> > add back the 28 from "SNAPSHOT", you get to a more comfortable level.
> >
> > I think if we combine this problem with Sachin's request for a
> > separate directory for applications, we could do something like this:
> >
> > ${GeronimoName}/apps/${FileName}/${NestedPath}
> >
> > There are several problems with this.  I think users will confuse the
> > hot-deploy directory "deploy" with the "apps" directory [1].  Then
> > again, if you look at the problem configurations they are all apps
> > the users may want to remove (sample apps and the console), so may be
> > we should just put these in the hot-deploy directory.  Another
> > problem is that it will be much more difficult to query a repository
> > without a directory structure.  The server will basically have to
> > read the configuration from these apps on startup to determine what
> > they are, so again we may just want to use the hot-deploy directory.
> > I'm not a fan of the hot-deploy directory, but I'm not sure there is
> > a better solution.
> >
> > Again I renew my hate of Windows...
> > /me shakes his fist at Bill Gates
> >
> > -dain
> >
> >
> > [1] As a side issue, I prefer the name "apps" because it will be most
> > familiar to tomcat users.
> >
> >
> >
>

Re: Build fails trying to delete a long dir path

2006-04-06 Thread Prasad Kashyap

Terribly sorry for this thread proliferation. Now I see  the other
thread  with the same subject. Consider this thread closed.

Will write to that..
http://www.mail-archive.com/dev@geronimo.apache.org/msg20016.html

Cheers
Prasad

On 4/6/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> Geronimo version 1.1.
> Build platform: Win XP
>
> While building the j2ee-installer assembly, it executes a clean:clean
> goal that tries to delete the target directory. Now if a target dir
> exists from before, there are chances that the clean goal might fail
> based on how deep down the project root is.
>
> Now I have my project root at c:\apache and that was too deep for the
> files in the target dir to be deleted.
>
> Is this a known problem ? Is there a JIRA to fix this ? One solution I
> can think of, IF the clean:clean goal fails, is  to move the dir to be
> deleted to say c:\tmp and then delete it from there.
>
>
> multiproject:install-callback:
> [echo] Running assemble:install for Geronimo Assembly for an
> IZPack Installer
> assemble:install:
> clean:clean:
> [delete] Deleting directory
> C:\Apache\geronimo\assemblies\j2ee-installer\target
>
> BUILD FAILED
> File.. C:\Apache\geronimo\maven.xml
> Element... maven:reactor
> Line.. 63
> Column -1
> Unable to obtain goal [multiproject:install-callback] -- C:\Documents
> and 
> Settings\Administrator\.maven\cache\maven-clean-plugin-1.3\plugin.jelly:30:-1:
>  Unable to delete directory
> C:\Apache\geronimo\assemblies\j2ee-installer\target
> Total time   : 4 minutes 30 seconds
> Finished at  : Thursday, April 6, 2006 9:35:17 PM EDT
>
> Cheers
> Prasad
>

Build fails trying to delete a long dir path

2006-04-06 Thread Prasad Kashyap

Geronimo version 1.1.
Build platform: Win XP

While building the j2ee-installer assembly, it executes a clean:clean
goal that tries to delete the target directory. Now if a target dir
exists from before, there are chances that the clean goal might fail
based on how deep down the project root is.

Now I have my project root at c:\apache and that was too deep for the
files in the target dir to be deleted.

Is this a known problem ? Is there a JIRA to fix this ? One solution I
can think of, IF the clean:clean goal fails, is  to move the dir to be
deleted to say c:\tmp and then delete it from there.


multiproject:install-callback:
[echo] Running assemble:install for Geronimo Assembly for an
IZPack Installer
assemble:install:
clean:clean:
[delete] Deleting directory
C:\Apache\geronimo\assemblies\j2ee-installer\target

BUILD FAILED
File.. C:\Apache\geronimo\maven.xml
Element... maven:reactor
Line.. 63
Column -1
Unable to obtain goal [multiproject:install-callback] -- C:\Documents
and 
Settings\Administrator\.maven\cache\maven-clean-plugin-1.3\plugin.jelly:30:-1:
 Unable to delete directory
C:\Apache\geronimo\assemblies\j2ee-installer\target
Total time   : 4 minutes 30 seconds
Finished at  : Thursday, April 6, 2006 9:35:17 PM EDT

Cheers
Prasad

Re: [jira] Unassigned issues (273) as of 2006-04-06

2006-04-06 Thread Jeff Genender

-0 on jira to scm.  scm has *much* more messages plowing through it.  I
will never catch jira's there.  JIRA to dev seems to be a great way to
alert developers of issues that need fixing.  I personally am able to
see anything that affects code that I produced through the jiras on dev.
 But thats my selfish view ;-)

Jeff

Dain Sundstrom wrote:
> David can you change the tag [jira] on the subject to something else.  I
> filter all [jira] notices into the trash^H^H^^H^H jira folder :)
> 
> Actually what does everyone think of redirecting jira notices to the scm
> list, and leave David's awesome summary reports coming to this list?
> 
> -dain
> 
> On Apr 6, 2006, at 4:20 PM, David Blevins wrote:
> 
>> All, we have a new report to be embarrassed ^H^H^H motivated by.
>>
>>
>> If you have a moment, look in the 1+ year section and see if there
>> aren't some items which can just be deleted.
>>
>> -David
>>
>> On Apr 6, 2006, at 3:53 PM, [EMAIL PROTECTED] wrote:
>>
>>>
>>>  * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>>  1 WEEK (8 issues)
>>>
>>>  * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>>   Key 
>>> SummaryReporter   Created
>>>  GERONIMO-1800 SPECjAppServer2004 Deployment
>>> Descriptors   Vasily Zakharov Apr 03, 2006
>>>  GERONIMO-1804 The name of JNDI/RMI service provider is hardcoded in
>>> the sources.  Andrey Pavlenko Apr 05, 2006
>>>  GERONIMO-1805 org.apache.geronimo.directory.RunningTest hangs on BEA
>>> Jrockit VMs  Alexei Zakharov Apr 05, 2006
>>>  GERONIMO-1815 Remove empty config-store
>>> directory Dain Sundstrom  Apr 06,
>>> 2006
>>>  GERONIMO-1792 Ant Tasks Mirror of Maven
>>> Plugins   Heinie Barnard  Mar 30,
>>> 2006
>>>  GERONIMO-1801 Restart/Shutdown functionality for Geronimo when using
>>> Java Service Mario Ruebsam   Apr 04, 2006
>>>Wrapper
>>>  GERONIMO-1812 When already deployed application is hot deployed once
>>> gain , ServerMansoor Apr 06, 2006
>>>doesn't delete the module from hot deployed directory
>>>  GERONIMO-1813 When already deployed application is hot deployed once
>>> gain , ServerMansoor Apr 06, 2006
>>>doesn't delete the module from hot deployed directory
>>>
>>>  * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>>  30 DAYS (37 issues)
>>>
>>>  * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>>   Key  
>>> SummaryReporter  Created
>>>  GERONIMO-1733 Module migration to Maven 2:
>>> mail Jacek Laskowski   Mar 09, 2006
>>>  GERONIMO-1734 Module migration to Maven 2:
>>> naming-builder   Jacek Laskowski   Mar 09, 2006
>>>  GERONIMO-1735 Module migration to Maven 2:
>>> transaction  Jacek Laskowski   Mar 09, 2006
>>>  GERONIMO-1736 Module migration to Maven 2:
>>> web-builder  Jacek Laskowski   Mar 09, 2006
>>>  GERONIMO-1739 Plugin migration to Maven 2:
>>> geronimo-izpack-plugin   Jacek Laskowski   Mar 09, 2006
>>>  GERONIMO-1747 HTTP-methods
>>> checks   Ilya
>>> Platonov Mar 16, 2006
>>>  GERONIMO-1749 Server Logs portlet - Web Access Log Viewer
>>> improvements  Vamsavardhana Reddy   Mar 17, 2006
>>>  GERONIMO-1726 Module migration to Maven 2:
>>> common   Jacek Laskowski   Mar 09, 2006
>>>  GERONIMO-1727 Module migration to Maven2:
>>> connector Jacek Laskowski   Mar 09, 2006
>>>  GERONIMO-1752 JMS Server portlet - Edits to JMS Network Listener are
>>> lost upon  Vamsavardhana Reddy   Mar 20, 2006
>>>server restart
>>>  GERONIMO-1751 Deployment of ear with external plan using "Deploy
>>> New" console   John Sisson   Mar 20, 2006
>>>option caused FileNotFoundException
>>>  GERONIMO-1756 Move from 1.1-dev version of commons-fileupload to
>>> version 1.1John Sisson   Mar 20, 2006
>>>  GERONIMO-1758 Can not use Realm with SQL database over connection
>>> pool  Torsten Markwardt Mar 21, 2006
>>>  GERONIMO-1761 Change geronimo-util module to geronimo-crypto, give
>>> credit where Aaron Mulder  Mar 22, 2006
>>>credit is due
>>>  GERONIMO-1762 Create a derby network /embedded XA datasource via
>>> admin console  Lin Sun   Mar 23, 2006
>>>fail
>>>  GERONIMO-1763 default config.xml does not list Jetty AJP
>>> connector  Aaron Mulder  Mar 23, 2006
>>>  GERONIMO-1786 JMS Listeners for protocols activeio, peer and
>>> openwire fail to   Donald Woods  Mar 28, 2006
>>>start
>>>  GERONIMO

Deploy Tool Problems in 1.1

It looks like there was a lot of breakage in the deploy tool in 1.1. 
I've started working through that.  At the moment, there's a problem
in redeploy.  Dain, if you could take a look, that'd be great.  To
reproduce:

 - start Geronimo
 - in another console, go to applications/console-ear and run:

java -jar 
../../assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/bin/deployer.jar
--verbose redeploy target/geronimo-console-*.ear
../../configs/console-jetty/target/plan/plan.xml


I get this on the server console:

22:32:13,602 ERROR [LocalAttributeManager] Trying to stop unknown
configuration: 
geronimo/webconsole-jetty_geronimo-console-framework-1.1-SNAPSHOT.war/1.1-SNAPSHOT/car
22:32:13,906 ERROR [LocalAttributeManager] Trying to stop unknown
configuration: 
geronimo/webconsole-jetty_geronimo-console-standard-1.1-SNAPSHOT.war/1.1-SNAPSHOT/car

And this on the client console:

Stopped geronimo/webconsole-jetty/1.1-SNAPSHOT/car
Unloaded geronimo/webconsole-jetty/1.1-SNAPSHOT/car
Uninstalled geronimo/webconsole-jetty/1.1-SNAPSHOT/car
Error: Operation failed: Unable to initialize webapp GBean
org.apache.geronimo.common.DeploymentException: Unable to initialize
webapp GBean
at
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:720)
at
org.apache.geronimo.jetty.deployment.JettyModuleBuilder$$FastClassByCGLIB$$b30bba8a.invoke()
...
Caused by: org.apache.geronimo.kernel.GBeanAlreadyExistsException:
geronimo/webconsole-jetty/1.1-SNAPSHOT/car?J2EEApplication=geronimo/webconsole-jetty/1.1-SNAPSHOT/car,WebModule=geronimo-console-framework-1.1-SNAPSHOT.war,j2eeType=Servlet,name=jsp
at
org.apache.geronimo.kernel.config.Configuration.addGBean(Configuration.java:497)
at
org.apache.geronimo.deployment.DeploymentContext.addGBean(DeploymentContext.java:195)
at
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:672)
... 70 more


Thanks,
Aaron

Re: [jira] Unassigned issues (273) as of 2006-04-06

2006-04-06 Thread Jason Dillon

+1 for jiras to not go to the dev list. 

--jason


-Original Message-
From: Dain Sundstrom <[EMAIL PROTECTED]>
Date: Thu, 6 Apr 2006 17:03:53 
To:dev@geronimo.apache.org
Subject: Re: [jira] Unassigned issues (273) as of 2006-04-06

David can you change the tag [jira] on the subject to something  
else.  I filter all [jira] notices into the trash^H^H^^H^H jira  
folder :)

Actually what does everyone think of redirecting jira notices to the  
scm list, and leave David's awesome summary reports coming to this list?

-dain

On Apr 6, 2006, at 4:20 PM, David Blevins wrote:

> All, we have a new report to be embarrassed ^H^H^H motivated by.
>
>
> If you have a moment, look in the 1+ year section and see if there  
> aren't some items which can just be deleted.
>
> -David
>
> On Apr 6, 2006, at 3:53 PM, [EMAIL PROTECTED] wrote:
>
>>
>>  * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>
>>  1 WEEK (8 issues)
>>
>>  * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>
>>   Key   
>> SummaryReporter   Created
>>  GERONIMO-1800 SPECjAppServer2004 Deployment  
>> Descriptors   Vasily Zakharov Apr 03,  
>> 2006
>>  GERONIMO-1804 The name of JNDI/RMI service provider is hardcoded  
>> in the sources.  Andrey Pavlenko Apr 05, 2006
>>  GERONIMO-1805 org.apache.geronimo.directory.RunningTest hangs on  
>> BEA Jrockit VMs  Alexei Zakharov Apr 05, 2006
>>  GERONIMO-1815 Remove empty config-store  
>> directory Dain Sundstrom  Apr  
>> 06, 2006
>>  GERONIMO-1792 Ant Tasks Mirror of Maven  
>> Plugins   Heinie Barnard  Mar  
>> 30, 2006
>>  GERONIMO-1801 Restart/Shutdown functionality for Geronimo when  
>> using Java Service Mario Ruebsam   Apr 04, 2006
>>Wrapper
>>  GERONIMO-1812 When already deployed application is hot deployed  
>> once gain , ServerMansoor Apr 06, 2006
>>doesn't delete the module from hot deployed directory
>>  GERONIMO-1813 When already deployed application is hot deployed  
>> once gain , ServerMansoor Apr 06, 2006
>>doesn't delete the module from hot deployed directory
>>
>>  * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>
>>  30 DAYS (37 issues)
>>
>>  * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>
>>   Key
>> SummaryReporter  Created
>>  GERONIMO-1733 Module migration to Maven 2:  
>> mail Jacek Laskowski   Mar 09,  
>> 2006
>>  GERONIMO-1734 Module migration to Maven 2: naming- 
>> builder   Jacek Laskowski   Mar 09, 2006
>>  GERONIMO-1735 Module migration to Maven 2:  
>> transaction  Jacek Laskowski   Mar 09,  
>> 2006
>>  GERONIMO-1736 Module migration to Maven 2: web- 
>> builder  Jacek Laskowski   Mar 09, 2006
>>  GERONIMO-1739 Plugin migration to Maven 2: geronimo-izpack- 
>> plugin   Jacek Laskowski   Mar 09, 2006
>>  GERONIMO-1747 HTTP-methods  
>> checks   Ilya  
>> Platonov Mar 16, 2006
>>  GERONIMO-1749 Server Logs portlet - Web Access Log Viewer  
>> improvements  Vamsavardhana Reddy   Mar 17, 2006
>>  GERONIMO-1726 Module migration to Maven 2:  
>> common   Jacek Laskowski   Mar 09,  
>> 2006
>>  GERONIMO-1727 Module migration to Maven2:  
>> connector Jacek Laskowski   Mar  
>> 09, 2006
>>  GERONIMO-1752 JMS Server portlet - Edits to JMS Network Listener  
>> are lost upon  Vamsavardhana Reddy   Mar 20, 2006
>>server restart
>>  GERONIMO-1751 Deployment of ear with external plan using "Deploy  
>> New" console   John Sisson   Mar 20, 2006
>>option caused FileNotFoundException
>>  GERONIMO-1756 Move from 1.1-dev version of commons-fileupload to  
>> version 1.1John Sisson   Mar 20, 2006
>>  GERONIMO-1758 Can not use Realm with SQL database over connection  
>> pool  Torsten Markwardt Mar 21, 2006
>>  GERONIMO-1761 Change geronimo-util module to geronimo-crypto,  
>> give credit where Aaron Mulder  Mar 22, 2006
>>credit is due
>>  GERONIMO-1762 Create a derby network /embedded XA datasource via  
>> admin console  Lin Sun   Mar 23, 2006
>>fail
>>  GERONIMO-1763 default config.xml does not list Jetty AJP  
>> connector  Aaron Mulder  Mar 23, 2006
>>  GERONIMO-1786 JMS Listeners for protocols activeio, peer and  
>> openwire fail to   Donald Woods  Mar 28, 2006
>>start
>>  GERONIMO-1789 Exceptions while adding SQL Realm thru Admin  
>> Console  Vamsavardhana Reddy   Mar 29, 2006
>>  GERONI

Re: [jira] Unassigned issues (273) as of 2006-04-06

2006-04-06 Thread John Sisson


Dain Sundstrom wrote:
David can you change the tag [jira] on the subject to something else.  
I filter all [jira] notices into the trash^H^H^^H^H jira folder :)



+1 to changing the tag if possible.

How many other people are filtering JIRAs to trash?  I wonder whether 
this could be contributing to us having so many open issues, because 
those people filtering will only see issues if they go out of their way 
to look for them (e.g. via recently created/updated screen).  It may 
also increase the possibility that problems reported via JIRA rather 
than an email to the dev list will be missed or have a slow response.


I color code my JIRA and scm emails in thunderbird to make it easy to 
identify emails.  I'm not sure how many other email clients allow this.
Actually what does everyone think of redirecting jira notices to the 
scm list, and leave David's awesome summary reports coming to this list?
How about having an issues AT geronimo.apache.org address (Maven has an 
issues mailing list)?  This would allow users (who may not contribute 
code) who want to see issues and their progress without having to 
subscribe to the SCM list that can have large posts to it.


Regards,

John


-dain

On Apr 6, 2006, at 4:20 PM, David Blevins wrote:


All, we have a new report to be embarrassed ^H^H^H motivated by.


If you have a moment, look in the 1+ year section and see if there 
aren't some items which can just be deleted.


-David

On Apr 6, 2006, at 3:53 PM, [EMAIL PROTECTED] wrote:



 * * * * * * * * * * * * * * * * * * * * * * * * * * *

 1 WEEK (8 issues)

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Key  
SummaryReporter   Created
 GERONIMO-1800 SPECjAppServer2004 Deployment 
Descriptors   Vasily Zakharov Apr 03, 2006
 GERONIMO-1804 The name of JNDI/RMI service provider is hardcoded in 
the sources.  Andrey Pavlenko Apr 05, 2006
 GERONIMO-1805 org.apache.geronimo.directory.RunningTest hangs on 
BEA Jrockit VMs  Alexei Zakharov Apr 05, 2006
 GERONIMO-1815 Remove empty config-store 
directory Dain Sundstrom  Apr 
06, 2006
 GERONIMO-1792 Ant Tasks Mirror of Maven 
Plugins   Heinie Barnard  Mar 
30, 2006
 GERONIMO-1801 Restart/Shutdown functionality for Geronimo when 
using Java Service Mario Ruebsam   Apr 04, 2006

   Wrapper
 GERONIMO-1812 When already deployed application is hot deployed 
once gain , ServerMansoor Apr 06, 2006

   doesn't delete the module from hot deployed directory
 GERONIMO-1813 When already deployed application is hot deployed 
once gain , ServerMansoor Apr 06, 2006

   doesn't delete the module from hot deployed directory

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

 30 DAYS (37 issues)

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Key   
SummaryReporter  Created
 GERONIMO-1733 Module migration to Maven 2: 
mail Jacek Laskowski   Mar 09, 2006
 GERONIMO-1734 Module migration to Maven 2: 
naming-builder   Jacek Laskowski   Mar 09, 2006
 GERONIMO-1735 Module migration to Maven 2: 
transaction  Jacek Laskowski   Mar 09, 2006
 GERONIMO-1736 Module migration to Maven 2: 
web-builder  Jacek Laskowski   Mar 09, 2006
 GERONIMO-1739 Plugin migration to Maven 2: 
geronimo-izpack-plugin   Jacek Laskowski   Mar 09, 2006
 GERONIMO-1747 HTTP-methods 
checks   Ilya 
Platonov Mar 16, 2006
 GERONIMO-1749 Server Logs portlet - Web Access Log Viewer 
improvements  Vamsavardhana Reddy   Mar 17, 2006
 GERONIMO-1726 Module migration to Maven 2: 
common   Jacek Laskowski   Mar 09, 2006
 GERONIMO-1727 Module migration to Maven2: 
connector Jacek Laskowski   Mar 09, 
2006
 GERONIMO-1752 JMS Server portlet - Edits to JMS Network Listener 
are lost upon  Vamsavardhana Reddy   Mar 20, 2006

   server restart
 GERONIMO-1751 Deployment of ear with external plan using "Deploy 
New" console   John Sisson   Mar 20, 2006

   option caused FileNotFoundException
 GERONIMO-1756 Move from 1.1-dev version of commons-fileupload to 
version 1.1John Sisson   Mar 20, 2006
 GERONIMO-1758 Can not use Realm with SQL database over connection 
pool  Torsten Markwardt Mar 21, 2006
 GERONIMO-1761 Change geronimo-util module to geronimo-crypto, give 
credit where Aaron Mulder  Mar 22, 2006

   credit is due
 GERONIMO-1762 Create a derby network /embedded XA datasource via 
admin console  Lin Sun   Mar 23, 2006

   fail
 GER

Re: Cannot build 1.1 on Windows - long file paths

I think we should be able to JAR up our generated stuff and that
should get around the problem for now.  There will be some limit for
user path lengths, but they don't have to use archive names like
org.apache.geronimo/artifact/1.0-SNAPSHOT.ear/org.apache.geronimo.artifact-1.0-SNAPSHOT.war/...

Thanks,
Aaron

On 4/6/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Man I hate Windows
>
> Anyway, if you have a real OS and list the files in an assembly, you
> will see that the problem is caused by the combination of two
> changes: we now keep configurations in the repository and we unpack
> them. If you look closer you will see that the big offenders are
> unpacked ears and wars.
>
> I believe the following are the longest paths in the server:
>
> (270)
> geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty/1.1-
> SNAPSHOT/daytrader-derby-jetty-1.1-SNAPSHOT.car/daytrader-web-1.1-
> SNAPSHOT.war/META-INF/geronimo-generated/org/apache/geronimo/axis/
> client/GenericServiceEndpointWrapper$$EnhancerByCGLIB$$36344d29.class
> (264)
> geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1-
> SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console-
> standard-1.1-SNAPSHOT.war/WEB-INF/classes/org/apache/geronimo/console/
> databasemanager/wizard/DatabasePoolPortlet$ResourceAdapterParams.class
>
>
> One thing to note here is that the longest paths are all classes
> generated by Geronimo, nested classes in wars or compiled JSP pages.
> Someone should look into makeing maven jar the latter two and
> Geronimo should be creating jars when generating classes (actually we
> should stop generating classes a head of time but that is another
> story).
>
>
>
> Breaking down the longest path, we have:
>
> GeronimoName (22)
>geronimo-1.1-SNAPSHOT
> RepositoryPath (55)
>repository/geronimo/daytrader-derby-jetty/1.1-SNAPSHOT
> FileName (39)
>daytrader-derby-jetty-1.1-SNAPSHOT.car
> NestedPath (154)
>daytrader-web-1.1-SNAPSHOT.war/META-INF/geronimo-generated/org/
> apache/geronimo/axis/client/GenericServiceEndpointWrapper$
> $EnhancerByCGLIB$$36344d29.class
>
>
>
> The first thing to note is if we simply replace "SNAPSHOT" with "0",
> we drop 28 characters which makes the longest path 242; not enough
> head room.  Of course, when we switch our groupId to the maven
> standard org.apache.geronimo we eat up 20 more characters.  If we are
> going to unpack war files there is very little we can do about the
> NestedPath, so we have very few choices left.  If we simply combine
> combine ${GeronimoName}/${FileName}/${NestedPath} we are up to 115
> characters leaving only 41 characters for anything else, but when you
> add back the 28 from "SNAPSHOT", you get to a more comfortable level.
>
> I think if we combine this problem with Sachin's request for a
> separate directory for applications, we could do something like this:
>
> ${GeronimoName}/apps/${FileName}/${NestedPath}
>
> There are several problems with this.  I think users will confuse the
> hot-deploy directory "deploy" with the "apps" directory [1].  Then
> again, if you look at the problem configurations they are all apps
> the users may want to remove (sample apps and the console), so may be
> we should just put these in the hot-deploy directory.  Another
> problem is that it will be much more difficult to query a repository
> without a directory structure.  The server will basically have to
> read the configuration from these apps on startup to determine what
> they are, so again we may just want to use the hot-deploy directory.
> I'm not a fan of the hot-deploy directory, but I'm not sure there is
> a better solution.
>
> Again I renew my hate of Windows...
> /me shakes his fist at Bill Gates
>
> -dain
>
>
> [1] As a side issue, I prefer the name "apps" because it will be most
> familiar to tomcat users.
>
>
>

[jira] Created: (AMQ-682) several functions spelled wrong, impairs code readability

2006-04-06 Thread Andrew Lusk (JIRA)

several functions spelled wrong, impairs code readability
-

 Key: AMQ-682
 URL: https://issues.apache.org/activemq/browse/AMQ-682
 Project: ActiveMQ
Type: Bug

Reporter: Andrew Lusk
Priority: Trivial


In the OpenWire marshalling code / scripts for Java, s/Unmarsal/Unmarshal/.
In OpenWireFormat.java, WireFormatNegotiator.java, and 
OpenWireFormatFactory.java, s/negociat/negotiate/.

Nitpicks, yes, but the cause of some wasted time looking around for functions 
that didn't exist.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (AMQ-681) Tight encoding not the default; wire format negotiation needs work

2006-04-06 Thread Andrew Lusk (JIRA)

Tight encoding not the default; wire format negotiation needs work
--

 Key: AMQ-681
 URL: https://issues.apache.org/activemq/browse/AMQ-681
 Project: ActiveMQ
Type: Bug

  Components: Broker  
Reporter: Andrew Lusk


In OpenWireFormat.java, tightEncoding defaults to false, when, since it's the 
historical format, it should be true.

Wire format negotiation isn't really negotiation.  Since the broker defaults to 
loose encoding, it sends a loosely-encoded WireFormatInfo message to connecting 
clients, and expects loosely-encoded WireFormatInfo messages from them.  This 
not only enforces that clients implement loose marshalling and unmarshalling, 
but fails when the client sends a well-formatted but tightly-encoded 
WireFormatInfo message.

The broker fails in this case because it assumes that the client and broker 
both have the same concept of what encoding is the default, when in actuality 
the encoding of a message should be part of the actual message, allowing the 
broker to handle clients who prefer either format (and may not have the other 
format even implemented).

The broker should also only ever send messages in the format asked for by the 
client - it should wait to send a WireFormatInfo until it has received one from 
the client indicating its preferred format.

I suggest two changes:

  * adding a leading byte to all messages indicating their encoding
  * the broker should wait to send a WireFormatInfo until it has received one 
from the connecting client, whose preferences override all broker defaults for 
that connection

The requirement that the server and client have shared, non-obvious information 
from the beginning (like which encoding is default) causes ugly problem in the 
broker like this, when it gets a message of a type it didn't expect:

Exception in thread "tcp:///127.0.0.1:54316" 
java.lang.IllegalArgumentException: Invalid version: 1297154048, could not load 
org.apache.activemq.openwire.v1297154048.MarshallerFactory


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Unassigned issues (273) as of 2006-04-06

2006-04-06 Thread David Blevins



On Apr 6, 2006, at 5:03 PM, Dain Sundstrom wrote:

David can you change the tag [jira] on the subject to something  
else.  I filter all [jira] notices into the trash^H^H^^H^H jira  
folder :)


Actually what does everyone think of redirecting jira notices to  
the scm list, and leave David's awesome summary reports coming to  
this list?




I'd be up for the jira stuff going to the scm list.  Didn't it used  
to be that way back in the incubator days?


-David

Re: [jira] Unassigned issues (273) as of 2006-04-06

David can you change the tag [jira] on the subject to something  
else.  I filter all [jira] notices into the trash^H^H^^H^H jira  
folder :)


Actually what does everyone think of redirecting jira notices to the  
scm list, and leave David's awesome summary reports coming to this list?


-dain

On Apr 6, 2006, at 4:20 PM, David Blevins wrote:


All, we have a new report to be embarrassed ^H^H^H motivated by.


If you have a moment, look in the 1+ year section and see if there  
aren't some items which can just be deleted.


-David

On Apr 6, 2006, at 3:53 PM, [EMAIL PROTECTED] wrote:



 * * * * * * * * * * * * * * * * * * * * * * * * * * *

 1 WEEK (8 issues)

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Key   
SummaryReporter   Created
 GERONIMO-1800 SPECjAppServer2004 Deployment  
Descriptors   Vasily Zakharov Apr 03,  
2006
 GERONIMO-1804 The name of JNDI/RMI service provider is hardcoded  
in the sources.  Andrey Pavlenko Apr 05, 2006
 GERONIMO-1805 org.apache.geronimo.directory.RunningTest hangs on  
BEA Jrockit VMs  Alexei Zakharov Apr 05, 2006
 GERONIMO-1815 Remove empty config-store  
directory Dain Sundstrom  Apr  
06, 2006
 GERONIMO-1792 Ant Tasks Mirror of Maven  
Plugins   Heinie Barnard  Mar  
30, 2006
 GERONIMO-1801 Restart/Shutdown functionality for Geronimo when  
using Java Service Mario Ruebsam   Apr 04, 2006

   Wrapper
 GERONIMO-1812 When already deployed application is hot deployed  
once gain , ServerMansoor Apr 06, 2006

   doesn't delete the module from hot deployed directory
 GERONIMO-1813 When already deployed application is hot deployed  
once gain , ServerMansoor Apr 06, 2006

   doesn't delete the module from hot deployed directory

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

 30 DAYS (37 issues)

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Key
SummaryReporter  Created
 GERONIMO-1733 Module migration to Maven 2:  
mail Jacek Laskowski   Mar 09,  
2006
 GERONIMO-1734 Module migration to Maven 2: naming- 
builder   Jacek Laskowski   Mar 09, 2006
 GERONIMO-1735 Module migration to Maven 2:  
transaction  Jacek Laskowski   Mar 09,  
2006
 GERONIMO-1736 Module migration to Maven 2: web- 
builder  Jacek Laskowski   Mar 09, 2006
 GERONIMO-1739 Plugin migration to Maven 2: geronimo-izpack- 
plugin   Jacek Laskowski   Mar 09, 2006
 GERONIMO-1747 HTTP-methods  
checks   Ilya  
Platonov Mar 16, 2006
 GERONIMO-1749 Server Logs portlet - Web Access Log Viewer  
improvements  Vamsavardhana Reddy   Mar 17, 2006
 GERONIMO-1726 Module migration to Maven 2:  
common   Jacek Laskowski   Mar 09,  
2006
 GERONIMO-1727 Module migration to Maven2:  
connector Jacek Laskowski   Mar  
09, 2006
 GERONIMO-1752 JMS Server portlet - Edits to JMS Network Listener  
are lost upon  Vamsavardhana Reddy   Mar 20, 2006

   server restart
 GERONIMO-1751 Deployment of ear with external plan using "Deploy  
New" console   John Sisson   Mar 20, 2006

   option caused FileNotFoundException
 GERONIMO-1756 Move from 1.1-dev version of commons-fileupload to  
version 1.1John Sisson   Mar 20, 2006
 GERONIMO-1758 Can not use Realm with SQL database over connection  
pool  Torsten Markwardt Mar 21, 2006
 GERONIMO-1761 Change geronimo-util module to geronimo-crypto,  
give credit where Aaron Mulder  Mar 22, 2006

   credit is due
 GERONIMO-1762 Create a derby network /embedded XA datasource via  
admin console  Lin Sun   Mar 23, 2006

   fail
 GERONIMO-1763 default config.xml does not list Jetty AJP  
connector  Aaron Mulder  Mar 23, 2006
 GERONIMO-1786 JMS Listeners for protocols activeio, peer and  
openwire fail to   Donald Woods  Mar 28, 2006

   start
 GERONIMO-1789 Exceptions while adding SQL Realm thru Admin  
Console  Vamsavardhana Reddy   Mar 29, 2006
 GERONIMO-1746 Updates to Logger through Log Manager portlet under  
Console are   Vamsavardhana Reddy   Mar 16, 2006

   not reflected in the server
 GERONIMO-1782 Properties File Login module fails after editing  
through AdminVamsavardhana Reddy   Mar 28, 2006

   Console
 GERONIMO-1711 WebServer Connectors portlet should provide a  
"restart" optionVamsavardhana Reddy   Mar 08, 2006

   for connectors
 GERONIMO-1721 Security Realms portlet should prov

Re: Cannot build 1.1 on Windows - long file paths

I'll modify my options below:

John Sisson wrote:

Matt Hogstrom wrote:

So the file that is in Dave's example is 268 characters long. Here
are a couple of questions that perhaps the folks using Windows can
answer.

1. What about long-name support in Windows. I thought MS had some way
to shorten names...probably a Long Shot...but thought I'd try.

I don't think it would be safe going down this path. Some users turn
may have turned off short file name generation using the "fsutil
behaviour set disable8dot3 1" command.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil.mspx?mfr=true

2. Can we leave CARs JARed up? I think this may be the only way to
get past the problem.

I agree that this seems to be the only way to keep the file paths at a
reasonable length (also so other Windows programs can work with the
files without troubles). Is there a reason why are we using expanded
CARs in the repository?

After thinking about this a bit more the expanded CARs is really better for development as
developers could update JSPs , etc directly. If we leave the CAR in an archive format developers
would have to expand them, update them and then archive them (or something other than modifying the
directly). I think I'd prefer option 3 but it sounds oddly like the old config-store
concept...perhaps there is a middle ground.

John

3. The Maven jar naming convention is dramatically increasing the
length of the file name. The groupId and artifacts are repeated as is
the version number. For instance this takes up a lot of the realestate:

So this:
\geronimo\webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class

becomes:
\geronimo\10\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class

and we have an entrie like this in an index.properties:
10=webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\

This would save 109 characters in the path name.

No matter what this is going to be a bit ugly.

Thoughts?

Hernan Cunico wrote:

I am having basically the same issue building directly on Windows.
When the build gets to the izpack section it fails. I check the
assemblies\j2ee-installer\target directory and it cascades
recursively, in fact I am not able to delete that directory (yet).

Any subsequent build attempts will also fail since maven will fail to
delete the target directory.

Cheers!
Hernan

Dain Sundstrom wrote:

What if you unpack with jar -xf?

-dain

On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote:

The "long file path" problem on the windows platform isn't limited
to building G1.1 on this platform. The current images are
incompatible with windows even when the images are generated on a
different platform..

Specifically, I built G1.1 on linux and then FTP'd the generated
windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows
machine..

The resulting image can't unzip on the windows platform due to the
path length problem.. :(

e.g. C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole-
tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-
console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache
\geronimo\console\securitymanager\realm\SecurityRealmPortlet
$ExistingRealm.class

Guess this is obvious in hindsight, though was thinking it was
strictly a build issue..

This absolutely needs to get fixed..

-Dave-

Joe Bohn wrote:

You beat me to it John I'm hitting the exact same problem.
Joe
John Sisson wrote:

I had issues relating to long file paths when building 1.1 from
my C:\dev\asf\geronimo\branches\1.1 directory, so I tried
building from a shorter directory ( C:\geronimo1.1 ) and still
have issues (see below).

I haven't had a chance to look into this yet but I consider this
to be a blocker.

Once we can build on windows we then need to test that Geronimo
can be installed in common locations on windows (e.g. under C:
\Program Files\Geronimo-1.1 ) without encountering file path
length issues.

The following path (from the output below) is 317 bytes long:

C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1-
SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT
\daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1-
SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis
\client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$
$2ae63e1d.class

See http://issues.apache.org/jira/browse/GERONIMO-1790 for more
info on the long file path issue.

John

izpack:izpack-installer-build:
[echo] IZPack installer build is running.
[echo] IZPack Version is 3.8.0
[java]
[java] .:: IzPack - Version 3.8.0 ::.
[java]
[java] < compiler specifications

Re: Cannot build 1.1 on Windows - long file paths


Man I hate Windows

Anyway, if you have a real OS and list the files in an assembly, you  
will see that the problem is caused by the combination of two  
changes: we now keep configurations in the repository and we unpack  
them. If you look closer you will see that the big offenders are  
unpacked ears and wars.


I believe the following are the longest paths in the server:

(270)
geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty/1.1- 
SNAPSHOT/daytrader-derby-jetty-1.1-SNAPSHOT.car/daytrader-web-1.1- 
SNAPSHOT.war/META-INF/geronimo-generated/org/apache/geronimo/axis/ 
client/GenericServiceEndpointWrapper$$EnhancerByCGLIB$$36344d29.class

(264)
geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1- 
SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console- 
standard-1.1-SNAPSHOT.war/WEB-INF/classes/org/apache/geronimo/console/ 
databasemanager/wizard/DatabasePoolPortlet$ResourceAdapterParams.class



One thing to note here is that the longest paths are all classes  
generated by Geronimo, nested classes in wars or compiled JSP pages.   
Someone should look into makeing maven jar the latter two and  
Geronimo should be creating jars when generating classes (actually we  
should stop generating classes a head of time but that is another  
story).




Breaking down the longest path, we have:

GeronimoName (22)
  geronimo-1.1-SNAPSHOT
RepositoryPath (55)
  repository/geronimo/daytrader-derby-jetty/1.1-SNAPSHOT
FileName (39)
  daytrader-derby-jetty-1.1-SNAPSHOT.car
NestedPath (154)
  daytrader-web-1.1-SNAPSHOT.war/META-INF/geronimo-generated/org/ 
apache/geronimo/axis/client/GenericServiceEndpointWrapper$ 
$EnhancerByCGLIB$$36344d29.class




The first thing to note is if we simply replace "SNAPSHOT" with "0",  
we drop 28 characters which makes the longest path 242; not enough  
head room.  Of course, when we switch our groupId to the maven  
standard org.apache.geronimo we eat up 20 more characters.  If we are  
going to unpack war files there is very little we can do about the  
NestedPath, so we have very few choices left.  If we simply combine  
combine ${GeronimoName}/${FileName}/${NestedPath} we are up to 115  
characters leaving only 41 characters for anything else, but when you  
add back the 28 from "SNAPSHOT", you get to a more comfortable level.


I think if we combine this problem with Sachin's request for a  
separate directory for applications, we could do something like this:


${GeronimoName}/apps/${FileName}/${NestedPath}

There are several problems with this.  I think users will confuse the  
hot-deploy directory "deploy" with the "apps" directory [1].  Then  
again, if you look at the problem configurations they are all apps  
the users may want to remove (sample apps and the console), so may be  
we should just put these in the hot-deploy directory.  Another  
problem is that it will be much more difficult to query a repository  
without a directory structure.  The server will basically have to  
read the configuration from these apps on startup to determine what  
they are, so again we may just want to use the hot-deploy directory.   
I'm not a fan of the hot-deploy directory, but I'm not sure there is  
a better solution.


Again I renew my hate of Windows...
/me shakes his fist at Bill Gates

-dain


[1] As a side issue, I prefer the name "apps" because it will be most  
familiar to tomcat users.

Re: Cannot build 1.1 on Windows - long file paths

2006-04-06 Thread Paul McMahan

On 4/6/06, John Sisson <[EMAIL PROTECTED]> wrote:
> I think a reason why we are using expanded CARs could be so that users
> can edit web app files directly in the repository, as discussed in
> Sachin's recent "1.1 repo/configstore" thread.

Right -- I rely on this feature for editing JSPs without having to
restart the server, and for softlinking the web-inf/classes directory
to my project's target/classes directory so I can avoid redeploy
between code changes.  I would miss it if it were gone but realize of
course that the windows path problem is more important :-)

Best wishes,
Paul

Re: Cannot build 1.1 on Windows - long file paths

2006-04-06 Thread John Sisson

John Sisson wrote:

Matt Hogstrom wrote:
So the file that is in Dave's example is 268 characters long. Here
are a couple of questions that perhaps the folks using Windows can
answer.

1. What about long-name support in Windows. I thought MS had some way
to shorten names...probably a Long Shot...but thought I'd try.

I don't think it would be safe going down this path. Some users turn
may have turned off short file name generation using the "fsutil
behaviour set disable8dot3 1" command.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil.mspx?mfr=true

2. Can we leave CARs JARed up? I think this may be the only way to
get past the problem.

I think a reason why we are using expanded CARs could be so that users
can edit web app files directly in the repository, as discussed in
Sachin's recent "1.1 repo/configstore" thread.

John

John
3. The Maven jar naming convention is dramatically increasing the
length of the file name. The groupId and artifacts are repeated as is
the version number. For instance this takes up a lot of the realestate:

becomes:
\geronimo\10\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class

and we have an entrie like this in an index.properties:
10=webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\

This would save 109 characters in the path name.

No matter what this is going to be a bit ugly.

Thoughts?

Hernan Cunico wrote:
I am having basically the same issue building directly on Windows.
When the build gets to the izpack section it fails. I check the
assemblies\j2ee-installer\target directory and it cascades
recursively, in fact I am not able to delete that directory (yet).

Any subsequent build attempts will also fail since maven will fail to
delete the target directory.

Cheers!
Hernan

Dain Sundstrom wrote:

What if you unpack with jar -xf?

-dain

On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote:

Specifically, I built G1.1 on linux and then FTP'd the generated
windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows
machine..

The resulting image can't unzip on the windows platform due to the
path length problem.. :(

Guess this is obvious in hindsight, though was thinking it was
strictly a build issue..

This absolutely needs to get fixed..

-Dave-

Joe Bohn wrote:

You beat me to it John I'm hitting the exact same problem.
Joe
John Sisson wrote:

I haven't had a chance to look into this yet but I consider this
to be a blocker.

The following path (from the output below) is 317 bytes long:

See http://issues.apache.org/jira/browse/GERONIMO-1790 for more
info on the long file path issue.

John

izpack:izpack-installer-build:
[echo] IZPack installer build is running.
[echo] IZPack Version is 3.8.0
[java]
[java] .:: IzPack - Version 3.8.0 ::.
[java]
[java] < compiler specifications version : 1.0 >
[java]
[java] - Copyright (C) 2001-2005 Julien Ponge
[java] - Visit http://www.izforge.com/ for the latests releases
[java] - Released under the terms of the Apache Software
License version 2.0.

[java]
[java] -> Processing

Re: [jira] Unassigned issues (273) as of 2006-04-06

2006-04-06 Thread David Blevins


All, we have a new report to be embarrassed ^H^H^H motivated by.


If you have a moment, look in the 1+ year section and see if there  
aren't some items which can just be deleted.


-David

On Apr 6, 2006, at 3:53 PM, [EMAIL PROTECTED] wrote:



 * * * * * * * * * * * * * * * * * * * * * * * * * * *

 1 WEEK (8 issues)

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Key   
SummaryReporter   Created
 GERONIMO-1800 SPECjAppServer2004 Deployment  
Descriptors   Vasily Zakharov Apr 03, 2006
 GERONIMO-1804 The name of JNDI/RMI service provider is hardcoded  
in the sources.  Andrey Pavlenko Apr 05, 2006
 GERONIMO-1805 org.apache.geronimo.directory.RunningTest hangs on  
BEA Jrockit VMs  Alexei Zakharov Apr 05, 2006
 GERONIMO-1815 Remove empty config-store  
directory Dain Sundstrom  Apr  
06, 2006
 GERONIMO-1792 Ant Tasks Mirror of Maven  
Plugins   Heinie Barnard  Mar  
30, 2006
 GERONIMO-1801 Restart/Shutdown functionality for Geronimo when  
using Java Service Mario Ruebsam   Apr 04, 2006

   Wrapper
 GERONIMO-1812 When already deployed application is hot deployed  
once gain , ServerMansoor Apr 06, 2006

   doesn't delete the module from hot deployed directory
 GERONIMO-1813 When already deployed application is hot deployed  
once gain , ServerMansoor Apr 06, 2006

   doesn't delete the module from hot deployed directory

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

 30 DAYS (37 issues)

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Key
SummaryReporter  Created
 GERONIMO-1733 Module migration to Maven 2:  
mail Jacek Laskowski   Mar 09,  
2006
 GERONIMO-1734 Module migration to Maven 2: naming- 
builder   Jacek Laskowski   Mar 09, 2006
 GERONIMO-1735 Module migration to Maven 2:  
transaction  Jacek Laskowski   Mar 09,  
2006
 GERONIMO-1736 Module migration to Maven 2: web- 
builder  Jacek Laskowski   Mar 09, 2006
 GERONIMO-1739 Plugin migration to Maven 2: geronimo-izpack- 
plugin   Jacek Laskowski   Mar 09, 2006
 GERONIMO-1747 HTTP-methods  
checks   Ilya  
Platonov Mar 16, 2006
 GERONIMO-1749 Server Logs portlet - Web Access Log Viewer  
improvements  Vamsavardhana Reddy   Mar 17, 2006
 GERONIMO-1726 Module migration to Maven 2:  
common   Jacek Laskowski   Mar 09,  
2006
 GERONIMO-1727 Module migration to Maven2:  
connector Jacek Laskowski   Mar 09,  
2006
 GERONIMO-1752 JMS Server portlet - Edits to JMS Network Listener  
are lost upon  Vamsavardhana Reddy   Mar 20, 2006

   server restart
 GERONIMO-1751 Deployment of ear with external plan using "Deploy  
New" console   John Sisson   Mar 20, 2006

   option caused FileNotFoundException
 GERONIMO-1756 Move from 1.1-dev version of commons-fileupload to  
version 1.1John Sisson   Mar 20, 2006
 GERONIMO-1758 Can not use Realm with SQL database over connection  
pool  Torsten Markwardt Mar 21, 2006
 GERONIMO-1761 Change geronimo-util module to geronimo-crypto, give  
credit where Aaron Mulder  Mar 22, 2006

   credit is due
 GERONIMO-1762 Create a derby network /embedded XA datasource via  
admin console  Lin Sun   Mar 23, 2006

   fail
 GERONIMO-1763 default config.xml does not list Jetty AJP  
connector  Aaron Mulder  Mar 23, 2006
 GERONIMO-1786 JMS Listeners for protocols activeio, peer and  
openwire fail to   Donald Woods  Mar 28, 2006

   start
 GERONIMO-1789 Exceptions while adding SQL Realm thru Admin  
Console  Vamsavardhana Reddy   Mar 29, 2006
 GERONIMO-1746 Updates to Logger through Log Manager portlet under  
Console are   Vamsavardhana Reddy   Mar 16, 2006

   not reflected in the server
 GERONIMO-1782 Properties File Login module fails after editing  
through AdminVamsavardhana Reddy   Mar 28, 2006

   Console
 GERONIMO-1711 WebServer Connectors portlet should provide a  
"restart" optionVamsavardhana Reddy   Mar 08, 2006

   for connectors
 GERONIMO-1721 Security Realms portlet should provide link to  
delete an existing Vamsavardhana Reddy   Mar 09, 2006

   realm
 GERONIMO-1741 Console should provide option to "redeploy"  
applications  Vamsavardhana Reddy   Mar 10, 2006
 GERONIMO-1748 Site migration to Maven  
2 John Sisson   Mar  
16, 2006
 GERONIMO-1750 Unable

[jira] Closed: (GERONIMO-1811) Improve the "Error: Unable to distribute foo.ear: Cannot deploy the requested application module" message

2006-04-06 Thread John Sisson (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1811?page=all ]
 
John Sisson closed GERONIMO-1811:
-

Resolution: Duplicate

Somehow I managed to create this issue twice.  See Geronimo-1810 .

> Improve the "Error: Unable to distribute foo.ear: Cannot deploy the requested 
> application module" message
> -
>
>  Key: GERONIMO-1811
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1811
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.0
> Reporter: John Sisson
> Assignee: John Sisson
> Priority: Trivial
>  Fix For: 1.1

>
> Need to provide more information in the following error message, giving the 
> user a bit more of a hint as to what the problem may be.
> C:\test>geronimo-1.0.1-SNAPSHOT\bin\deploy --user system --password manager 
> deploy jstest.ear jstest.xml
> Using GERONIMO_BASE:   C:\test\geronimo-1.0.1-SNAPSHOT
> Using GERONIMO_HOME:   C:\test\geronimo-1.0.1-SNAPSHOT
> Using GERONIMO_TMPDIR: C:\test\geronimo-1.0.1-SNAPSHOT\var\temp
> Using JRE_HOME:C:\j2sdk1.4.2_10
> Error: Unable to distribute jstest.ear: Cannot deploy the requested
> application module (planFile=C:\test\jstest.xml,
> 
> moduleFile=C:\test\geronimo-1.0.1-SNAPSHOT\var\temp\geronimo-deployer59948.tmpdir\jstest.ear)
> In the case above it was due to my ear file accidentially having all the 
> files under a directory.
> I propose we add the following to the end of the message:
> Check that the module file contains the expected deployment files and 
> directory structure.  If problems persist, ensure the appropriate module 
> builder is running.

-- 
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: Cannot build 1.1 on Windows - long file paths

2006-04-06 Thread John Sisson

Matt Hogstrom wrote:
So the file that is in Dave's example is 268 characters long. Here
are a couple of questions that perhaps the folks using Windows can
answer.

1. What about long-name support in Windows. I thought MS had some way
to shorten names...probably a Long Shot...but thought I'd try.

I don't think it would be safe going down this path. Some users turn
may have turned off short file name generation using the "fsutil
behaviour set disable8dot3 1" command.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil.mspx?mfr=true

2. Can we leave CARs JARed up? I think this may be the only way to
get past the problem.

becomes:
\geronimo\10\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class

and we have an entrie like this in an index.properties:
10=webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\

This would save 109 characters in the path name.

No matter what this is going to be a bit ugly.

Thoughts?

Any subsequent build attempts will also fail since maven will fail to
delete the target directory.

Cheers!
Hernan

Dain Sundstrom wrote:

What if you unpack with jar -xf?

-dain

On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote:

Specifically, I built G1.1 on linux and then FTP'd the generated
windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows
machine..

The resulting image can't unzip on the windows platform due to the
path length problem.. :(

Guess this is obvious in hindsight, though was thinking it was
strictly a build issue..

This absolutely needs to get fixed..

-Dave-

Joe Bohn wrote:

You beat me to it John I'm hitting the exact same problem.
Joe
John Sisson wrote:

I haven't had a chance to look into this yet but I consider this
to be a blocker.

The following path (from the output below) is 317 bytes long:

See http://issues.apache.org/jira/browse/GERONIMO-1790 for more
info on the long file path issue.

John

[java]
[java] -> Processing : C:\geronimo1.1\assemblies\j2ee-
installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml
[java] -> Output : C:\geronimo1.1\assemblies\j2ee-
installer/target/geronimo-installer-1.1-SNAPSHOT.jar

[java] ->

[jira] Unassigned issues (273) as of 2006-04-06

2006-04-06 Thread dblevins


 * * * * * * * * * * * * * * * * * * * * * * * * * * *

 1 WEEK (8 issues)

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Key  Summary  
  Reporter   Created
 GERONIMO-1800 SPECjAppServer2004 Deployment Descriptors
   Vasily Zakharov Apr 03, 2006
 GERONIMO-1804 The name of JNDI/RMI service provider is hardcoded in the 
sources.  Andrey Pavlenko Apr 05, 2006
 GERONIMO-1805 org.apache.geronimo.directory.RunningTest hangs on BEA Jrockit 
VMs  Alexei Zakharov Apr 05, 2006
 GERONIMO-1815 Remove empty config-store directory  
   Dain Sundstrom  Apr 06, 2006
 GERONIMO-1792 Ant Tasks Mirror of Maven Plugins
   Heinie Barnard  Mar 30, 2006
 GERONIMO-1801 Restart/Shutdown functionality for Geronimo when using Java 
Service Mario Ruebsam   Apr 04, 2006
   Wrapper
 GERONIMO-1812 When already deployed application is hot deployed once gain , 
ServerMansoor Apr 06, 2006
   doesn't delete the module from hot deployed directory
 GERONIMO-1813 When already deployed application is hot deployed once gain , 
ServerMansoor Apr 06, 2006
   doesn't delete the module from hot deployed directory

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

 30 DAYS (37 issues)

 * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Key   Summary 
   Reporter  Created
 GERONIMO-1733 Module migration to Maven 2: mail
 Jacek Laskowski   Mar 09, 2006
 GERONIMO-1734 Module migration to Maven 2: naming-builder  
 Jacek Laskowski   Mar 09, 2006
 GERONIMO-1735 Module migration to Maven 2: transaction 
 Jacek Laskowski   Mar 09, 2006
 GERONIMO-1736 Module migration to Maven 2: web-builder 
 Jacek Laskowski   Mar 09, 2006
 GERONIMO-1739 Plugin migration to Maven 2: geronimo-izpack-plugin  
 Jacek Laskowski   Mar 09, 2006
 GERONIMO-1747 HTTP-methods checks  
 Ilya Platonov Mar 16, 2006
 GERONIMO-1749 Server Logs portlet - Web Access Log Viewer improvements 
 Vamsavardhana Reddy   Mar 17, 2006
 GERONIMO-1726 Module migration to Maven 2: common  
 Jacek Laskowski   Mar 09, 2006
 GERONIMO-1727 Module migration to Maven2: connector
 Jacek Laskowski   Mar 09, 2006
 GERONIMO-1752 JMS Server portlet - Edits to JMS Network Listener are lost upon 
 Vamsavardhana Reddy   Mar 20, 2006
   server restart
 GERONIMO-1751 Deployment of ear with external plan using "Deploy New" console  
 John Sisson   Mar 20, 2006
   option caused FileNotFoundException
 GERONIMO-1756 Move from 1.1-dev version of commons-fileupload to version 1.1   
 John Sisson   Mar 20, 2006
 GERONIMO-1758 Can not use Realm with SQL database over connection pool 
 Torsten Markwardt Mar 21, 2006
 GERONIMO-1761 Change geronimo-util module to geronimo-crypto, give credit 
where Aaron Mulder  Mar 22, 2006
   credit is due
 GERONIMO-1762 Create a derby network /embedded XA datasource via admin console 
 Lin Sun   Mar 23, 2006
   fail
 GERONIMO-1763 default config.xml does not list Jetty AJP connector 
 Aaron Mulder  Mar 23, 2006
 GERONIMO-1786 JMS Listeners for protocols activeio, peer and openwire fail to  
 Donald Woods  Mar 28, 2006
   start
 GERONIMO-1789 Exceptions while adding SQL Realm thru Admin Console 
 Vamsavardhana Reddy   Mar 29, 2006
 GERONIMO-1746 Updates to Logger through Log Manager portlet under Console are  
 Vamsavardhana Reddy   Mar 16, 2006
   not reflected in the server
 GERONIMO-1782 Properties File Login module fails after editing through Admin   
 Vamsavardhana Reddy   Mar 28, 2006
   Console
 GERONIMO-1711 WebServer Connectors portlet should provide a "restart" option   
 Vamsavardhana Reddy   Mar 08, 2006
   for connectors
 GERONIMO-1721 Security Realms portlet should provide link to delete an 
existing Vamsavardhana Reddy   Mar 09, 2006
   realm
 GERONIMO-1741 Console should provide option to "redeploy" applications 
 Vamsavardhana Reddy   Mar 10, 2006
 GERONIMO-1748 Site migration to Maven 2
 John Sisson   Mar 16, 2006
 GERONIMO-1750 Unable to run tradeStreamerAppclient 
 Lin Sun   Mar 17, 2006
 GERONIMO-1757 rarRelativePath is not set correctly cause showplan.jsp  
 Lin Sun   Mar 21, 2006
   displayswrong instruction
 GERONIMO-1764 Daytrader createDB.sh script does not su

Re: Cannot build 1.1 on Windows - long file paths

2006-04-06 Thread Hernan Cunico

Hi Matt,
so far I have not found a way in windows to recursively "list" all directories and files with the
alternate short name. dir /X /s will not shrink recursively directory names

As for keeping the CARs JARed, I guess that will hide temporarily the problem. Windows still will
need to get to those files, right. Isn't this the same issue Dave C is having? Isn't the application
ruled by the OS limitations? if not, then using JARs instead may be an option.

Cheers!
Hernan

Matt Hogstrom wrote:
So the file that is in Dave's example is 268 characters long. Here are
a couple of questions that perhaps the folks using Windows can answer.

1. What about long-name support in Windows. I thought MS had some way
to shorten names...probably a Long Shot...but thought I'd try.

2. Can we leave CARs JARed up? I think this may be the only way to get
past the problem.

3. The Maven jar naming convention is dramatically increasing the length
of the file name. The groupId and artifacts are repeated as is the
version number. For instance this takes up a lot of the realestate:

becomes:
\geronimo\10\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class

and we have an entrie like this in an index.properties:
10=webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\

This would save 109 characters in the path name.

No matter what this is going to be a bit ugly.

Thoughts?

Hernan Cunico wrote:

Any subsequent build attempts will also fail since maven will fail to
delete the target directory.

Cheers!
Hernan

Dain Sundstrom wrote:

What if you unpack with jar -xf?

-dain

On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote:

Specifically, I built G1.1 on linux and then FTP'd the generated
windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows
machine..

The resulting image can't unzip on the windows platform due to the
path length problem.. :(

Guess this is obvious in hindsight, though was thinking it was
strictly a build issue..

This absolutely needs to get fixed..

-Dave-

Joe Bohn wrote:

You beat me to it John I'm hitting the exact same problem.
Joe
John Sisson wrote:

I haven't had a chance to look into this yet but I consider this
to be a blocker.

The following path (from the output below) is 317 bytes long:

See http://issues.apache.org/jira/browse/GERONIMO-1790 for more
info on the long file path issue.

John

[java] -> Base path : .
[java] -> Kind

Re: New Feature Idea

I did a quick test by building the server with the XStream configs and it still failed when starting
with 1.5. I haven't looked into it much yet...it was just a sniff test.

Dain Sundstrom wrote:

Shouldn't update our QName implementation to be compatiable with 1.5?

Also, if we do ship with the XStream based configs on we no longer will
have this problem.

-dain

On Apr 6, 2006, at 11:45 AM, Aaron Mulder wrote:

I didn't think there were problems with web services in Geronimo in
general between 1.4 and 1.5 -- I thought it's only the fact that
QNames are serialized that causes problem. I wouldn't expect to have
a problem with an application that calls a web service or is called
via a web service so long as it doesn't do any Java serialization
involving QNames. Is that not correct? (Does Geronimo itself do the
QName serialization for certain types of Web Services apps?)

Thanks,
Aaron

On 4/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

To be clear. The reason DayTrader has an issue is that it uses
WebServices and specifically it has
to do with the javax.xml.namespace.QName class has different
serialization characteristics between
1.4 and 1.5. So, if someone wants to move back and forth between
1.4 and 1.5 and their using

WebServices they'll still have issues.

Aaron Mulder wrote:

We already support JDK 1.5 except for CORBA. Because of the CORBA
limitation Geronimo can't be certified on JDK 1.5, but if you leave
CORBA disabled (and turn off the DayTrader sample application)
Geronimo should run fine on 1.5.

Thanks,
Aaron

On 4/6/06, Christopher Stura <[EMAIL PROTECTED]> wrote:

support for sun jdk 1.5

Re: New Feature Idea

You are correct in that the only problem for a Geronimo user is that they can't deployon 1.4 and 
switch to 1.5 or vice versa.  You need to pick a VM and stick with it.


Aaron Mulder wrote:

I didn't think there were problems with web services in Geronimo in
general between 1.4 and 1.5 -- I thought it's only the fact that
QNames are serialized that causes problem.  I wouldn't expect to have
a problem with an application that calls a web service or is called
via a web service so long as it doesn't do any Java serialization
involving QNames.  Is that not correct?  (Does Geronimo itself do the
QName serialization for certain types of Web Services apps?)

Thanks,
 Aaron

On 4/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:


To be clear.  The reason DayTrader has an issue is that it uses WebServices and 
specifically it has
to do with the javax.xml.namespace.QName class has different serialization 
characteristics between
1.4 and 1.5.  So, if someone wants to move back and forth between 1.4 and 1.5 
and their using
WebServices they'll still have issues.

Aaron Mulder wrote:


We already support JDK 1.5 except for CORBA.  Because of the CORBA
limitation Geronimo can't be certified on JDK 1.5, but if you leave
CORBA disabled (and turn off the DayTrader sample application)
Geronimo should run fine on 1.5.

Thanks,
   Aaron

On 4/6/06, Christopher Stura <[EMAIL PROTECTED]> wrote:



support for sun jdk 1.5

Re: Need some help with the Ant Tasks

2006-04-06 Thread Heinie Barnard

Thanks Dain

Great Idea !, for those of you not in irc (Dain and I have
already discussed in irc).

I am almost finish with the changes. I ran in the following
problem:
Coloured version at http://rifers.org/paste/show/468

This file is in the jar file under
org/apache/geronimo/ant/deployment/ant-geronimo.xml







  
  









This is my build.xml file







  
 
 

 
 

 
 


   


 
  
   
 
  
   
  


  

  
  
  
 
  
  
 


 
   
   
   
 

  
   
   
  

 
   
   
  

  
   
   
  

  

   
   


  
 
   
   
 




For some odd "uri" reason ant is looking for the
ant-geronimo.xml on my
local file system and not in the jar.

I get the following from ant

Buildfile: build.xml
  [typedef] File C:\Documents and Settings\Heinie
Barnard\workspace\GeronimoAntT
asks\org\apache\geronimo\ant\deployment\ant-geronimo.xml
does not exist


Regards
Heinie Barnard
Kaybee IT Solutions
Orbis non sufficit



> Can we wrap the tasks up into an AntLib so it is easier
for our users
> to declare and use the tasks?   The maven team has
wrapped their
> artifact management code into an ant lib so ant users can
use the
> maven repo.
>
> Here is some info on ant libs:
>http://ant.apache.org/manual/CoreTypes/antlib.html
>
> Here is the docs on how ant users use the maven artifact
management
> ant tasks:
>http://maven.apache.org/ant-tasks.html
>
> -dain
>
>
> On Apr 5, 2006, at 3:05 PM, Heinie Barnard wrote:
>
>> Here's the build.xml file. I tried to colour code it,
but
>> it was removed.
>>
>> 
>>
>> 
>>
>>
>>  > basedir=".">
>>
>> 
>> 
>> > location="C:/geronimo-1.0/lib"/>
>> > location="C:/geronimo-1.0/repository/geronimo/jars"/>
>>
>> 
>> 
>>   
>> 
>> 
>>   
>> 
>> 
>>   
>> 
>> 
>>
>> 
>> >  value="C:/geronimo-jetty/geronimo-1.0" />
>> >
 value="jmx:rmi:///jndi/rmi://localhost:1099/JMXConnector"
>> />
>>
>> >
 value="${maven.repo.local}/myproject/jars/myapplication-1.0-
>> SNAPSHOT.jar"
>> />
>> >value="org/myproject/MyConfigurationName" />
>>
>> 
>> 
>>
>> 
>> >
>>
classname="org.apache.geronimo.deployment.ant.StartRemoteServer"
>>classpathref="ant.lib.path"/>
>> >
>>
classname="org.apache.geronimo.deployment.ant.StopRemoteServer"
>> classpathref="ant.lib.path"/>
>>>
classname="org.apache.geronimo.deployment.ant.WaitForStarted"
>>   classpathref="ant.lib.path"/>
>> >
  classname="org.apache.geronimo.deployment.ant.DistributeModule"
>> classpathref="ant.lib.path"/>
>> >
classname="org.apache.geronimo.deployment.ant.UndeployModule"
>>   classpathref="ant.lib.path"/>
>> >
   classname="org.apache.geronimo.deployment.ant.StartModule"
>>  classpathref="ant.lib.path"/>
>> >
classname="org.apache.geronimo.deployment.ant.StopModule"
>>   classpathref="ant.lib.path"/>
>>
>>
>> 
>>
>>   
>>  
>>   
>>  
>> 
>> 
>>
>> 
>> 
>>
>>   
>>
>>   
>>   > geronimoTarget="C:/geronimo-jetty/geronimo-1.0">
>>   
>> 
>>   
>>   
>>
>>   
>> > password="${password}">
>> 
>>   
>>   
>>
>>   
>> > password="${password}" id="${moduleId}">
>> 
>>   
>>
>>   
>> > password="${password}" id="${moduleId}">
>> 
>>   
>>
>>   > previous one ->
>>   
>> > password="${password}" home="${basedir}"
>> module="${module}">
>> 
>>   
>>
>>   > previous one ->
>>   
>> > password="${password}" id="${moduleId}">
>> 
>>   
>>
>> 
>>
>>
>>>Good evening everybody   We need some help with
>> the Ant Plugin
>>> Tasks. We  need some people to test the tasks.   The
>> source code
>>> can be obtained at :
>>> http://issues.apache.org/jira/browse/GERONIMO-1792
>>   Prasad Kashyap
>>> and I have decided that we need to  change the
following:
>>   1)
>>> Package structure:   2) Refactor StartRemoteServer /
>>> StopRemoteServer to StartServer and StopServer   3)
>> Change the ant
>>> build file to look like  the build at the bottom
>>   Regards Heinie
>>> Barnard Kaybee IT Solutions Orbis non sufficit
>>
>>>
>>
>>
>>>
>>
>>
>>>
>>
>>
>>>
>>
>>
>>>
>>
>>
>>>
>>
>>
>>>
>>
>>
>>>
>>
>>
>>>
>>>
>>
___
>>>  For super low premiums, click here
>> http://www.webmail.co.za/dd.pwm
>>>http://www.webmail.co.za the South African FREE
email
>> service
>>
___
>> For super low premiums, click here
http://www.webmail.co.za/dd.pwm
>>
>>

Re: Cannot build 1.1 on Windows - long file paths

So the file that is in Dave's example is 268 characters long.  Here are a couple of questions that 
perhaps the folks using Windows can answer.


1. What about long-name support in Windows.  I thought MS had some way to shorten names...probably a 
Long Shot...but thought I'd try.


2. Can we leave CARs JARed up?  I think this may be the only way to get past 
the problem.

3. The Maven jar naming convention is dramatically increasing the length of the file name.  The 
groupId and artifacts are repeated as is the version number.  For instance this takes up a lot of 
the realestate:


So this:
\geronimo\webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class

becomes:
\geronimo\10\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class

and we have an entrie like this in an index.properties:
10=webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\

This would save 109 characters in the path name.

No matter what this is going to be a bit ugly.

Thoughts?


Hernan Cunico wrote:
I am having basically the same issue building directly on Windows. When 
the build gets to the izpack section it fails. I check the 
assemblies\j2ee-installer\target directory and it cascades recursively, 
in fact I am not able to delete that directory (yet).


Any subsequent build attempts will also fail since maven will fail to 
delete the target directory.


Cheers!
Hernan

Dain Sundstrom wrote:


What if you unpack with jar -xf?

-dain

On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote:

The "long file path" problem on the windows platform isn't limited  
to building G1.1 on this platform.  The current images are  
incompatible with windows even when the images are generated on a  
different platform..


Specifically, I built G1.1 on linux and then FTP'd the generated  
windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows  
machine..


The resulting image can't unzip on the windows platform due to the  
path length problem.. :(


e.g. C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole- 
tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo- 
console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache 
\geronimo\console\securitymanager\realm\SecurityRealmPortlet 
$ExistingRealm.class


Guess this is obvious in hindsight, though was thinking it was  
strictly a build issue..


This absolutely needs to get fixed..

-Dave-


Joe Bohn wrote:


You beat me to it John  I'm hitting the exact same problem.
Joe
John Sisson wrote:

I had issues relating to long file paths when building 1.1 from  my 
C:\dev\asf\geronimo\branches\1.1 directory, so I tried  building 
from a shorter directory ( C:\geronimo1.1 ) and still  have issues 
(see below).


I haven't had a chance to look into this yet but I consider this  
to be a blocker.


Once we can build on windows we then need to test that Geronimo  
can be installed in common locations on windows (e.g. under C: 
\Program Files\Geronimo-1.1 ) without encountering file path  
length issues.


The following path (from the output below) is 317 bytes long:

C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1- 
SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT 
\daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1- 
SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis 
\client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$ 
$2ae63e1d.class


See http://issues.apache.org/jira/browse/GERONIMO-1790 for more  
info on the long file path issue.


John

izpack:izpack-installer-build:
   [echo] IZPack installer build is running.
   [echo] IZPack Version is 3.8.0
   [java]
   [java] .::  IzPack - Version 3.8.0 ::.
   [java]
   [java] < compiler specifications version : 1.0 >
   [java]
   [java] - Copyright (C) 2001-2005 Julien Ponge
   [java] - Visit http://www.izforge.com/ for the latests releases
   [java] - Released under the terms of the Apache Software  
License version 2.0.

   [java]
   [java] -> Processing  : C:\geronimo1.1\assemblies\j2ee- 
installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml
   [java] -> Output  : C:\geronimo1.1\assemblies\j2ee- 
installer/target/geronimo-installer-1.1-SNAPSHOT.jar

   [java] -> Base path   : .
   [java] -> Kind: standard
   [java] -> Compression : default
   [java] -> Compr. level: -1
   [java]
   [java] Adding resource: IzPack.uninstaller
   [java] Setting the installer information
   [java] Setting the GUI preferences
   [java] Adding langpack: eng
   [java] Adding resource: flag.eng
   [java] Adding resource: Installer.image
   [java] Adding resource: LicencePanel.licence
   [java] Adding resource: InfoPanel.info
   [java] Adding resource: userInputSpec.xml
   [java] Adding resource: ProcessPanel.Spec.xml
   [j

Re: JCA Flow

2006-04-06 Thread Guillaume Nodet

It seems that the version you are running is quite old.
Could you try with a recent snapshot ?

Cheers,
Guillaume Nodet

On 4/6/06, fretzlaff <[EMAIL PROTECTED]> wrote:
>
> I have tried but doesn't work... take a look at my XML:
>
> 
> http://xbean.org/schemas/spring/1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:sm="http://servicemix.apache.org/config/1.0";
> xmlns:spring="http://xbean.org/schemas/spring/1.0";
> xsi:schemaLocation="http://xbean.org/schemas/spring/1.0 spring-beans.xsd
> http://servicemix.apache.org/config/1.0 servicemix.xsd">
>  createMBeanServer="false" useMBeanServer="true" flowName="jca"
> MBeanServer="#mbeanServer" name="jbi" spring:id="jbi">
> 
> 
>  id="mbeanServer"/>
>  id="transactionContextManager"/>
>  id="transactionManager"/>
> 
> --
> View this message in context: 
> http://www.nabble.com/JCA-Flow-t1405473.html#a3791374
> Sent from the ServiceMix - Dev forum at Nabble.com.
>
>

Re: Cannot build 1.1 on Windows - long file paths

2006-04-06 Thread Dave Colasurdo


I tried with:

winzip - indicates an unzip error
infozip  - no error but omits the offending files
jar -xvf - gets the following exception

java.io.FileNotFoundException: 
geronimo-1.1-SNAPSHOT\repository\geronimo\daytrad

er-derby-tomcat\1.1-SNAPSHOT\daytrader-derby-tomcat-1.1-SNAPSHOT.car\daytrader-w
eb-1.1-SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis\client\
GenericServiceEndpointWrapper$$EnhancerByCGLIB$$6a6aebe.class (The 
system cannot

 find the path specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:179)
at java.io.FileOutputStream.(FileOutputStream.java:131)
at sun.tools.jar.Main.extractFile(Main.java:712)
at sun.tools.jar.Main.extract(Main.java:678)
at sun.tools.jar.Main.run(Main.java:190)
at sun.tools.jar.Main.main(Main.java:904)

The problem isn't with the unzip program.. The problem is that the 
images have files with path lengths that exceed the current limit of 256 
for the windows platform..


-Dave-




Dain Sundstrom wrote:

What if you unpack with jar -xf?

-dain

On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote:

The "long file path" problem on the windows platform isn't limited to 
building G1.1 on this platform.  The current images are incompatible 
with windows even when the images are generated on a different platform..


Specifically, I built G1.1 on linux and then FTP'd the generated 
windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows 
machine..


The resulting image can't unzip on the windows platform due to the 
path length problem.. :(


e.g. 
C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class 



Guess this is obvious in hindsight, though was thinking it was 
strictly a build issue..


This absolutely needs to get fixed..

-Dave-


Joe Bohn wrote:

You beat me to it John  I'm hitting the exact same problem.
Joe
John Sisson wrote:
I had issues relating to long file paths when building 1.1 from my 
C:\dev\asf\geronimo\branches\1.1 directory, so I tried building from 
a shorter directory ( C:\geronimo1.1 ) and still have issues (see 
below).


I haven't had a chance to look into this yet but I consider this to 
be a blocker.


Once we can build on windows we then need to test that Geronimo can 
be installed in common locations on windows (e.g. under C:\Program 
Files\Geronimo-1.1 ) without encountering file path length issues.


The following path (from the output below) is 317 bytes long:

C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1-SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT\daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1-SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis\client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$$2ae63e1d.class 



See http://issues.apache.org/jira/browse/GERONIMO-1790 for more info 
on the long file path issue.


John

izpack:izpack-installer-build:
   [echo] IZPack installer build is running.
   [echo] IZPack Version is 3.8.0
   [java]
   [java] .::  IzPack - Version 3.8.0 ::.
   [java]
   [java] < compiler specifications version : 1.0 >
   [java]
   [java] - Copyright (C) 2001-2005 Julien Ponge
   [java] - Visit http://www.izforge.com/ for the latests releases
   [java] - Released under the terms of the Apache Software License 
version 2.0.

   [java]
   [java] -> Processing  : 
C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml 

   [java] -> Output  : 
C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-installer-1.1-SNAPSHOT.jar 


   [java] -> Base path   : .
   [java] -> Kind: standard
   [java] -> Compression : default
   [java] -> Compr. level: -1
   [java]
   [java] Adding resource: IzPack.uninstaller
   [java] Setting the installer information
   [java] Setting the GUI preferences
   [java] Adding langpack: eng
   [java] Adding resource: flag.eng
   [java] Adding resource: Installer.image
   [java] Adding resource: LicencePanel.licence
   [java] Adding resource: InfoPanel.info
   [java] Adding resource: userInputSpec.xml
   [java] Adding resource: ProcessPanel.Spec.xml
   [java] Adding resource: ImgPacksPanel.img.0
   [java] Adding resource: ImgPacksPanel.img.1
   [java] Adding resource: ImgPacksPanel.img.2
   [java] Adding resource: ImgPacksPanel.img.3
   [java] Adding resource: ImgPacksPanel.img.4
   [java] Adding resource: ImgPacksPanel.img.5
   [java] Adding resource: ImgPacksPanel.img.6
   [java] Adding resource: ImgPacksPanel.img.7
   [java] Adding resource: ImgPacksPanel.img.8
   [java] Adding resource: ImgPacksPanel.img.9
   [java] Adding resource: ImgPacksPanel.img.10
   [java] Adding resource: ImgPacksPanel.img.11
   [java] Adding resource: ImgPacksP

Re: Cannot build 1.1 on Windows - long file paths

2006-04-06 Thread Hernan Cunico

I am having basically the same issue building directly on Windows. When the build gets to the izpack 
section it fails. I check the assemblies\j2ee-installer\target directory and it cascades 
recursively, in fact I am not able to delete that directory (yet).


Any subsequent build attempts will also fail since maven will fail to delete 
the target directory.

Cheers!
Hernan

Dain Sundstrom wrote:

What if you unpack with jar -xf?

-dain

On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote:

The "long file path" problem on the windows platform isn't limited  to 
building G1.1 on this platform.  The current images are  incompatible 
with windows even when the images are generated on a  different 
platform..


Specifically, I built G1.1 on linux and then FTP'd the generated  
windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows  
machine..


The resulting image can't unzip on the windows platform due to the  
path length problem.. :(


e.g. C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole- 
tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo- 
console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache 
\geronimo\console\securitymanager\realm\SecurityRealmPortlet 
$ExistingRealm.class


Guess this is obvious in hindsight, though was thinking it was  
strictly a build issue..


This absolutely needs to get fixed..

-Dave-


Joe Bohn wrote:


You beat me to it John  I'm hitting the exact same problem.
Joe
John Sisson wrote:

I had issues relating to long file paths when building 1.1 from  my 
C:\dev\asf\geronimo\branches\1.1 directory, so I tried  building 
from a shorter directory ( C:\geronimo1.1 ) and still  have issues 
(see below).


I haven't had a chance to look into this yet but I consider this  to 
be a blocker.


Once we can build on windows we then need to test that Geronimo  can 
be installed in common locations on windows (e.g. under C: \Program 
Files\Geronimo-1.1 ) without encountering file path  length issues.


The following path (from the output below) is 317 bytes long:

C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1- 
SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT 
\daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1- 
SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis 
\client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$ $2ae63e1d.class


See http://issues.apache.org/jira/browse/GERONIMO-1790 for more  
info on the long file path issue.


John

izpack:izpack-installer-build:
   [echo] IZPack installer build is running.
   [echo] IZPack Version is 3.8.0
   [java]
   [java] .::  IzPack - Version 3.8.0 ::.
   [java]
   [java] < compiler specifications version : 1.0 >
   [java]
   [java] - Copyright (C) 2001-2005 Julien Ponge
   [java] - Visit http://www.izforge.com/ for the latests releases
   [java] - Released under the terms of the Apache Software  License 
version 2.0.

   [java]
   [java] -> Processing  : C:\geronimo1.1\assemblies\j2ee- 
installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml
   [java] -> Output  : C:\geronimo1.1\assemblies\j2ee- 
installer/target/geronimo-installer-1.1-SNAPSHOT.jar

   [java] -> Base path   : .
   [java] -> Kind: standard
   [java] -> Compression : default
   [java] -> Compr. level: -1
   [java]
   [java] Adding resource: IzPack.uninstaller
   [java] Setting the installer information
   [java] Setting the GUI preferences
   [java] Adding langpack: eng
   [java] Adding resource: flag.eng
   [java] Adding resource: Installer.image
   [java] Adding resource: LicencePanel.licence
   [java] Adding resource: InfoPanel.info
   [java] Adding resource: userInputSpec.xml
   [java] Adding resource: ProcessPanel.Spec.xml
   [java] Adding resource: ImgPacksPanel.img.0
   [java] Adding resource: ImgPacksPanel.img.1
   [java] Adding resource: ImgPacksPanel.img.2
   [java] Adding resource: ImgPacksPanel.img.3
   [java] Adding resource: ImgPacksPanel.img.4
   [java] Adding resource: ImgPacksPanel.img.5
   [java] Adding resource: ImgPacksPanel.img.6
   [java] Adding resource: ImgPacksPanel.img.7
   [java] Adding resource: ImgPacksPanel.img.8
   [java] Adding resource: ImgPacksPanel.img.9
   [java] Adding resource: ImgPacksPanel.img.10
   [java] Adding resource: ImgPacksPanel.img.11
   [java] Adding resource: ImgPacksPanel.img.12
   [java] Adding resource: ImgPacksPanel.img.13
   [java] Adding resource: ImgPacksPanel.img.14
   [java] Adding resource: ImgPacksPanel.img.15
   [java] Adding resource: ImgPacksPanel.img.16
   [java] Adding resource: ImgPacksPanel.img.17
   [java] Adding resource: ImgPacksPanel.img.18
   [java] Adding resource: ImgPacksPanel.img.19
   [java] Adding resource: ImgPacksPanel.img.20
   [java] Adding content of jar: file:/C:/Documents%20and% 
20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/ 
standal

one-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar
   [java] Adding content of jar: file:/C:/Documents%20and% 
20Settings/sis

Re: Cannot build 1.1 on Windows - long file paths


What if you unpack with jar -xf?

-dain

On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote:

The "long file path" problem on the windows platform isn't limited  
to building G1.1 on this platform.  The current images are  
incompatible with windows even when the images are generated on a  
different platform..


Specifically, I built G1.1 on linux and then FTP'd the generated  
windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows  
machine..


The resulting image can't unzip on the windows platform due to the  
path length problem.. :(


e.g. C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole- 
tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo- 
console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache 
\geronimo\console\securitymanager\realm\SecurityRealmPortlet 
$ExistingRealm.class


Guess this is obvious in hindsight, though was thinking it was  
strictly a build issue..


This absolutely needs to get fixed..

-Dave-


Joe Bohn wrote:

You beat me to it John  I'm hitting the exact same problem.
Joe
John Sisson wrote:
I had issues relating to long file paths when building 1.1 from  
my C:\dev\asf\geronimo\branches\1.1 directory, so I tried  
building from a shorter directory ( C:\geronimo1.1 ) and still  
have issues (see below).


I haven't had a chance to look into this yet but I consider this  
to be a blocker.


Once we can build on windows we then need to test that Geronimo  
can be installed in common locations on windows (e.g. under C: 
\Program Files\Geronimo-1.1 ) without encountering file path  
length issues.


The following path (from the output below) is 317 bytes long:

C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1- 
SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT 
\daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1- 
SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis 
\client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$ 
$2ae63e1d.class


See http://issues.apache.org/jira/browse/GERONIMO-1790 for more  
info on the long file path issue.


John

izpack:izpack-installer-build:
   [echo] IZPack installer build is running.
   [echo] IZPack Version is 3.8.0
   [java]
   [java] .::  IzPack - Version 3.8.0 ::.
   [java]
   [java] < compiler specifications version : 1.0 >
   [java]
   [java] - Copyright (C) 2001-2005 Julien Ponge
   [java] - Visit http://www.izforge.com/ for the latests releases
   [java] - Released under the terms of the Apache Software  
License version 2.0.

   [java]
   [java] -> Processing  : C:\geronimo1.1\assemblies\j2ee- 
installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml
   [java] -> Output  : C:\geronimo1.1\assemblies\j2ee- 
installer/target/geronimo-installer-1.1-SNAPSHOT.jar

   [java] -> Base path   : .
   [java] -> Kind: standard
   [java] -> Compression : default
   [java] -> Compr. level: -1
   [java]
   [java] Adding resource: IzPack.uninstaller
   [java] Setting the installer information
   [java] Setting the GUI preferences
   [java] Adding langpack: eng
   [java] Adding resource: flag.eng
   [java] Adding resource: Installer.image
   [java] Adding resource: LicencePanel.licence
   [java] Adding resource: InfoPanel.info
   [java] Adding resource: userInputSpec.xml
   [java] Adding resource: ProcessPanel.Spec.xml
   [java] Adding resource: ImgPacksPanel.img.0
   [java] Adding resource: ImgPacksPanel.img.1
   [java] Adding resource: ImgPacksPanel.img.2
   [java] Adding resource: ImgPacksPanel.img.3
   [java] Adding resource: ImgPacksPanel.img.4
   [java] Adding resource: ImgPacksPanel.img.5
   [java] Adding resource: ImgPacksPanel.img.6
   [java] Adding resource: ImgPacksPanel.img.7
   [java] Adding resource: ImgPacksPanel.img.8
   [java] Adding resource: ImgPacksPanel.img.9
   [java] Adding resource: ImgPacksPanel.img.10
   [java] Adding resource: ImgPacksPanel.img.11
   [java] Adding resource: ImgPacksPanel.img.12
   [java] Adding resource: ImgPacksPanel.img.13
   [java] Adding resource: ImgPacksPanel.img.14
   [java] Adding resource: ImgPacksPanel.img.15
   [java] Adding resource: ImgPacksPanel.img.16
   [java] Adding resource: ImgPacksPanel.img.17
   [java] Adding resource: ImgPacksPanel.img.18
   [java] Adding resource: ImgPacksPanel.img.19
   [java] Adding resource: ImgPacksPanel.img.20
   [java] Adding content of jar: file:/C:/Documents%20and% 
20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/ 
standal

one-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar
   [java] Adding content of jar: file:/C:/Documents%20and% 
20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/ 
standal

one-compiler-custom-3.8.0.jar!/bin/panels/LicencePanel.jar
   [java] Adding content of jar: file:/C:/Documents%20and% 
20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/ 
standal

one-compiler-custom-3.8.0.jar!/bin/panels/TargetPanel.jar
   [java] Adding content of jar: file:/C:/Documents%20and% 
20Settings/sissonj/.ger

Re: Cannot build 1.1 on Windows - long file paths

2006-04-06 Thread Dave Colasurdo

The "long file path" problem on the windows platform isn't limited to 
building G1.1 on this platform.  The current images are incompatible 
with windows even when the images are generated on a different platform..


Specifically, I built G1.1 on linux and then FTP'd the generated windows 
image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows machine..


The resulting image can't unzip on the windows platform due to the path 
length problem.. :(


e.g. 
C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class


Guess this is obvious in hindsight, though was thinking it was strictly 
a build issue..


This absolutely needs to get fixed..

-Dave-


Joe Bohn wrote:


You beat me to it John  I'm hitting the exact same problem.

Joe

John Sisson wrote:
I had issues relating to long file paths when building 1.1 from my 
C:\dev\asf\geronimo\branches\1.1 directory, so I tried building from a 
shorter directory ( C:\geronimo1.1 ) and still have issues (see below).


I haven't had a chance to look into this yet but I consider this to be 
a blocker.


Once we can build on windows we then need to test that Geronimo can be 
installed in common locations on windows (e.g. under C:\Program 
Files\Geronimo-1.1 ) without encountering file path length issues.


The following path (from the output below) is 317 bytes long:

C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1-SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT\daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1-SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis\client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$$2ae63e1d.class 



See http://issues.apache.org/jira/browse/GERONIMO-1790 for more info 
on the long file path issue.


John

izpack:izpack-installer-build:
   [echo] IZPack installer build is running.
   [echo] IZPack Version is 3.8.0
   [java]
   [java] .::  IzPack - Version 3.8.0 ::.
   [java]
   [java] < compiler specifications version : 1.0 >
   [java]
   [java] - Copyright (C) 2001-2005 Julien Ponge
   [java] - Visit http://www.izforge.com/ for the latests releases
   [java] - Released under the terms of the Apache Software License 
version 2.0.

   [java]
   [java] -> Processing  : 
C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml 

   [java] -> Output  : 
C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-installer-1.1-SNAPSHOT.jar 


   [java] -> Base path   : .
   [java] -> Kind: standard
   [java] -> Compression : default
   [java] -> Compr. level: -1
   [java]
   [java] Adding resource: IzPack.uninstaller
   [java] Setting the installer information
   [java] Setting the GUI preferences
   [java] Adding langpack: eng
   [java] Adding resource: flag.eng
   [java] Adding resource: Installer.image
   [java] Adding resource: LicencePanel.licence
   [java] Adding resource: InfoPanel.info
   [java] Adding resource: userInputSpec.xml
   [java] Adding resource: ProcessPanel.Spec.xml
   [java] Adding resource: ImgPacksPanel.img.0
   [java] Adding resource: ImgPacksPanel.img.1
   [java] Adding resource: ImgPacksPanel.img.2
   [java] Adding resource: ImgPacksPanel.img.3
   [java] Adding resource: ImgPacksPanel.img.4
   [java] Adding resource: ImgPacksPanel.img.5
   [java] Adding resource: ImgPacksPanel.img.6
   [java] Adding resource: ImgPacksPanel.img.7
   [java] Adding resource: ImgPacksPanel.img.8
   [java] Adding resource: ImgPacksPanel.img.9
   [java] Adding resource: ImgPacksPanel.img.10
   [java] Adding resource: ImgPacksPanel.img.11
   [java] Adding resource: ImgPacksPanel.img.12
   [java] Adding resource: ImgPacksPanel.img.13
   [java] Adding resource: ImgPacksPanel.img.14
   [java] Adding resource: ImgPacksPanel.img.15
   [java] Adding resource: ImgPacksPanel.img.16
   [java] Adding resource: ImgPacksPanel.img.17
   [java] Adding resource: ImgPacksPanel.img.18
   [java] Adding resource: ImgPacksPanel.img.19
   [java] Adding resource: ImgPacksPanel.img.20
   [java] Adding content of jar: 
file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal 


one-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar
   [java] Adding content of jar: 
file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal 


one-compiler-custom-3.8.0.jar!/bin/panels/LicencePanel.jar
   [java] Adding content of jar: 
file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal 


one-compiler-custom-3.8.0.jar!/bin/panels/TargetPanel.jar
   [java] Adding content of jar: 
file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal 


one-compiler-custom-3.8.0.jar!/bin/panels/ImgPacksPanel.jar
   [java] Add

[jira] Commented: (AMQ-678) MessageCleanup fails with mysql 4.1.x

2006-04-06 Thread Jack Humphrey (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-678?page=comments#action_36000 ] 

Jack Humphrey commented on AMQ-678:
---

I have written a JDBC adapter for ActiveMQ 3.2.2 that replaces this statement 
with a two-step temp table process in order to work with MySQL 4.0. Not sure if 
they have changed the JDBC adapter framework for ActiveMQ 4.0 or not, but I'm 
happy to share a howto if you want it.

> MessageCleanup fails with mysql 4.1.x
> -
>
>  Key: AMQ-678
>  URL: https://issues.apache.org/activemq/browse/AMQ-678
>  Project: ActiveMQ
> Type: Bug

>   Components: Message Store
> Versions: 4.0 M4
> Reporter: Paul Focke
> Priority: Minor

>
>
> When ActiveMQ does a message cleanup using mysql-4.1 for jdbc persistence an 
> error occurs.  ActiveMQ complains that the connection is already closed.  The 
> nested exception however is an EOFException.  The exception is thrown by 
> DefaultJDBCAdapter.doDeleteOldMessages(DefaultJDBCAdapter.java:544).  I poked 
> around I found that the sql statement it produces causes mysql to crash.  It 
> even causes mysqld to crash when entered in the mysql client console, so this 
> is not a Connector/J issue.  Here is the statement
> DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION<>0 AND EXPIRATION<1144326387433) 
> OR ID <= ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM ACTIVEMQ_ACKS WHERE 
> ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
> It can be found in Statements.java:220.
> I have tested this under mysql 4.1.12, 4.1.13 & 5.0.18.  The exceptions were 
> only thrown in mysql 4.1.  5.0 behaved as would be expected.
> Possible solutions would be : 
>  - rewrite the delete statement so that it doesn't kill mysqld : 
> - I had a quick look into rewriting the statement but I haven't found how
> - change the current delete into a select id from ... (this works) and 
> delete records 1 by 1 using the resultSet ( which really sucks when there are 
> lots of messages to be deleted )
>  - not use mysql-4.1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1816) XML based serialized configurations

XML based serialized configurations
---

 Key: GERONIMO-1816
 URL: http://issues.apache.org/jira/browse/GERONIMO-1816
 Project: Geronimo
Type: New Feature
Security: public (Regular issues) 
  Components: kernel  
Reporter: Dain Sundstrom
 Assigned to: Dain Sundstrom 
 Fix For: 1.1


Configurations should be stored in an XML format instead of using Java Object 
Serialization.  This will provide the maximum flexibility and make our 
configuration more future proof.  It also allows an admin to directly modify 
the server in the case of a production outage.

-- 
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-1815) Remove empty config-store directory

Remove empty config-store directory
---

 Key: GERONIMO-1815
 URL: http://issues.apache.org/jira/browse/GERONIMO-1815
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: buildsystem, Maven Plugins for G  
Reporter: Dain Sundstrom
 Fix For: 1.1


The assembly and installer plugins are creating an empty config-store 
directory.   We no longer use a config-store directory so this code should be 
removed.

-- 
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-1814) Add version number XStream serialized configuration files

Add version number XStream serialized configuration files
-

 Key: GERONIMO-1814
 URL: http://issues.apache.org/jira/browse/GERONIMO-1814
 Project: Geronimo
Type: Improvement
Security: public (Regular issues) 
  Components: kernel  
Reporter: Dain Sundstrom
 Assigned to: Dain Sundstrom 
 Fix For: 1.1


We should a version number on the serialized configurations so we can detect 
changes in the format in future version.

-- 
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-1357) Apache Geronimo V1.0 Documentation Draft

2006-04-06 Thread Hernan Cunico (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1357?page=all ]
 
Hernan Cunico resolved GERONIMO-1357:
-

Resolution: Fixed

doc included in Geronimo release 1.0

> Apache Geronimo V1.0 Documentation Draft
> 
>
>  Key: GERONIMO-1357
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1357
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.0
>  Environment: All
> Reporter: Hernan Cunico
> Assignee: Hernan Cunico
>  Attachments: GDoc_2005_12_15.zip, GDoc_2005_12_16.zip, 
> GERONIMO_DOC_2005_12_13.zip
>
> Better later than never, here is the updated HTML documentation.

-- 
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-1611) Apache Geronimo Web site update

2006-04-06 Thread Hernan Cunico (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1611?page=all ]
 
Hernan Cunico closed GERONIMO-1611:
---

Resolution: Fixed

site updated to new template.

> Apache Geronimo Web site update
> ---
>
>  Key: GERONIMO-1611
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1611
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: website
> Reporter: Hernan Cunico
> Assignee: Hernan Cunico
>  Attachments: site.06-02-22.zip, site.06-02-24.diff, site.diff.06-02-13.zip, 
> site.diff.06-02-14.zip, site.diff.06-02-22.diff, site.images.06-02-13.zip, 
> sites_geronimo.06-02-08.zip, sites_geronimo.06-02-09.zip, 
> sites_geronimo.06-02-10.zip, sites_geronimo.06-02-13.zip, 
> sites_geronimo.06-02-17.zip
>
> I have updated the template of the current Apache Geronimo Web site to use 
> the one proposed from EPIQ

-- 
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: JCA Flow

2006-04-06 Thread fretzlaff


I have tried but doesn't work... take a look at my XML:


http://xbean.org/schemas/spring/1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:sm="http://servicemix.apache.org/config/1.0";
xmlns:spring="http://xbean.org/schemas/spring/1.0";
xsi:schemaLocation="http://xbean.org/schemas/spring/1.0 spring-beans.xsd
http://servicemix.apache.org/config/1.0 servicemix.xsd">







--
View this message in context: 
http://www.nabble.com/JCA-Flow-t1405473.html#a3791374
Sent from the ServiceMix - Dev forum at Nabble.com.

[jira] Updated: (GERONIMO-927) Provide a statement cache for TranQL for JDBCs drivers that don't inherintly provide this functionality.

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

Dain Sundstrom updated GERONIMO-927:


Component: connector
   databases

> Provide a statement cache for TranQL for JDBCs drivers that don't inherintly 
> provide this functionality.
> 
>
>  Key: GERONIMO-927
>  URL: http://issues.apache.org/jira/browse/GERONIMO-927
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: connector, databases
> Versions: 1.0-M4
>  Environment: All
> Reporter: Matt Hogstrom
> Assignee: Matt Hogstrom
>  Fix For: 1.1

>
> Not all JDBC providers currently provide a statement cache on a per 
> connection basis.  This can be a very expensive operation that impacts 
> performance of not only Geronimo but of the database being used.

-- 
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-557) smooth application upgrade/versioning

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

Dain Sundstrom updated GERONIMO-557:


Component: deployment
   kernel

> smooth application upgrade/versioning
> -
>
>  Key: GERONIMO-557
>  URL: http://issues.apache.org/jira/browse/GERONIMO-557
>  Project: Geronimo
> Type: New Feature

>   Components: deployment, kernel
> Reporter: David Jencks
>  Fix For: 1.2

>
> There have been several requests for the ability to change fairly fundamental 
> bits of application configuration at runtime, such as which resource a 
> resource-ref points to.  Currently the only way to do this is to redeploy the 
> reconfigured application, and changing this would break a lot of our 
> implementation and some of our philosophy.
> Perhaps a better way to approach this kind of problem is to version 
> applications, and have a process for seamlessly switching between versions of 
> an application.
> So, to change the target of a resource-ref, you'd configure a new "copy" of 
> your app with the new target, deploy it, and undeploy the old version.

-- 
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-1488) externalize sensitive data out of the deployment plans

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

Dain Sundstrom updated GERONIMO-1488:
-

  Component: security
Fix Version: 1.2

> externalize sensitive data out of the deployment plans
> --
>
>  Key: GERONIMO-1488
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1488
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: security
> Versions: 1.2
> Reporter: simon godik
>  Fix For: 1.2

>
> externalize sensitive data out of deployment plans. Reference secure-vault 
> gbean and grant gbean permission to read vault for the given alias; 
> Gbean-permission is granted in the deployment plan; deployment plan syntax 
> needs to be extended  to support gbean permissions

-- 
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-1574) Spring integration with Geronimo Transaction Manager

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

Dain Sundstrom updated GERONIMO-1574:
-

  Summary: Spring integration with Geronimo Transaction Manager  (was: 
Spring integration -- wrap our components in spring interfaces)
Component: transaction manager

> Spring integration with Geronimo Transaction Manager
> 
>
>  Key: GERONIMO-1574
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1574
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: transaction manager
> Versions: 1.2
> Reporter: David Jencks
> Assignee: David Jencks
>  Fix For: 1.2

>
> For a reasonable spring integration, we need to expose some of our components 
> wrapped in spring interfaces.  The most obvious is the transaction manager.

-- 
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-1697) Can't set listen host/IP for Sun CORBA Name Service GBean

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

Dain Sundstrom updated GERONIMO-1697:
-

Component: CORBA

> Can't set listen host/IP for Sun CORBA Name Service GBean
> -
>
>  Key: GERONIMO-1697
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1697
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: CORBA
> Reporter: Aaron Mulder

>
> The Sun CORBA Name Service wrapper GBean lets you specify the port, but not 
> the listen hostname/IP.  It should let you specify both.  The class in 
> question is:
> geronimo/openejb/modules/core/src/java/org/openejb/corba/SunNameService.java
> When this is done, the getAddress() method should be updated to return the 
> proper listen address instead of 0.0.0.0.

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

G1.1 testing - default applications

2006-04-06 Thread Dave Colasurdo

The welcome app, servlets-examples, jsp-examples and ldap-demo work fine 
(unchanged) for both tomcat and jetty with the latest G1.1 build..  Will 
now try the clustering example and others..


-Dave-

[jira] Updated: (GERONIMO-1702) The latest maven 1 Build process

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

Dain Sundstrom updated GERONIMO-1702:
-

Component: buildsystem

> The latest maven 1 Build process
> 
>
>  Key: GERONIMO-1702
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1702
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: buildsystem
>  Environment: All
> Reporter: Anita Kulshreshtha
> Priority: Minor

>
> This task is to keep track of changes to maven 1 build. 

-- 
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-1472) packaging plugin creates client cars with wrong version

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

Dain Sundstrom updated GERONIMO-1472:
-

Component: deployment

> packaging plugin creates client cars with wrong version
> ---
>
>  Key: GERONIMO-1472
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1472
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1, 1.2
> Reporter: David Jencks
> Assignee: David Jencks
>  Fix For: 1.1, 1.2

>
> In branch 1.0.1-SNAPSHOT, starting with daytrader ear 1.0, we get the main 
> car at 1.0.1-SNAPSHOT but the client car at 1.0.

-- 
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-1532) NullPointerException when a badly named jar is put into repository directory

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

Dain Sundstrom updated GERONIMO-1532:
-

  Component: console
Fix Version: 1.1
  Assign To: Aaron Mulder

My guess is you have already fixed this.

> NullPointerException when a badly named jar is put into repository directory
> 
>
>  Key: GERONIMO-1532
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1532
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.0
> Reporter: Heikki Linnakangas
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: 1.1
>  Attachments: listURIs.diff
>
> I copied a JDBC driver jar to geronimo/repository-directory, thinking that 
> geronimo would pick it up from there. What I didn't know, is that jars in the 
> repository need to be named in a particular way.
> I then tried to add a Database pool using the wizard. I filled the name and 
> type in step 1, and clicked next. Instead of step 2, I got a blank screen, 
> and this stack trace in the log:
> 14:30:33,322 ERROR [DatabasePoolPortlet] Unable to render portlet
> java.lang.NullPointerException
>   at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750)
>   at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderBasicParams(DatabasePoolPortlet.java:721)
>   at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:625)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250)
>   at javax.portlet.GenericPortlet.render(GenericPortlet.java:178)
> ...
> The culprit seems to be the FileSystemRepository.listURIs-method, that 
> doesn't handle invalid filenames properly, but returns nulls in the array it 
> returns instead.

-- 
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-1703) ServerInfo.getBaseDirectory() returns null

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

Dain Sundstrom updated GERONIMO-1703:
-

Component: console
Assign To: Aaron Mulder

My guess is this has already been fixed in 1.1

> ServerInfo.getBaseDirectory() returns null
> --
>
>  Key: GERONIMO-1703
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1703
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.0, 1.1, 1.2
>  Environment: Sun JDK 1.4.2_08, Win XP, Geronimo-Tomcat
> Reporter: Vamsavardhana Reddy
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: 1.2
>  Attachments: ServerInfoWebApp.war
>
> Calling getBaseDirectory on org.apache.geronimo.system.serverinfo.ServerInfo 
> returned by KernelManagementHelper.getServerInfo() returns null instead of 
> Geronimo Base 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] Updated: (GERONIMO-1664) Export / Import configurations capability

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

Dain Sundstrom updated GERONIMO-1664:
-

Component: console
Assign To: Aaron Mulder

> Export / Import configurations capability
> -
>
>  Key: GERONIMO-1664
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1664
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.0
> Reporter: Hernan Cunico
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: 1.2

>
> It would be nice to have the option to export (from both command line and 
> Admin Console) applications as well as any other configuration (connection 
> pools, security realms, entire server configuration, etc).
> Having the export capability will provide an alternative method for moving 
> applications and configurations across Geronimo servers. It would also 
> support/promote a standard procedure for backup and restore.

-- 
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-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work

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

Dain Sundstrom updated GERONIMO-1686:
-

  Component: specs
Fix Version: 1.2

> Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
> --
>
>  Key: GERONIMO-1686
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1686
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: specs
> Reporter: Bill Dudney
> Assignee: Jeff Genender
> Priority: Minor
>  Fix For: 1.2
>  Attachments: jee5_exp.patch, jee5_exp_servlet.patch, servlet_fixes.patch
>
> I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the 
> week of 3/6/06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1783) Welcome application i18n

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

Dain Sundstrom updated GERONIMO-1783:
-

  Component: console
 sample apps
Fix Version: 1.2

> Welcome application i18n
> 
>
>  Key: GERONIMO-1783
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1783
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: console, sample apps
> Reporter: Yeray Cabrera Santana
> Priority: Minor
>  Fix For: 1.2
>  Attachments: patch.txt, welcome.diff
>
> Patch for Welcome app includes i18n and Spanish translation. This patch 
> depends on taglibs-i18n-1.0.jar which is not available on any maven repo.

-- 
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-1781) FileSystemRepository not able to handle entry with version number which is a single digit

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

Dain Sundstrom updated GERONIMO-1781:
-

Component: kernel
Assign To: Dain Sundstrom

> FileSystemRepository not able to handle entry with version number which is a 
> single digit
> -
>
>  Key: GERONIMO-1781
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1781
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: kernel
> Versions: 1.0, 1.1, 1.2
> Reporter: Vamsavardhana Reddy
> Assignee: Dain Sundstrom
> Priority: Minor
>  Fix For: 1.1

>
> I see the following in FileSystemRepository.java
>   Pattern.compile("(.+)/(.+)s/(.+)-([0-9].+)\\.([^0-9]+)");
> This reqular expression is not matching an entry like the following.
> group/jars/artifact-1.jar
> Here the version number is "1", a single digit.
> FIX:  Change to Pattern.compile("(.+)/(.+)s/(.+)-([0-9].*)\\.([^0-9]+)")

-- 
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-1732) Module migration to Maven 2: jetty-builder

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

Dain Sundstrom updated GERONIMO-1732:
-

Component: buildsystem

> Module migration to Maven 2: jetty-builder
> --
>
>  Key: GERONIMO-1732
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1732
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Versions: 1.x
> Reporter: Jacek Laskowski
> Assignee: Prasad Kashyap
>  Attachments: jetty-builder-apply-me.patch, jetty-builder.patch
>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1773) Automatic driver download is duplicated

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

Dain Sundstrom updated GERONIMO-1773:
-

Component: console

> Automatic driver download is duplicated
> ---
>
>  Key: GERONIMO-1773
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1773
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.0
> Reporter: Yiannis Mavroukakis
> Priority: Trivial

>
> If the page times out during the download and is refreshed, a second download 
> is initiated. This doesn't impact the installation of the driver.

-- 
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-1693) Module migration to Maven2: j2ee-schema

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

Dain Sundstrom updated GERONIMO-1693:
-

Component: buildsystem

> Module migration to Maven2: j2ee-schema
> ---
>
>  Key: GERONIMO-1693
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1693
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Reporter: Anita Kulshreshtha
> Assignee: Anita Kulshreshtha
> Priority: Blocker
>  Attachments: pom.patch, pom.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1730) Module migration to Maven 2: interop

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

Dain Sundstrom updated GERONIMO-1730:
-

Component: buildsystem

> Module migration to Maven 2: interop
> 
>
>  Key: GERONIMO-1730
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1730
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Versions: 1.x
> Reporter: Jacek Laskowski
> Assignee: Jacek Laskowski

>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1785) Application migration to Maven 2: magicGball

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

Dain Sundstrom updated GERONIMO-1785:
-

Component: buildsystem

> Application migration to Maven 2: magicGball
> 
>
>  Key: GERONIMO-1785
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1785
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Reporter: Prasad Kashyap
> Assignee: Prasad Kashyap
>  Attachments: magicGball.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1659) Module migration to Maven 2: system

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

Dain Sundstrom updated GERONIMO-1659:
-

Component: buildsystem

> Module migration to Maven 2: system
> ---
>
>  Key: GERONIMO-1659
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1659
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Reporter: Anders Hessellund Jensen
> Assignee: Jacek Laskowski
>  Attachments: maven-timestamp-plugin.zip, 
> org.apache.geronimo.system.serverinfo.ServerInfoTest.txt, pom.patch, 
> system-m2-migration-new.patch, system-m2-migration.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1698) Module migration to Maven2: hot-deploy

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

Dain Sundstrom updated GERONIMO-1698:
-

Component: buildsystem

> Module migration to Maven2: hot-deploy
> --
>
>  Key: GERONIMO-1698
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1698
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Reporter: Rakesh Ranjan
> Priority: Minor
>  Attachments: pom.xml
>


-- 
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-1665) Module migration to Maven2: axis

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

Dain Sundstrom updated GERONIMO-1665:
-

Component: buildsystem

> Module migration to Maven2: axis
> 
>
>  Key: GERONIMO-1665
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1665
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Reporter: Henri Yandell
>  Attachments: GERONIMO-1665.patch
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1654) Itests in M2 (for openejb and others too)

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

Dain Sundstrom updated GERONIMO-1654:
-

Component: buildsystem

> Itests in M2 (for openejb and others too)
> -
>
>  Key: GERONIMO-1654
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1654
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Reporter: Prasad Kashyap
> Assignee: Jacek Laskowski
>  Attachments: itests.zip
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1725) Module migration to Maven 2: client-builder

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

Dain Sundstrom updated GERONIMO-1725:
-

Component: buildsystem

> Module migration to Maven 2: client-builder
> ---
>
>  Key: GERONIMO-1725
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1725
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Versions: 1.x
> Reporter: Jacek Laskowski
> Assignee: Prasad Kashyap
>  Attachments: pom.xml
>
> It's a task to help keep track of the progress of the module build migration 
> to Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1731) Module migration to Maven2: jetty

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

Dain Sundstrom updated GERONIMO-1731:
-

Component: buildsystem

> Module migration to Maven2: jetty
> -
>
>  Key: GERONIMO-1731
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1731
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem
> Versions: 1.x
> Reporter: Jacek Laskowski
> Assignee: Prasad Kashyap
>  Attachments: jetty.patch
>
> It's a task to keep track of the progress of the module build migration to 
> Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1655) Daytrader MDBs do not start properly

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

Dain Sundstrom updated GERONIMO-1655:
-

Component: sample apps

> Daytrader MDBs do not start properly
> 
>
>  Key: GERONIMO-1655
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1655
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: sample apps
> Versions: 1.1
>  Environment: All (j2ee-jetty-server and j2ee-tomcat-server, rev 380210) 
> Reporter: Anita Kulshreshtha
>  Fix For: 1.1

>
> The following MDBs of Daytrader application do not start during startup of 
> the server : 
> .
> WARNING: Some GBeans were not started successfully:
> TradeStreamerMDB (starting)
> TradeBrokerMDB (starting) 
>  This affects both jetty and tomcat servers.
> These are waiting for MdbContainer to start, which in turn is waiting for 
> Timers . All the timers NonTransactionalThreadPooledTimer etc are being 
> started properly,  but MdbContainer is looking for non existent GBeans, i.e. 
> the name part of the reference is NonTransactionalThreadPooledTimer,*  Here 
> is an example :
> 13:00:24,437 DEBUG [GBeanSingleReference] Waiting to start 
> geronimo.server:J2EEApplication=null,J2EEModule=geronimo/openejb/1.1-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=MdbContainer,name=MdbEjbContainer
>  because no targets are running for reference NontransactedTimer matching the 
> patterns 
> geronimo.server:J2EEApplication=null,J2EEServer=geronimo,j2eeType=GBean,name=NonTransactionalThreadPooledTimer,*
>  

-- 
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-1483) During Undeploy entry in config.xml is not removed

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

Dain Sundstrom updated GERONIMO-1483:
-

Component: console
   deployment

> During Undeploy entry in config.xml is not removed
> --
>
>  Key: GERONIMO-1483
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1483
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console, deployment
>  Environment: WinXP, JDK1.4.2_09 X86 Intel
> Reporter: Manu T George
> Assignee: Aaron Mulder
> Priority: Minor

>
> Suppose I have two modules A and B and A is dependant  on B. Usually we first 
> remove A and then  B . This works fine. If we remove B and then A then the 
> entry in config.xml is not removed and the server does not allow me to again 
> deploy the module A. This problem was noticed on running the deploy command. 
> from console

-- 
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: New Feature Idea


Shouldn't update our QName implementation to be compatiable with 1.5?

Also, if we do ship with the XStream based configs on we no longer  
will have this problem.


-dain

On Apr 6, 2006, at 11:45 AM, Aaron Mulder wrote:


I didn't think there were problems with web services in Geronimo in
general between 1.4 and 1.5 -- I thought it's only the fact that
QNames are serialized that causes problem.  I wouldn't expect to have
a problem with an application that calls a web service or is called
via a web service so long as it doesn't do any Java serialization
involving QNames.  Is that not correct?  (Does Geronimo itself do the
QName serialization for certain types of Web Services apps?)

Thanks,
 Aaron

On 4/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
To be clear.  The reason DayTrader has an issue is that it uses  
WebServices and specifically it has
to do with the javax.xml.namespace.QName class has different  
serialization characteristics between
1.4 and 1.5.  So, if someone wants to move back and forth between  
1.4 and 1.5 and their using

WebServices they'll still have issues.

Aaron Mulder wrote:

We already support JDK 1.5 except for CORBA.  Because of the CORBA
limitation Geronimo can't be certified on JDK 1.5, but if you leave
CORBA disabled (and turn off the DayTrader sample application)
Geronimo should run fine on 1.5.

Thanks,
Aaron

On 4/6/06, Christopher Stura <[EMAIL PROTECTED]> wrote:


support for sun jdk 1.5

[jira] Assigned: (GERONIMO-1483) During Undeploy entry in config.xml is not removed

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

Dain Sundstrom reassigned GERONIMO-1483:


Assign To: Aaron Mulder

Can you verify that this has been fixed once you get the console working.

> During Undeploy entry in config.xml is not removed
> --
>
>  Key: GERONIMO-1483
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1483
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>  Environment: WinXP, JDK1.4.2_09 X86 Intel
> Reporter: Manu T George
> Assignee: Aaron Mulder
> Priority: Minor

>
> Suppose I have two modules A and B and A is dependant  on B. Usually we first 
> remove A and then  B . This works fine. If we remove B and then A then the 
> entry in config.xml is not removed and the server does not allow me to again 
> deploy the module A. This problem was noticed on running the deploy command. 
> from console

-- 
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-624) WinXP: Testsuite: org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest failed

 [ http://issues.apache.org/jira/browse/GERONIMO-624?page=all ]
 
Dain Sundstrom closed GERONIMO-624:
---

Resolution: Fixed

I'm guessing this is no longer a problem since you haven't complained about it 
since summer of last year.

> WinXP: Testsuite: org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest 
> failed
> 
>
>  Key: GERONIMO-624
>  URL: http://issues.apache.org/jira/browse/GERONIMO-624
>  Project: Geronimo
> Type: Bug

> Versions: 1.0-M4
>  Environment: Windows XP SP2
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
> Reporter: John Sisson
> Priority: Minor
>  Fix For: Wish List

>
> At svn rev 159684. Was running maven with -X flag at the time trying to track 
> down a different problem.  
> Testsuite: org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest
> Tests run: 7, Failures: 0, Errors: 5, Time elapsed: 3.891 sec
> - Standard Error -
> log4j:WARN No appenders could be found for logger 
> (org.axiondb.engine.BaseDatabase).
> log4j:WARN Please initialize the log4j system properly.
> -  ---
> Testcase: 
> testASetBNewAB(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest):  
>   Caused an ERROR
> Access is denied
> java.io.IOException: Access is denied
>   at java.io.WinNTFileSystem.createFileExclusively(Native Method)
>   at java.io.File.checkAndCreate(File.java:1314)
>   at java.io.File.createTempFile(File.java:1402)
>   at java.io.File.createTempFile(File.java:1439)
>   at 
> org.apache.geronimo.deployment.util.DeploymentUtil.createTempDir(DeploymentUtil.java:58)
>   at 
> org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:176)
>   at 
> org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest.setUp(OneToOneTest.java:617)
> Testcase: 
> testBSetANewAB(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest):  
>   Caused an ERROR
> A kernel is already running this kernel name: bar
> java.lang.IllegalStateException: A kernel is already running this kernel 
> name: bar
>   at org.apache.geronimo.kernel.Kernel.boot(Kernel.java:437)
>   at 
> org.openejb.deployment.KernelHelper.getPreparedKernel(KernelHelper.java:48)
>   at 
> org.openejb.deployment.DeploymentHelper.setUpKernelWithTransactionManager(DeploymentHelper.java:118)
>   at 
> org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:157)
>   at 
> org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest.setUp(OneToOneTest.java:617)
> Testcase: 
> testASetBExistingBNewA(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest):
> Caused an ERROR
> A kernel is already running this kernel name: bar
> java.lang.IllegalStateException: A kernel is already running this kernel 
> name: bar
>   at org.apache.geronimo.kernel.Kernel.boot(Kernel.java:437)
>   at 
> org.openejb.deployment.KernelHelper.getPreparedKernel(KernelHelper.java:48)
>   at 
> org.openejb.deployment.DeploymentHelper.setUpKernelWithTransactionManager(DeploymentHelper.java:118)
>   at 
> org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:157)
>   at 
> org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest.setUp(OneToOneTest.java:617)
> Testcase: 
> testBSetAExistingBNewA(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest):
> Caused an ERROR
> A kernel is already running this kernel name: bar
> java.lang.IllegalStateException: A kernel is already running this kernel 
> name: bar
>   at org.apache.geronimo.kernel.Kernel.boot(Kernel.java:437)
>   at 
> org.openejb.deployment.KernelHelper.getPreparedKernel(KernelHelper.java:48)
>   at 
> org.openejb.deployment.DeploymentHelper.setUpKernelWithTransactionManager(DeploymentHelper.java:118)
>   at 
> org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:157)
>   at 
> org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest.setUp(OneToOneTest.java:617)
> Testcase: 
> testCascadeDelete(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest):
>  Caused an ERROR
> A kernel is already running this kernel name: bar
> java.lang.IllegalStateException: A kernel is already running this kernel 
> name: bar
>   at org.apache.geronimo.kernel.Kernel.boot(Kernel.java:437)
>   at 
> org.openejb.deployment.KernelHelper.getPreparedKernel(KernelHelper.java:48)
>   at 
> org.openejb.deployment.DeploymentHelper.setUpKernelWithTransactionManager(DeploymentHelper.java:118)
>   at 
> org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:157)
>   at 
> org.openejb.deployment.entity.cmp.c

[jira] Updated: (GERONIMO-631) Package Derby tools with Geronimo

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

Dain Sundstrom updated GERONIMO-631:


Component: databases

> Package Derby tools with Geronimo
> -
>
>  Key: GERONIMO-631
>  URL: http://issues.apache.org/jira/browse/GERONIMO-631
>  Project: Geronimo
> Type: Improvement

>   Components: databases
> Versions: 1.0-M4
> Reporter: John Sisson
> Assignee: John Sisson
> Priority: Minor
>  Fix For: 1.2

>
> IBM now has donated the JDBC network driver code to the Derby project (as a 
> patch) and it is under review (not committed).  Once it has been accepted and 
> included in a formal Derby release, it would be worthwhile including it with 
> Geronimo, along with some simple scripts to invoke Derby's ij tool, so 
> Geronimo users can easily manage the embedded Derby database(s).
> FYI.. the donated JDBC network driver supports XA.
> Here is a mail thread titled "Provision of derby tools JAR and JDBC network 
> driver JAR" from the dev list...
> [EMAIL PROTECTED] wrote:
> > If a Java application (not J2EE app) provides a database creation utility 
> > and expects to be able to use a JDBC network driver to connect to the 
> > Derby network server embedded in Geronimo, then currently the command line 
> > application (the database creation utility) needs access (assuming the IBM 
> > Universal Driver is used) to db2jcc.jar and db2jcc_license_c.jar . 
> > 
> > On the Derby lists I saw that IBM is planning on donating a JDBC network 
> > driver sometime in March. 
> > 
> > Q1. Would it make sense to place this driver jar and the derbytools jar in 
> > the  geronimo/repository/incubator-derby/jars directory to accompany the 
> > other derby jars so we provide all the required jars needed for connecting 
> > to and administering the Derby database embedded in Geronimo (even though 
> > the driver or tools won't be loaded by Geronimo)?
> > 
> Yes - we already configure and start the network server so having the 
> client jars available would make sense. These could also be used to 
> connect to a Derby instance in a different JVM.
> > Q2. Even if we do provide all the JARs in the repository, users of a 
> > command line Java application (running on the same machine) would probably 
> > have to edit their classpath to point to the correct  version of JDBC 
> > driver that matches the version of Derby embedded in Geronimo.  Any 
> > suggestions on how this could be automated (determining the version and 
> > getting the driver JAR)?
> > 
> I think it would depend on how the client app expected this to work and 
> whether it relied on having them in the system classpath or did some 
> fancy uber-jar type thing.
> One option would be to deploy the client along with the server (EAR) as 
> a J2EE Application Client. IIRC the app client can have a plan 
> associated with it where they can specify dependencies just like with 
> server-side modules.
> --
> Jeremy

-- 
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-1636) Support optional version number on dependencies

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

Dain Sundstrom updated GERONIMO-1636:
-

Component: kernel

> Support optional version number on dependencies
> ---
>
>  Key: GERONIMO-1636
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1636
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: kernel
> Versions: 1.0
> Reporter: Dain Sundstrom
> Assignee: David Jencks
>  Fix For: 1.1

>
> Add support for making the version number of a dependency optional.  In the 
> case of a missing version number a pluggable strategy should choose the 
> actual version to load.

-- 
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-1808) Replace AbstractName with URI

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

Dain Sundstrom updated GERONIMO-1808:
-

Component: kernel

> Replace AbstractName with URI
> -
>
>  Key: GERONIMO-1808
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1808
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: kernel
> Reporter: Dain Sundstrom
> Assignee: Dain Sundstrom
>  Fix For: 1.2

>
> Using a custom name class for Geronimo causes unnecessary extra dependencies 
> on Geronimo jars. Instead of using a custom name class we can instead just 
> encode our name into a URI.  The following describes the current proposal:
> http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Service+Names

-- 
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-1782) Properties File Login module fails after editing through Admin Console

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

Dain Sundstrom updated GERONIMO-1782:
-

Component: security

> Properties File Login module fails after editing through Admin Console
> --
>
>  Key: GERONIMO-1782
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1782
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: security
> Versions: 1.0, 1.1, 1.2
>  Environment: Win XP, Sun JDK 1.4.2_08
> Reporter: Vamsavardhana Reddy
>  Fix For: 1.1, 1.2

>
> Geronimo-properties-realm fails to initialize after editing the realm thru 
> Admin Console.
> Steps to reproduce the problem.
> 1.  Open the "Security Realms" portlet in Admin Console.
> 2.  Click on "edit" link provided next to "geronimo-properties-realm.
> 3.  Click on "Save" button in the next page.  PS: No need to edit anything in 
> this page.
> 4.  Restart the server.
> 5.  Access Admin Console to notice that the realm nolonger works.
> NOTE:  To make the realm work again, stop the server and remove the following 
> xml fragment from var/config/config.xml
>  name="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo,j2eeType=LoginModule,name=properties-login">
>   {usersURI=var/security/users.properties, 
> groupsURI=var/security/groups.properties}
>   True
>   False
>name="loginModuleClass">org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule
> 
> At step 5, the following exception is logged to geronimo.log.
> 13:53:41,950 ERROR [PropertiesFileLoginModule] Initialization failed
> java.lang.IllegalArgumentException: Both usersURI and groupsURI must be 
> provided!
>   at 
> org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.initialize(PropertiesFileLoginModule.java:77)
>   at 
> org.apache.geronimo.security.jaas.server.JaasLoginService.getServerLoginCallbacks(JaasLoginService.java:205)
>   at 
> org.apache.geronimo.security.jaas.server.JaasLoginService$$FastClassByCGLIB$$95b84fc9.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.GBeanOperation.invoke(GBeanOperation.java:118)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
>   at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>   at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
>   at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>   at 
> org.apache.geronimo.security.jaas.server.JaasLoginServiceMBean$$EnhancerByCGLIB$$7dca63e6.getServerLoginCallbacks()
>   at 
> org.apache.geronimo.security.jaas.client.ServerLoginProxy.login(ServerLoginProxy.java:68)
>   at 
> org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.performLogin(JaasLoginCoordinator.java:189)
>   at 
> org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.login(JaasLoginCoordinator.java:113)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at java.lang.reflect.Method.invoke(Unknown Source)
>   at javax.security.auth.login.LoginContext.invoke(Unknown Source)
>   at javax.security.auth.login.LoginContext.access$000(Unknown Source)
>   at javax.security.auth.login.LoginContext$4.run(Unknown Source)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.login.LoginContext.invokeModule(Unknown Source)
>   at javax.security.auth.login.LoginContext.login(Unknown Source)
>   at 
> org.apache.geronimo.jetty.JAASJettyRealm.authenticate(JAASJettyRealm.java:94)
>   at 
> org.mortbay.jetty.servlet.FormAuthenticator$FormCredential.authenticate(FormAuthenticator.java:305)
>   at 
> org.mortbay.jetty.servlet.FormAuthenticator.authenticate(FormAuthenticator.java:148)
>   at 
> org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.obtainUser(SecurityContextBeforeAfter.java:282)
>   at 
> org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:191)
>   at 
> org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:585)
>   at 
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:432)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
>   at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
>

[jira] Updated: (GERONIMO-1492) Many "org/apache/geronimo" configIds still live in source tree

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

Dain Sundstrom updated GERONIMO-1492:
-

Fix Version: (was: 1.2)

> Many "org/apache/geronimo" configIds still live in source tree
> --
>
>  Key: GERONIMO-1492
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1492
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
> Versions: 1.0
> Reporter: Aaron Mulder
>  Fix For: 1.1

>
> I created a couple separate issues, but beyond those a quick search brought 
> up a few more in magic G ball and day trader -- I stopped before it went any 
> further, but we should grep for that and try to eliminate all the references 
> to old-style config IDs.

-- 
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: New Feature Idea

I didn't think there were problems with web services in Geronimo in
general between 1.4 and 1.5 -- I thought it's only the fact that
QNames are serialized that causes problem.  I wouldn't expect to have
a problem with an application that calls a web service or is called
via a web service so long as it doesn't do any Java serialization
involving QNames.  Is that not correct?  (Does Geronimo itself do the
QName serialization for certain types of Web Services apps?)

Thanks,
 Aaron

On 4/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
> To be clear.  The reason DayTrader has an issue is that it uses WebServices 
> and specifically it has
> to do with the javax.xml.namespace.QName class has different serialization 
> characteristics between
> 1.4 and 1.5.  So, if someone wants to move back and forth between 1.4 and 1.5 
> and their using
> WebServices they'll still have issues.
>
> Aaron Mulder wrote:
> > We already support JDK 1.5 except for CORBA.  Because of the CORBA
> > limitation Geronimo can't be certified on JDK 1.5, but if you leave
> > CORBA disabled (and turn off the DayTrader sample application)
> > Geronimo should run fine on 1.5.
> >
> > Thanks,
> > Aaron
> >
> > On 4/6/06, Christopher Stura <[EMAIL PROTECTED]> wrote:
> >
> >>support for sun jdk 1.5
> >>
> >>
> >
> >
> >
> >
>

[jira] Updated: (GERONIMO-1637) Add support for version ranges

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

Dain Sundstrom updated GERONIMO-1637:
-

Component: kernel

> Add support for version ranges
> --
>
>  Key: GERONIMO-1637
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1637
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: kernel
> Reporter: Dain Sundstrom
> Assignee: Dain Sundstrom
>  Fix For: 1.2

>
> Add support for the version ranges on dependencies.  Should support the full 
> syntax of maven version ranges.

-- 
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-1462) Finish implementing inverseClassloading attribute in plan schemas

 [ http://issues.apache.org/jira/browse/GERONIMO-1462?page=all ]
 
Dain Sundstrom closed GERONIMO-1462:


Fix Version: 1.1
 (was: 1.2)
 (was: 1.x)
 Resolution: Fixed

> Finish implementing inverseClassloading attribute in plan schemas
> -
>
>  Key: GERONIMO-1462
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1462
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: David Jencks
>  Fix For: 1.1

>
> The inverseClassloading attribute is declared in geronimo-config-1.0.xsd.
> It appears to be used in:
>  - geronimo-application-1.0
>  - geronimo-connector-1.0
>  - geronimo-jetty-1.0
>  - openejb-jar-2.0
> It should be added to:
>  - geronimo-web-1.0
>  - geronimo-tomcat-1.0
>  - geronimo-application-client-1.0 (not totally sure about this one)
> However, we need to decide whether to rev the version numbers of those 
> schemas when we make the change.  I would be inclined to not change the 
> namespace or version in the file name, but to add an internal version history 
> in the header comment of the schemas.  Mainly because that's how Sun does it 
> with the J2EE schemas, and I think it would be a huge pain to try to get 
> people to update their namespaces every time we have a tiny change.

-- 
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-241) GBean proxy code could use improvement

 [ http://issues.apache.org/jira/browse/GERONIMO-241?page=all ]
 
Dain Sundstrom closed GERONIMO-241:
---

Resolution: Fixed

> GBean proxy code could use improvement
> --
>
>  Key: GERONIMO-241
>  URL: http://issues.apache.org/jira/browse/GERONIMO-241
>  Project: Geronimo
> Type: Improvement

>   Components: kernel
> Versions: 1.0-M2
> Reporter: Jeremy Boynes
> Assignee: Dain Sundstrom
>  Fix For: 1.1

>
> Added support for proxies that use reflection or cglib depending on ig cglib 
> is available - there is a lot of redundent code that could be cleaned 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-241) GBean proxy code could use improvement

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

Dain Sundstrom updated GERONIMO-241:


  Component: kernel
Fix Version: 1.1
 (was: Wish List)
  Assign To: Dain Sundstrom

> GBean proxy code could use improvement
> --
>
>  Key: GERONIMO-241
>  URL: http://issues.apache.org/jira/browse/GERONIMO-241
>  Project: Geronimo
> Type: Improvement

>   Components: kernel
> Versions: 1.0-M2
> Reporter: Jeremy Boynes
> Assignee: Dain Sundstrom
>  Fix For: 1.1

>
> Added support for proxies that use reflection or cglib depending on ig cglib 
> is available - there is a lot of redundent code that could be cleaned 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] Closed: (GERONIMO-232) The ${geronimo.home}/config-store should be created if missing prior to deployment.

 [ http://issues.apache.org/jira/browse/GERONIMO-232?page=all ]
 
Dain Sundstrom closed GERONIMO-232:
---

Fix Version: 1.1
 (was: 1.x)
 Resolution: Invalid

We no longer have a config-store directory

> The ${geronimo.home}/config-store  should be created if missing prior to 
> deployment.
> 
>
>  Key: GERONIMO-232
>  URL: http://issues.apache.org/jira/browse/GERONIMO-232
>  Project: Geronimo
> Type: Improvement

> Reporter: Jason van Zyl
>  Fix For: 1.1

>
> If you nuke the ${geronimo.home}/config-store directory to start afresh an 
> error occurs during subsequent deployments.

-- 
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-1694) Improve Serviceability of Geronimo

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

Dain Sundstrom updated GERONIMO-1694:
-

  Component: kernel
Fix Version: 1.1
  Assign To: Dain Sundstrom

> Improve Serviceability of Geronimo
> --
>
>  Key: GERONIMO-1694
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1694
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: kernel
>  Environment: All
> Reporter: Matt Hogstrom
> Assignee: Dain Sundstrom
>  Fix For: 1.1

>
> Currently Geronimo requires significant intervention on the part of the user 
> when applying fixes to a Geronimo server instance.  The interventions can 
> range from something as simple as reading a set of iinstructions and making a 
> manual change to haveing to rebuild the entire server to introduce a required 
> fix into their environment.  Geronimo needs a servicebility strategy that 
> will allow fixes to be introduced to the users environment in the least 
> disruptive way.  This involves a number of elements like a fix installer, 
> ability to know what service level Geronimo is at, attention to 
> serialVersionUID issues, etc.  
> This JIRA highlights a significant barrier to wide range adoption of Geronimo 
> for users of a commercial nature in terms of disruption to production use 
> when some fixes are introduced into the environment.

-- 
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: Update: AMQ C++ Client: First working draft

2006-04-06 Thread Hiram Chirino

Then that sounds like a problem.  I'll look into it.

On 4/6/06, Mats Forslöf <[EMAIL PROTECTED]> wrote:
> Hi Hiram,
>
> Yes, it is the content length but its value is always 4 less than the actual 
> content length (calculated from the first content byte at position 5).
>
> Regards,
> Mats
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino
> Sent: den 5 april 2006 18:31
> To: activemq-dev@geronimo.apache.org
> Subject: Re: Update: AMQ C++ Client: First working draft
>
> Hi Mats,
>
> Feature.  Consider it to be like content-length
>
> Regards,
> Hiram
>
> On 4/5/06, Mats Forslöf <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > A new update has been uploaded to 
> > http://issues.apache.org/activemq/browse/AMQ-656, see issue for more 
> > details.
> >
> > When debugging the OpenWire protocol we've found an issue; the size
> > counter (first 4 bytes) of all packages received from the server is
> > always 4 numbers short of the actual package size (excluding the
> > counter itself)!? Bug or feature?? :)
> >
> > Regards,
> > Mats
> >
> >
>
>
> --
> Regards,
> Hiram
>


--
Regards,
Hiram

Re: 1.1 repo/configstore

2006-04-06 Thread Sachin Patel

I think having the index.properties to know what configurations will  
be started on launch was useful information.  I'd like to see a  
replacement for this in some form or another, perhaps something like  
what we discussed on one of the other threads yesterday having an xml  
file perhaps listing useful information about each application like  
the full configID, state, messages, etc..., so rather having to go to  
the console we have single file that users could go to.


In addition as far as the repo structure... I think something simple  
would suffice for now just to break apart user apps from system  
configuration and libraries.


../G11/repository/
../G11/applications/

Perhaps there may be some value later down to break it down even  
further... as to seperate system stuff/users stuff/libraries/ 
configurations like so...


../G1.1/system/repository/
../G1.1/system/applications/
../G1.1/usr/repository  (libraries)
../G1.1/usr/applications (actual configurations)

I'm not completely thrilled on this structure but hopefully it will  
bring trigger other ideas..


thx

- sachin



On Apr 6, 2006, at 11:49 AM, Dain Sundstrom wrote:



On Apr 6, 2006, at 6:26 AM, Sachin Patel wrote:

So I just launched 1.1 and have a couple of questions...  So it  
looks like the repository now hosts both configurations and  
runtime/user jars.  This is really good but my concern is now that  
user apps are not located in a separate location and when looking  
for a given application I was overwhelmed and took me more time  
then it should to find my app.  So the question is would it be  
possible to provide multiple repositories and configurations would  
be deployed to it?  I'm not sure if this is possible or how  
complex it would be if it were possible and wether these multiple  
repo's could be made aware of each other.


We can organize the repos how every you want.  Just propose what  
you want.


Secondly is there an equivalent to index.properties?  If I wanted  
to uninstall an app, where can I find the fully qualified artifact  
ID?


No there is not an index.properties file.  As for how you get the  
fully qualified artifact ID to uninstall an application, I think it  
depends on how you got the application in the first place.  If you  
know the directory in the repo, then you can work out the  
application id from the directory structure.  If you got the  
application from a running server, then you should already have the  
application id.


Second question is that in 1.0 web apps were exploded so users if  
wanted could easily modify running content if they wanted.  This  
is no longer and I assume this is because both webcontainer have  
moved to using the configuation classloader is this assumption  
correct?


As you discovered they are directories.

On Apr 6, 2006, at 6:55 AM, Sachin Patel wrote:
And just so I get my terminology straight... is the term "config- 
store" obsolete now? Or is there still a technical distinction  
between a config-store and repository?


At the filesystem level there is no config-store?  At least there  
won't be one once someone mangages to remove it from the assembly  
plugin maven.xml file.


-dain

Re: celtix-geronimo integration redux

2006-04-06 Thread Jeff Genender

Forgot to answer your other question.

I don't know if you can change the class of a current named bean.  Dain
or David Jencks may be able to answer that.

But I *think*, you can shut off the gbean as I explained in my last
email, then redeclare it in the config.xml.

Here is an example of a new ConnectorGBean that is declared in the
Tomcat configuration section of the config.xml:


  HTTP
  0.0.0.0
  9090
  MyNewHTTPListener
  

geronimo.server:J2EEApplication=null,J2EEModule=geronimo/tomcat/1.0/car,J2EEServer=geronimo,j2eeType=GBean,name=TomcatWebContainer
  


I am sure the others may be able to tweak this, but this should be in
the right general direction.

Jeff

Conrad O'Dea wrote:
> Hi there,
> 
> Right now I've got to the stage where I can, with a bit of tweaking of
> the config.xml, deploy Celtix to Geronimo and have it handle Web Service
> deployments.  This is on 1.2 where the deployers for wars, ejb jars and
> webservices are all separate so it's pretty straightforward to change
> configuration so that a Celtix deployer is used.  Thanks for the help in
> making that work.
> 
> 1.0/1.1 is another story, though.  Here, the j2ee-deployer directly
> configures the GBeans it uses for deploying web services etc.  I've
> tried overriding the class for the WebServiceBuilder in the config.xml
> but it is ignored.  In fact as the server is starting the config.xml is
> overwritten and my change is erased.
> 
> In the config.xml, should be possible to change the name of the class
> that implements a particular GBean? Can I prevent a GBean from being
> loaded?
> 
> thanks
> Conrad

Re: New Feature Idea

To be clear.  The reason DayTrader has an issue is that it uses WebServices and specifically it has 
to do with the javax.xml.namespace.QName class has different serialization characteristics between 
1.4 and 1.5.  So, if someone wants to move back and forth between 1.4 and 1.5 and their using 
WebServices they'll still have issues.


Aaron Mulder wrote:

We already support JDK 1.5 except for CORBA.  Because of the CORBA
limitation Geronimo can't be certified on JDK 1.5, but if you leave
CORBA disabled (and turn off the DayTrader sample application)
Geronimo should run fine on 1.5.

Thanks,
Aaron

On 4/6/06, Christopher Stura <[EMAIL PROTECTED]> wrote:


support for sun jdk 1.5

Re: celtix-geronimo integration redux

2006-04-06 Thread Jeff Genender

You can prevent a GBean from being loded with the following:

celtix-geronimo integration redux

2006-04-06 Thread Conrad O'Dea


Hi there,

Right now I've got to the stage where I can, with a bit of tweaking  
of the config.xml, deploy Celtix to Geronimo and have it handle Web  
Service deployments.  This is on 1.2 where the deployers for wars,  
ejb jars and webservices are all separate so it's pretty  
straightforward to change configuration so that a Celtix deployer is  
used.  Thanks for the help in making that work.


1.0/1.1 is another story, though.  Here, the j2ee-deployer directly  
configures the GBeans it uses for deploying web services etc.  I've  
tried overriding the class for the WebServiceBuilder in the  
config.xml but it is ignored.  In fact as the server is starting the  
config.xml is overwritten and my change is erased.


In the config.xml, should be possible to change the name of the class  
that implements a particular GBean? Can I prevent a GBean from being  
loaded?


thanks
Conrad

RE: FW: InstanceAlreadyExistsException when creating Connections without start them

2006-04-06 Thread Li, Fan

I am running only one broker and trying to make multiple connections to it. 
Thanks for commit the patch.

Fan

-Original Message-
From: James Strachan [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 06, 2006 8:55 AM
To: activemq-dev@geronimo.apache.org
Subject: Re: FW: InstanceAlreadyExistsException when creating Connections 
without start them

On 4/6/06, Li, Fan <[EMAIL PROTECTED]> wrote:
> This problem stops to appear if I change the variable nextConnectionId from 
> long to static long, since it now generate different names for each 
> Connection it tries to register with the MBeanServer.

Ah I see. I've committed your patch to SVN HEAD which should fix this issue. I 
wonder, is your issue caused by running multiple brokers - or is it multiple 
connectors clashing? No worries though, this issue shouldn't occur again

--

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

Re: 1.1 repo/configstore



On Apr 6, 2006, at 6:26 AM, Sachin Patel wrote:

So I just launched 1.1 and have a couple of questions...  So it  
looks like the repository now hosts both configurations and runtime/ 
user jars.  This is really good but my concern is now that user  
apps are not located in a separate location and when looking for a  
given application I was overwhelmed and took me more time then it  
should to find my app.  So the question is would it be possible to  
provide multiple repositories and configurations would be deployed  
to it?  I'm not sure if this is possible or how complex it would be  
if it were possible and wether these multiple repo's could be made  
aware of each other.


We can organize the repos how every you want.  Just propose what you  
want.


Secondly is there an equivalent to index.properties?  If I wanted  
to uninstall an app, where can I find the fully qualified artifact ID?


No there is not an index.properties file.  As for how you get the  
fully qualified artifact ID to uninstall an application, I think it  
depends on how you got the application in the first place.  If you  
know the directory in the repo, then you can work out the application  
id from the directory structure.  If you got the application from a  
running server, then you should already have the application id.


Second question is that in 1.0 web apps were exploded so users if  
wanted could easily modify running content if they wanted.  This is  
no longer and I assume this is because both webcontainer have moved  
to using the configuation classloader is this assumption correct?


As you discovered they are directories.

On Apr 6, 2006, at 6:55 AM, Sachin Patel wrote:
And just so I get my terminology straight... is the term "config- 
store" obsolete now? Or is there still a technical distinction  
between a config-store and repository?


At the filesystem level there is no config-store?  At least there  
won't be one once someone mangages to remove it from the assembly  
plugin maven.xml file.


-dain

Re: Tomcat access logs

Yes, I think Jetty shoudl work the same way, and if we get a
loggingEnabled flag in there or something similar, the console web
access log can work the same way as the web statistics in that if it's
not enabled it'll have a bit saying something to the effect of "The
web access log is currently disabled.  Please consult your HTTP server
log if Geronimo is running through e.g. Apache or IIS, or else [Enable
Access Log]" (that last bit a link or button).

Thanks,
Aaron

On 4/6/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
> Sounds like a good idea.  Questions:
>
> -  should the access logs for jetty also be disabled by default (for
> consistency)
> -  how should the web access log viewer in the console react to this change?
>
>
> Paul
>
> On 4/5/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> > A while back, someone had requested that the access logs for Tomcat be
> > turned on by default in Geronimo.  This basically involved enabling the
> > Tomcat AccessLogValve, and this request was granted.
> >
> > Upon further review, it would seem that other application servers leave
> > this off by default.  In fact, Tomcat itself leaves this off by default.
> >  I suppose that the reason for this is most Java web implementations are
> > front-ended by a web server such as httpd, and the web server handles
> > these logs.
> >
> > Should we follow suit and by default keep the access logs turned off?
> > This seems to make more sense.
> >
> > Thoughts and opinions on this matter?
> >
> > Jeff
> >
>

Re: New Feature Idea