date:20060613

I would prefer we have full control over the infrastructure relating to 
the hosting of ASF licensed plugins that are developed under ASF 
projects. The recent outages and changes at other hosting sites have 
only highlighted this need.


It would also be preferable that ASF hosted plugins are available via 
mirrors.  Does this sound feasible?


John

Guillaume Nodet wrote:
Why not having something like the maven guys did for m2 plugins at 
mojo.codehaus.org ?


I tend to prefer a single location for all plugins rather than having 
one two repos, one at Apache
for ASL plugins, and another one.We could then just redirect the 
geronimoplugins.org to
the site at codehaus.  I think it would give the needed transparency, 
as I guess all the problems

come from here.

Cheers,
Guillaume Nodet

Aaron Mulder wrote:


Please distinguish between plugin source code, plugin binaries, and
plugin documentation.  Which of these do you think should be hosted at
Apache, not hosted at Apache, or split across providers?

Thanks,
   Aaron

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

See my other post.  I hit send too quickly.   I DO think we should 
host plugins at the ASF.




Aaron Mulder wrote:
> I gather from what you're saying you don't think the Geronimo project
> should host any plugins?  How do others feel?
>
> Thanks,
>Aaron
>
> On 6/12/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>> As you say since plugins are not owned by the Geronimo project 
(ASF),

>> not released by the Geronimo
>> project and are not under the oversight of the porject perhaps the
>> best thing to do is to put in an
>> HTML link pointing to www.GeronimoPlugins.com and that way that
>> project can manage the releases,
>> interdependncies, etc.  I think its a nice clean break.
>>
>> When Geronimo hosts its own plugins then it would make sense for 
us to

>> document them here.
>>
>> I don't think we should host documentation as part of the Geronimo
>> Project that is not under ASF
>> license.
>>
>> The plugin framework is part of Geronimo...the content is not and is
>> hosted externally.  I think
>> this is the division.
>>
>> Matt
>>
>> Aaron Mulder wrote:
>> > On 6/12/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
>> >> As far as I can see, plugins are part of Geronimo and they 
should be

>> >> in the 1.1 documentation space.
>> >
>> > I diasgree.  Plugins will be versioned separately from 
Geronimo, and
>> > will not all be developed by the Geronimo team.  What will we 
do with
>> > the Geronimo 1.1 documentation if Plugin Foo is at version 1.0 
when
>> > Geronimo 1.1 ships, but Plugin Foo goes through version 1.1, 
1.2, and

>> > 1.3 before Geronimo 1.2 ships?  Will we constantly be updating the
>> > Geronimo 1.1 documentation?  I don't think that makes sense.
>> >
>> > I think there should be a Plugins space with the Plugin Foo
>> > documentation.  In the Geronimo 1.1 documentation we can include a
>> > list of known available plugins with references to their 
individual
>> > documentation pages, or we can actually repeat some common 
usage of

>> > popular plugins, but I don't think we should try to capture the
>> > current state of all plugins (and either have it get terribly 
outdated

>> > or need frequent changes to the "finished" parts of the 1.1
>> > documentation).
>> >
>> >> The plan is, as I proposed several times in earlier emails, to 
move

>> >> all the content from MoinMoin to
>> >> Confluence. Most of the content in the MoinMoin is outdated or
>> >> duplicated, the docs that are still
>> >> valid should be moved to a section within the new structure in
>> >> confluence. Those topics that don't
>> >> fit either the User's or Developer's guide should go into the 
Geronimo

>> >> SandBox space which is
>> >> version independent. This space should hold historical data 
like the

>> >> logo contest for example.
>> >
>> > OK.  Who's going to do that migration?  Also, I have to say, I 
don't

>> > think that putting documentation in a different Wiki is going to
>> > automatically keep it up to date.  It's a nice opportunity to 
clean
>> > up, but I imagine we'll need a regular cleaning process if we 
don't

>> > want our Wiki to get out of date.
>> >
>> > Thanks,
>> >Aaron
>> >
>> >> Aaron Mulder wrote:
>> >> > I'd like to add some documentation for specific plugins to a
>> Wiki.  I
>> >> > don't know if the plan is to migrate pretty much everything to
>> >> > Confluence or only keep our main documentation there and use
>> MoinMoin
>> >> > for the rest or what.
>> >> >
>> >> > Still, if we're documenting available plugins, that's probably
>> more or
>> >> > less project documentation, and should go in Confluence anyway.
>> Could
>> >> > someone with admin access create an Apache Geronimo Plugins 
space?
>> >> > (The plugins will be on a separate release track from 
Geronimo so I
>> >> > don't think the plugin docs should necessarily go in the 1.1 
docs.)

>> >> >
>> >> > Thanks,
>> >> >Aaron
>> >> >
>> >>
>>

Re: What's the Wiki story?

IMO, we should only host plugins that are ASF licensed and maintained as 
part of the Geronimo project.  For other plugins we can provide links to 
other sites (with a disclaimer that we don't endorse them etc).


John

Aaron Mulder wrote:

I gather from what you're saying you don't think the Geronimo project
should host any plugins?  How do others feel?

Thanks,
   Aaron

On 6/12/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
As you say since plugins are not owned by the Geronimo project (ASF), 
not released by the Geronimo
project and are not under the oversight of the porject perhaps the 
best thing to do is to put in an
HTML link pointing to www.GeronimoPlugins.com and that way that 
project can manage the releases,

interdependncies, etc.  I think its a nice clean break.

When Geronimo hosts its own plugins then it would make sense for us 
to document them here.


I don't think we should host documentation as part of the Geronimo 
Project that is not under ASF

license.

The plugin framework is part of Geronimo...the content is not and is 
hosted externally.  I think

this is the division.

Matt

Aaron Mulder wrote:
> On 6/12/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
>> As far as I can see, plugins are part of Geronimo and they should be
>> in the 1.1 documentation space.
>
> I diasgree.  Plugins will be versioned separately from Geronimo, and
> will not all be developed by the Geronimo team.  What will we do with
> the Geronimo 1.1 documentation if Plugin Foo is at version 1.0 when
> Geronimo 1.1 ships, but Plugin Foo goes through version 1.1, 1.2, and
> 1.3 before Geronimo 1.2 ships?  Will we constantly be updating the
> Geronimo 1.1 documentation?  I don't think that makes sense.
>
> I think there should be a Plugins space with the Plugin Foo
> documentation.  In the Geronimo 1.1 documentation we can include a
> list of known available plugins with references to their individual
> documentation pages, or we can actually repeat some common usage of
> popular plugins, but I don't think we should try to capture the
> current state of all plugins (and either have it get terribly outdated
> or need frequent changes to the "finished" parts of the 1.1
> documentation).
>
>> The plan is, as I proposed several times in earlier emails, to move
>> all the content from MoinMoin to
>> Confluence. Most of the content in the MoinMoin is outdated or
>> duplicated, the docs that are still
>> valid should be moved to a section within the new structure in
>> confluence. Those topics that don't
>> fit either the User's or Developer's guide should go into the 
Geronimo

>> SandBox space which is
>> version independent. This space should hold historical data like the
>> logo contest for example.
>
> OK.  Who's going to do that migration?  Also, I have to say, I don't
> think that putting documentation in a different Wiki is going to
> automatically keep it up to date.  It's a nice opportunity to clean
> up, but I imagine we'll need a regular cleaning process if we don't
> want our Wiki to get out of date.
>
> Thanks,
>Aaron
>
>> Aaron Mulder wrote:
>> > I'd like to add some documentation for specific plugins to a 
Wiki.  I

>> > don't know if the plan is to migrate pretty much everything to
>> > Confluence or only keep our main documentation there and use 
MoinMoin

>> > for the rest or what.
>> >
>> > Still, if we're documenting available plugins, that's probably 
more or
>> > less project documentation, and should go in Confluence anyway.  
Could

>> > someone with admin access create an Apache Geronimo Plugins space?
>> > (The plugins will be on a separate release track from Geronimo so I
>> > don't think the plugin docs should necessarily go in the 1.1 docs.)
>> >
>> > Thanks,
>> >Aaron
>> >
>>
>
>
>

[jira] Created: (GERONIMO-2117) Remove deployer-log4j.properties files - they are no longer used

Remove deployer-log4j.properties files - they are no longer used


 Key: GERONIMO-2117
 URL: http://issues.apache.org/jira/browse/GERONIMO-2117
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: deployment  
Versions: 1.1
Reporter: John Sisson
 Assigned to: John Sisson 
Priority: Trivial
 Fix For: 1.1.1


I can't see anything that is referencing the deployer-log4j.properties files, 
so they probably 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

Re: Atlanta JUG

2006-06-13 Thread Jeff Genender



John Sisson wrote:
> Jeff,
> 
> if you end up going and the JUG is open to all, then could you update
> the events page with the details.

Sure...lets see if I am going for sure first ;-)

> 
> Thanks,
> John
> 
> Jeff Genender wrote:
>> I probably can help out.
>>
>> Jeff
>>
>> Carmen Hagen wrote:
>>  
>>> Heard that the Atlanta JUG is interested in having a Geronimo committer
>>> speak at their October 17th meeting.  Anyone interested?  Please let me
>>> know as soon as possible, and I'll get you connected.  Thanks!
>>>
>>> *
>>> Carmen Hagen
>>> IBM Software Group
>>> Support for Apache Geronimo
>>> [EMAIL PROTECTED]
>>>
>>>
>>>
>>>
>>>
>>> 
>>
>>

[jira] Assigned: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file

2006-06-13 Thread Kevan Miller (JIRA)

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

Kevan Miller reassigned GERONIMO-2112:
--

Assign To: Kevan Miller

> Place required attrtibutions in the NOTICES.txt file or a license included in 
> the LICENSE.txt file
> --
>
>  Key: GERONIMO-2112
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2112
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.1
> Reporter: John Sisson
> Assignee: Kevan Miller
> Priority: Blocker
>  Fix For: 1.1
>  Attachments: LICENSE.txt, NOTICE.txt, NOTICE.txt, NOTICES-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft2.txt
>
> I have collated a list of components in the attached file indicating whether 
> IMHO they require an attribution in the NOTICES.txt file or a license 
> included in the LICENSE.txt file.  
> See http://www.apache.org/dev/apply-license.html#new for information on 
> license files.
> See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example 
> of a LICENSE file containing other licenses.

-- 
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-2115) Exclude j2ee-installer assembly from 1.1 build by renaming project.xml file to project.xml.ignore

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

Resolution: Fixed

> Exclude j2ee-installer assembly from 1.1 build by renaming project.xml file 
> to project.xml.ignore
> -
>
>  Key: GERONIMO-2115
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2115
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
> Versions: 1.1
> Reporter: John Sisson
> Assignee: John Sisson
> Priority: Minor
>  Fix For: 1.1

>
> The j2ee-installer assembly is not functional on Geronimo 1.1, therefore the 
> project.xml file for the assembly will be renamed to project.xml.ignore so 
> that users building from source don't build the j2ee-installer assembly.

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

[jira] Assigned: (GERONIMO-2116) Precompile JSPs in apps. Jar classes into web-inf/lib

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

Prasad Kashyap reassigned GERONIMO-2116:


Assign To: David Jencks

> Precompile JSPs in apps. Jar classes into web-inf/lib
> -
>
>  Key: GERONIMO-2116
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2116
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: web
> Versions: 1.2
> Reporter: Prasad Kashyap
> Assignee: David Jencks
>  Fix For: 1.2
>  Attachments: jspc.patch
>
> Patch precompiles jsps.
> Patch also jars classes into web-inf/lib/${project.build.finalName}.jar.
> Note: The 2.0.1 snapshot of the maven-war-plugin has not been deployed yet. 
> To test the jar functionality, you will have to build your own war plugin.

-- 
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-2116) Precompile JSPs in apps. Jar classes into web-inf/lib

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

Prasad Kashyap updated GERONIMO-2116:
-

Attachment: jspc.patch

> Precompile JSPs in apps. Jar classes into web-inf/lib
> -
>
>  Key: GERONIMO-2116
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2116
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: web
> Versions: 1.2
> Reporter: Prasad Kashyap
>  Fix For: 1.2
>  Attachments: jspc.patch
>
> Patch precompiles jsps.
> Patch also jars classes into web-inf/lib/${project.build.finalName}.jar.
> Note: The 2.0.1 snapshot of the maven-war-plugin has not been deployed yet. 
> To test the jar functionality, you will have to build your own war plugin.

-- 
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-2116) Precompile JSPs in apps. Jar classes into web-inf/lib

Precompile JSPs in apps. Jar classes into web-inf/lib
-

 Key: GERONIMO-2116
 URL: http://issues.apache.org/jira/browse/GERONIMO-2116
 Project: Geronimo
Type: Sub-task
Security: public (Regular issues) 
  Components: web  
Versions: 1.2
Reporter: Prasad Kashyap
 Fix For: 1.2
 Attachments: jspc.patch

Patch precompiles jsps.

Patch also jars classes into web-inf/lib/${project.build.finalName}.jar.
Note: The 2.0.1 snapshot of the maven-war-plugin has not been deployed yet. To 
test the jar functionality, you will have to build your own war plugin.

-- 
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: Eclipse Plugin V1.1.0 unstable driver now available

Hi Sachin, I just wanted to report that your latest build works very 
well for me. Thanks very much!


Cheers.

-Neal

[jira] Created: (GERONIMO-2115) Exclude j2ee-installer assembly from 1.1 build by renaming project.xml file to project.xml.ignore

Exclude j2ee-installer assembly from 1.1 build by renaming project.xml file to 
project.xml.ignore
-

 Key: GERONIMO-2115
 URL: http://issues.apache.org/jira/browse/GERONIMO-2115
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
Versions: 1.1
Reporter: John Sisson
 Assigned to: John Sisson 
Priority: Minor
 Fix For: 1.1


The j2ee-installer assembly is not functional on Geronimo 1.1, therefore the 
project.xml file for the assembly will be renamed to project.xml.ignore so that 
users building from source don't build the j2ee-installer assembly.

-- 
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: Eclipse Plugin V1.1.0 unstable driver now available

Okay, good, because my build is failing. I'll download yours and test it
out here. My error during build was:

[ERROR] BUILD FAILURE
[INFO]

[INFO] Compilation failure

E:\geronimo-eclipse-tools\plugins\org.apache.geronimo.st.v11.core\src\org\apache
\geronimo\st\v11\core\GeronimoV11Utils.java:[54,65] incompatible types
found : java.lang.Object
required: org.apache.geronimo.xml.ns.deployment.EnvironmentType

I'll try again later.

-Neal

Sachin Patel wrote:

Ok, actually I'm using now...

MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m"

and I'm uploading a build as we speak, should be done in just about 5
min.

On Jun 13, 2006, at 10:13 PM, Neal Sanche wrote:

I noticed that in the build scripts... Good that you fixed it. I will
keep trying to build it. I ran into the out of memory problem just
now and found your previous post on MAVEN_OPTS=-Xmx512m so I'll stop
the build and svn update first. Thanks.

-Neal

Sachin Patel wrote:
Cool, you'll want to do an svn update, i just checked in some stuff,
happened to be that v11.ui wasn't even building, nor being packaged :)

On Jun 13, 2006, at 9:39 PM, Neal Sanche wrote:

Well, in the meantime I'm learning how to compile it. Downloaded
Maven 2.0.4 and am just waiting for the rest of the downloads to
happen. Exciting stuff. :)

-Neal

Sachin Patel wrote:
My bad, you're right. Fixing and rebuilding now. Check for a new
driver shortly. Thanks for your patience.

-sachin

On Jun 13, 2006, at 9:09 PM, Neal Sanche wrote:

Just tried it, and it's the same thing Sachin. Could you,
perhaps, send me the following file, or make it available in the
.zip:

org.apache.geronimo.st.v11.ui.jar

It isn't in the .zip you sent, however it is in the source
distribution, but I can't make the plugin source code compile.
Are you using Maven, or m2?

-Neal

Neal Sanche wrote:
Thanks Sachin, I will give it a good run tonight, and let you
know through JIRAs if I encounter anything.

Cheers.

-Neal

Sachin Patel wrote:
Ah found the problem, the bundle manifest was missing a "."
entry for bundle-classpath. I'm uploading a new driver right now.

On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:

Sachin Patel wrote:
The following driver can run on both JDK 1.4 or
1.5. It should be run with WTP 1.0x and will
eventually but not currently run on WTP 1.5.

http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip

-sachin

[jira] Commented: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file

2006-06-13 Thread Dave Colasurdo (JIRA)

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

Dave Colasurdo commented on GERONIMO-2112:
--

That was the format I used in the original LICENSE.TXT and NOTICE.txt that I 
attached (separating licenses from attributions).  I suspect tweaking those 
files with updated info may be the way to go..

-Dave-  

> Place required attrtibutions in the NOTICES.txt file or a license included in 
> the LICENSE.txt file
> --
>
>  Key: GERONIMO-2112
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2112
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.1
> Reporter: John Sisson
> Priority: Blocker
>  Fix For: 1.1
>  Attachments: LICENSE.txt, NOTICE.txt, NOTICE.txt, NOTICES-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft2.txt
>
> I have collated a list of components in the attached file indicating whether 
> IMHO they require an attribution in the NOTICES.txt file or a license 
> included in the LICENSE.txt file.  
> See http://www.apache.org/dev/apply-license.html#new for information on 
> license files.
> See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example 
> of a LICENSE file containing other licenses.

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

[jira] Commented: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file

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

John Sisson commented on GERONIMO-2112:
---

We're getting closer.  

All licenses should be moved to the LICENSE.txt file.  The NOTICE.txt file 
should only contain notices or attributions.

Should probably be specific and identify the version of the CPL license (1.0).


> Place required attrtibutions in the NOTICES.txt file or a license included in 
> the LICENSE.txt file
> --
>
>  Key: GERONIMO-2112
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2112
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.1
> Reporter: John Sisson
> Priority: Blocker
>  Fix For: 1.1
>  Attachments: LICENSE.txt, NOTICE.txt, NOTICE.txt, NOTICES-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft2.txt
>
> I have collated a list of components in the attached file indicating whether 
> IMHO they require an attribution in the NOTICES.txt file or a license 
> included in the LICENSE.txt file.  
> See http://www.apache.org/dev/apply-license.html#new for information on 
> license files.
> See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example 
> of a LICENSE file containing other licenses.

-- 
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: Eclipse Plugin V1.1.0 unstable driver now available


Ok, actually I'm using now...

MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m"

and I'm uploading a build as we speak, should be done in just about 5  
min.


On Jun 13, 2006, at 10:13 PM, Neal Sanche wrote:

I noticed that in the build scripts... Good that you fixed it. I  
will keep trying to build it. I ran into the out of memory problem  
just now and found your previous post on MAVEN_OPTS=-Xmx512m so  
I'll stop the build and svn update first. Thanks.


-Neal

Sachin Patel wrote:
Cool, you'll want to do an svn update, i just checked in some  
stuff, happened to be that v11.ui wasn't even building, nor being  
packaged :)


On Jun 13, 2006, at 9:39 PM, Neal Sanche wrote:

Well, in the meantime I'm learning how to compile it. Downloaded  
Maven 2.0.4 and am just waiting for the rest of the downloads to  
happen. Exciting stuff. :)


-Neal

Sachin Patel wrote:
My bad, you're right.  Fixing and rebuilding now.  Check for a  
new driver shortly.  Thanks for your patience.


-sachin

On Jun 13, 2006, at 9:09 PM, Neal Sanche wrote:

Just tried it, and it's the same thing Sachin. Could you,  
perhaps, send me the following file, or make it available in  
the .zip:


org.apache.geronimo.st.v11.ui.jar

It isn't in the .zip you sent, however it is in the source  
distribution, but I can't make the plugin source code compile.  
Are you using Maven, or m2?


-Neal

Neal Sanche wrote:
Thanks Sachin, I will give it a good run tonight, and let you  
know through JIRAs if I encounter anything.


Cheers.

-Neal

Sachin Patel wrote:
Ah found the problem, the bundle manifest was missing a "."  
entry for bundle-classpath.  I'm uploading a new driver right  
now.


On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or  
1.5. It should be run with WTP 1.0x and will  
eventually but not currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/ 
unstable/g-eclipse-plugin-1.1-SNAPSHOT- 
deployable.zip







-sachin






-sachin






-sachin

Re: Eclipse Plugin V1.1.0 unstable driver now available

I noticed that in the build scripts... Good that you fixed it. I will
keep trying to build it. I ran into the out of memory problem just now
and found your previous post on MAVEN_OPTS=-Xmx512m so I'll stop the
build and svn update first. Thanks.

-Neal

Sachin Patel wrote:
Cool, you'll want to do an svn update, i just checked in some stuff,
happened to be that v11.ui wasn't even building, nor being packaged :)

On Jun 13, 2006, at 9:39 PM, Neal Sanche wrote:

Well, in the meantime I'm learning how to compile it. Downloaded
Maven 2.0.4 and am just waiting for the rest of the downloads to
happen. Exciting stuff. :)

-Neal

Sachin Patel wrote:
My bad, you're right. Fixing and rebuilding now. Check for a new
driver shortly. Thanks for your patience.

-sachin

On Jun 13, 2006, at 9:09 PM, Neal Sanche wrote:

Just tried it, and it's the same thing Sachin. Could you, perhaps,
send me the following file, or make it available in the .zip:

org.apache.geronimo.st.v11.ui.jar

It isn't in the .zip you sent, however it is in the source
distribution, but I can't make the plugin source code compile. Are
you using Maven, or m2?

-Neal

Neal Sanche wrote:
Thanks Sachin, I will give it a good run tonight, and let you know
through JIRAs if I encounter anything.

Cheers.

-Neal

Sachin Patel wrote:
Ah found the problem, the bundle manifest was missing a "." entry
for bundle-classpath. I'm uploading a new driver right now.

On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:

Sachin Patel wrote:
The following driver can run on both JDK 1.4 or
1.5. It should be run with WTP 1.0x and will
eventually but not currently run on WTP 1.5.

http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip

-sachin

Re: Eclipse Plugin V1.1.0 unstable driver now available

Cool, you'll want to do an svn update, i just checked in some stuff,  
happened to be that v11.ui wasn't even building, nor being packaged :)


On Jun 13, 2006, at 9:39 PM, Neal Sanche wrote:

Well, in the meantime I'm learning how to compile it. Downloaded  
Maven 2.0.4 and am just waiting for the rest of the downloads to  
happen. Exciting stuff. :)


-Neal

Sachin Patel wrote:
My bad, you're right.  Fixing and rebuilding now.  Check for a new  
driver shortly.  Thanks for your patience.


-sachin

On Jun 13, 2006, at 9:09 PM, Neal Sanche wrote:

Just tried it, and it's the same thing Sachin. Could you,  
perhaps, send me the following file, or make it available in  
the .zip:


org.apache.geronimo.st.v11.ui.jar

It isn't in the .zip you sent, however it is in the source  
distribution, but I can't make the plugin source code compile.  
Are you using Maven, or m2?


-Neal

Neal Sanche wrote:
Thanks Sachin, I will give it a good run tonight, and let you  
know through JIRAs if I encounter anything.


Cheers.

-Neal

Sachin Patel wrote:
Ah found the problem, the bundle manifest was missing a "."  
entry for bundle-classpath.  I'm uploading a new driver right now.


On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or  
1.5. It should be run with WTP 1.0x and will  
eventually but not currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/ 
unstable/g-eclipse-plugin-1.1-SNAPSHOT- 
deployable.zip







-sachin






-sachin

[jira] Updated: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file

2006-06-13 Thread Kevan Miller (JIRA)

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

Kevan Miller updated GERONIMO-2112:
---

Attachment: NOTICE.txt

NOTICE.txt file. 

John,
I believe this addresses all of the notice/license requirements which you've 
identified -- great work by the way! Thanks for doing all of that...

> Place required attrtibutions in the NOTICES.txt file or a license included in 
> the LICENSE.txt file
> --
>
>  Key: GERONIMO-2112
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2112
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.1
> Reporter: John Sisson
> Priority: Blocker
>  Fix For: 1.1
>  Attachments: LICENSE.txt, NOTICE.txt, NOTICE.txt, NOTICES-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft2.txt
>
> I have collated a list of components in the attached file indicating whether 
> IMHO they require an attribution in the NOTICES.txt file or a license 
> included in the LICENSE.txt file.  
> See http://www.apache.org/dev/apply-license.html#new for information on 
> license files.
> See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example 
> of a LICENSE file containing other licenses.

-- 
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: Eclipse Plugin V1.1.0 unstable driver now available

Well, in the meantime I'm learning how to compile it. Downloaded Maven 
2.0.4 and am just waiting for the rest of the downloads to happen. 
Exciting stuff. :)


-Neal

Sachin Patel wrote:
My bad, you're right.  Fixing and rebuilding now.  Check for a new 
driver shortly.  Thanks for your patience.


-sachin

On Jun 13, 2006, at 9:09 PM, Neal Sanche wrote:

Just tried it, and it's the same thing Sachin. Could you, perhaps, 
send me the following file, or make it available in the .zip:


org.apache.geronimo.st.v11.ui.jar

It isn't in the .zip you sent, however it is in the source 
distribution, but I can't make the plugin source code compile. Are 
you using Maven, or m2?


-Neal

Neal Sanche wrote:
Thanks Sachin, I will give it a good run tonight, and let you know 
through JIRAs if I encounter anything.


Cheers.

-Neal

Sachin Patel wrote:
Ah found the problem, the bundle manifest was missing a "." entry 
for bundle-classpath.  I'm uploading a new driver right now.


On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or 1.5. 
It should be run with WTP 1.0x and will eventually 
but not currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip 








-sachin

Re: Eclipse Plugin V1.1.0 unstable driver now available

My bad, you're right.  Fixing and rebuilding now.  Check for a new  
driver shortly.  Thanks for your patience.


-sachin

On Jun 13, 2006, at 9:09 PM, Neal Sanche wrote:

Just tried it, and it's the same thing Sachin. Could you, perhaps,  
send me the following file, or make it available in the .zip:


org.apache.geronimo.st.v11.ui.jar

It isn't in the .zip you sent, however it is in the source  
distribution, but I can't make the plugin source code compile. Are  
you using Maven, or m2?


-Neal

Neal Sanche wrote:
Thanks Sachin, I will give it a good run tonight, and let you know  
through JIRAs if I encounter anything.


Cheers.

-Neal

Sachin Patel wrote:
Ah found the problem, the bundle manifest was missing a "." entry  
for bundle-classpath.  I'm uploading a new driver right now.


On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or  
1.5. It should be run with WTP 1.0x and will  
eventually but not currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/ 
unstable/g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip







-sachin

Re: Atlanta JUG


Jeff,

if you end up going and the JUG is open to all, then could you update 
the events page with the details.


Thanks,
John

Jeff Genender wrote:

I probably can help out.

Jeff

Carmen Hagen wrote:
  

Heard that the Atlanta JUG is interested in having a Geronimo committer
speak at their October 17th meeting.  Anyone interested?  Please let me
know as soon as possible, and I'll get you connected.  Thanks!

*
Carmen Hagen
IBM Software Group
Support for Apache Geronimo
[EMAIL PROTECTED]

Re: Eclipse Plugin V1.1.0 unstable driver now available

Just tried it, and it's the same thing Sachin. Could you, perhaps, send 
me the following file, or make it available in the .zip:


org.apache.geronimo.st.v11.ui.jar

It isn't in the .zip you sent, however it is in the source distribution, 
but I can't make the plugin source code compile. Are you using Maven, or m2?


-Neal

Neal Sanche wrote:
Thanks Sachin, I will give it a good run tonight, and let you know 
through JIRAs if I encounter anything.


Cheers.

-Neal

Sachin Patel wrote:
Ah found the problem, the bundle manifest was missing a "." entry for 
bundle-classpath.  I'm uploading a new driver right now.


On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or 1.5. It 
should be run with WTP 1.0x and will eventually but not 
currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip

[jira] Updated: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file

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

John Sisson updated GERONIMO-2112:
--

Attachment: geronimo-1.1-RC-licenses-attributions-draft2.txt

Updated/Added the following items:

axis
commons-fileupload
commons-io
commons-modeler
dwr
jaxr-api
jstl
stax-api
wsdl4j



> Place required attrtibutions in the NOTICES.txt file or a license included in 
> the LICENSE.txt file
> --
>
>  Key: GERONIMO-2112
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2112
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.1
> Reporter: John Sisson
> Priority: Blocker
>  Fix For: 1.1
>  Attachments: LICENSE.txt, NOTICE.txt, NOTICES-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft2.txt
>
> I have collated a list of components in the attached file indicating whether 
> IMHO they require an attribution in the NOTICES.txt file or a license 
> included in the LICENSE.txt file.  
> See http://www.apache.org/dev/apply-license.html#new for information on 
> license files.
> See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example 
> of a LICENSE file containing other licenses.

-- 
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: Eclipse Plugin V1.1.0 unstable driver now available

Thanks Sachin, I will give it a good run tonight, and let you know 
through JIRAs if I encounter anything.


Cheers.

-Neal

Sachin Patel wrote:
Ah found the problem, the bundle manifest was missing a "." entry for 
bundle-classpath.  I'm uploading a new driver right now.


On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or 1.5. It 
should be run with WTP 1.0x and will eventually but not 
currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip

Re: Atlanta JUG

2006-06-13 Thread Jeff Genender

I probably can help out.

Jeff

Carmen Hagen wrote:
> 
> Heard that the Atlanta JUG is interested in having a Geronimo committer
> speak at their October 17th meeting.  Anyone interested?  Please let me
> know as soon as possible, and I'll get you connected.  Thanks!
> 
> *
> Carmen Hagen
> IBM Software Group
> Support for Apache Geronimo
> [EMAIL PROTECTED]
> 
> 
> 
> 
>

Atlanta JUG

2006-06-13 Thread Carmen Hagen


Heard that the Atlanta JUG is interested
in having a Geronimo committer speak at their October 17th meeting.  Anyone
interested?  Please let me know as soon as possible, and I'll get
you connected.  Thanks!

*
Carmen Hagen
IBM Software Group
     Support for Apache Geronimo
[EMAIL PROTECTED]

Should the we modify the the new5 goal in 1.1 to exclude the zzzzj2ee-installer assembly ?

It may be misleading to have it built if it doesn't work.  Users will 
try to build from source and will ask us why the installer doesn't work...


I also noticed that the standard.jar that seems to be only under the 
j2ee-installer assembly is different to the standard-1.1.1.jar file 
available from  
http://archive.apache.org/dist/jakarta/taglibs/standard/binaries/ . 
Don't have time to investigate now.


John

Re: rc1 Status and Next Steps

I did a binary comparison of the stax-api-1.0.1 jar in Geronimo and it 
matches the JAR at http://dist.codehaus.org/stax/jars/stax-api-1.0.1.jar 
as Guillaume said.


FYI, the URL for the project is http://stax.codehaus.org/ and the page 
says "Open Source (Apache ASL 2.1)".


Does anyone know where the tag is for the stax-api 1.0.1 code? I tried 
svn list svn://svn.stax.codehaus.org/stax/tags/ but nothing was listed.  
There also isn't a downloadable source distribution for that version. 


Thanks,
John

Guillaume Nodet wrote:

This jar: http://dist.codehaus.org/stax/jars/stax-api-1.0.1.jar
does not contain anything and is licensed under ASL 2.

I guess you are refering to the stax RI from BEA, but this one
is not licensed under ASL and is not reditributable.

Cheers,
Guillaume Nodet

On 6/13/06, *Donald Woods* < [EMAIL PROTECTED] 
> wrote:


If you look at the NOTICES-Draft1.txt file I attached before Dave's,
you'll see the Stax source contains the following License/Notices
which
need to be mentioned -


(i) Indiana University Extreme!  LabSoftware License V1.1

  Indiana University Extreme! Lab Software License, Version 1.1.1

   Copyright (c) 2002 Extreme! Lab, Indiana University. All rights
reserved.

   Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

   1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.

   2. Redistributions in binary form must reproduce the above
copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

   3. The end-user documentation included with the redistribution, if
any, must include the following acknowledgment:  "This product
includes
software developed by the Indiana University Extreme! Lab
(http://www.extreme.indiana.edu/)
."  Alternately, this
acknowledgment
may appear in the software itself, if and wherever such
third-party
acknowledgments normally appear.

   4. The names "Indiana University" and "Indiana University Extreme!
Lab" must not be used to endorse or promote products derived from this
software without prior written permission. For written permission,
please contact http://www.extreme.indiana.edu/.

   5. Products derived from this software may not use "Indiana
University" name nor may "Indiana University" appear in their name,
without prior written permission of the Indiana University.


   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.  IN
NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS
INTERRUPTION) HOWEVER CAUSED AND  ON ANY THEORY OF LIABILITY,
WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.


  

(ii)The Apache Software License, Version 1.1


   Copyright (c) 2000 The Apache Software Foundation.  All rights
reserved.

  Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

   1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.

   2. Redistributions in binary form must reproduce the above
copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

   3. The end-user documentation included with the redistribution, if
any, must include the following acknowledgment:  "This product
includes
software developed by the Apache Software Foundation
( http://www.apache.org/)
."  Alternately, this acknowledgment
may appear
in the software itself, if and wherever such third-party
acknowledgments
normally appear.

   4. The names "Crimson" and "Apache Software Foundation" must
not be
used to endorse or promote products derived from this software without
prior written permission. For written permission, please contact
[EMAIL PROTECTED] .

   5. P

Re: rc1 Status and Next Steps

I thought I'd confirm what guillaume is saying and go into more detail.The codehaus stax project is at http://stax.codehaus.org.  I think from some svn comments and the participation of Alexander Slominsky that it was moved from indiana university at some point.It's hard to find the license in the source of the stax project at codehaus, however this:http://svn.stax.codehaus.org/browse/~raw,r=73/stax/trunk/dev/README-API.txtclearly indicates the 1.0 stax-api jar is asl 2.0 licensed.  I can find no information on what is in the 1.0.1 release, but presumably it is still under the same license.  The source files indicate bea as the copyright holder but contain no licensing information.Looking in the implementation classes (which we don't use or include in geronimo), the few I looked at all have asl 2.0 licensing headers.  Furthermore they don't have the bea copyright even though they are in the com.bea.xml.stream package.On another related note, the xmlbeans oct-dev board report indicates that they have negotiated with bea with the result that bea has relicensed the stax-api source under asl2.0.  From a post dec 19:Here's what I'm about to submit for our quarterly status report.  Anyadditions/corrections are welcome up until Wednesday, 10 am PST.XMLBeans Status report for October-December 20051. Resolved JSR-173 RI licensing issue.  BEA licensed the necessaryparts under the Apache License; so, there is no longer any licensingissue thereThis code appears to be the base of what's at codehaus as well.I wish these guys would all take better care of their licensing issues, but I think we're safe on this one.thanksdavid jencksOn Jun 13, 2006, at 1:17 PM, Guillaume Nodet wrote:This jar: http://dist.codehaus.org/stax/jars/stax-api-1.0.1.jardoes not contain anything and is licensed under ASL 2.I guess you are refering to the stax RI from BEA, but this one is not licensed under ASL and is not reditributable.Cheers,Guillaume NodetOn 6/13/06, Donald Woods < [EMAIL PROTECTED]> wrote:If you look at the NOTICES-Draft1.txt file I attached before Dave's, you'll see the Stax source contains the following License/Notices whichneed to be mentioned -(i) Indiana University Extreme!  LabSoftware License V1.1  Indiana University Extreme! Lab Software License, Version 1.1.1   Copyright (c) 2002 Extreme! Lab, Indiana University. All rights reserved.   Redistribution and use in source and binary forms, with or withoutmodification, are permitted provided that the following conditions are met:    1. Redistributions of source code must retain the above copyrightnotice, this list of conditions and the following disclaimer.   2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in thedocumentation and/or other materials provided with the distribution.   3. The end-user documentation included with the redistribution, ifany, must include the following acknowledgment:  "This product includes software developed by the Indiana University Extreme! Lab(http://www.extreme.indiana.edu/)."  Alternately, this acknowledgmentmay appear in the software itself, if and wherever such third-party acknowledgments normally appear.   4. The names "Indiana University" and "Indiana University Extreme!Lab" must not be used to endorse or promote products derived from thissoftware without prior written permission. For written permission, please contact http://www.extreme.indiana.edu/.   5. Products derived from this software may not use "IndianaUniversity" name nor may "Indiana University" appear in their name, without prior written permission of the Indiana University.   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIEDWARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BELIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, ORCONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OFSUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND  ON ANY THEORY OF LIABILITY, WHETHER INCONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.  (ii)The Apache Software License, Version 1.1   Copyright (c) 2000 The Apache Software Foundation.  All rights reserved.   Redistribution and use in source and binary forms, with or withoutmodification, are permitted provided that the following conditions are met:   1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.   2. Redistributions in binary form must reproduce the above copyrightnotice, this list of conditions and the following disclaimer in thedo

Re: STOMP and JMSType

On 6/13/06, Nathan Mittler <[EMAIL PROTECTED]> wrote:

Could you guys point me to a place in AMQ where this sort of thing is being
done?  That would save me a lot of searching =)

Its not really done anywhere else :-(

I'm viewing this problem from the client side - the Stomp C++ client that
Tim Bish and I are writing currently supports text and bytes messages.  So
when I get a stomp frame in, I need to map it back to a text or bytes
message.  We chose to do this for a couple of reasons: 1) to give JMS users
a familiar interface and 2) to provide a simple interface for reading and
writing text messages (e.g. xml).

Sure.  that would be handy.  But you could also eventualy support Map
messages too right?

With that said, I'm not seeing how I can do that mapping if the transformer
is provided only in the SUBSCRIBE.  A client could potentially get a variety
of message types from a single subscription.  I think it would have to be
part of the MESSAGE frame, rather than the SUBSCRIBE.

Well, when the publisher is a pure jms client, he wont be providing a
header for the transform type right?  What I was thinking is that when
the client says SUBSCRIBE with x transform, it basically sets up a
contract that given all the JMS message types a well defined
transformation to STOMP frames will be done.  It could be that a
future transform will take a Map messages and turn it into XML and put
that in a text stomp frame.  But a different transformation might take
a Map message and do a binary encoding of the key value pairs.  Either
way the client will know what to expect because he requested it on the
SUBSCRIBE.

In addition, a smarter transformer could enhance the subscription's
selector so that it does not receive message types that it cannot
handle.  That way if the client says it can only receive text
messages, it only subscribes to text messages.

Here are the use cases I see:

Client->Server
1) SEND\n...\ntransformer:text (client tells server it's a text message)
2) SEND\n...\ntransformer:bytes (client tells server it's a bytes message)
3) SEND\n...\ntransformer:default (client tells server to use content-length
to make determination)
4) SEND\n...\n (no transformer specified - same as #3)
5) SEND\n..\ntransformer:bob (client gives server unknown transformer - use
default)

and I also see stuff similar to:
6) SEND\n...\ntransformer:xml-to-map (client tells server it's a xml
stomp frame that need to get converted to a jms MAP message)

Server->Client
1) MESSAGE\n...\ntransformer:text (server tells client it's a text message)
2) MESSAGE\n...\ntransformer:bytes (server tells client it's a bytes
message)
3) MESSAGE\n...\ntransformer:default (server tells client to use
content-length to make determination)
4) MESSAGE\n...\n (no transformer specified - same as #3)
5) MESSAGE\n...\ntransformer:bob (server tells client to use unknown
transformer - use default)

Sure, but that's just content type information.  I do agree we need to
set this to something.  But it's separate from doing transforms to map
from all the JMS message types to the 2 basic stomp types text and
bytes.

Does this make sense, or am I missing something?

I think we are starting to converge now.  I guess the biggest issues
with content type like fields is that there are so many of them.  I
personally would map content-type -> JMSType since I think they were
meant to hold app specific descriptions of the payload.  We may want
to have the additional header you were proposing to hold information
about the STOMP frame - > JMS Message type kind of information.  It
gets fuzzy here.

Thanks,
Nate

On 6/13/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>
> > I would suggest that we use a weak form of specification encoding.
> > ActiveMQ already uses pseudo-urls in a lot of places, and named
> > transforms trump class names, usually:
> >
>
> yeah! URI style configuration rocks!
>
>
> > -Brian
> >
> >
> >
> >
> >
>
>
> --
> Regards,
> Hiram
>

--
Regards,
Hiram

Re: STOMP and JMSType

2006-06-13 Thread Brian McCallister


On Jun 13, 2006, at 1:50 PM, Nathan Mittler wrote:

Could you guys point me to a place in AMQ where this sort of thing  
is being

done?  That would save me a lot of searching =)

I'm viewing this problem from the client side - the Stomp C++  
client that

Tim Bish and I are writing currently supports text and bytes messages.


Within a general Stomp client, I would suggest that switching on JMS  
message types is not a productive goal. Using Content-type here makes  
a lot more sense, I think. . It would make a lot of sense to set it  
for text messages going out to Stomp if there is not one already  
supplied.


Stomp is a protocol, like HTTP or SMTP -- hardwiring a client to a  
specific server implementation is probably not a general solution  
(though is fine if it is specifically an activemq client which  
happens to use stomp for transport).


So when I get a stomp frame in, I need to map it back to a text or  
bytes
message.  We chose to do this for a couple of reasons: 1) to give  
JMS users
a familiar interface and 2) to provide a simple interface for  
reading and

writing text messages (e.g. xml).


Content-type: text/xml

--

Content-type: application/octet-stream

With that said, I'm not seeing how I can do that mapping if the  
transformer
is provided only in the SUBSCRIBE.  A client could potentially get  
a variety
of message types from a single subscription.  I think it would have  
to be

part of the MESSAGE frame, rather than the SUBSCRIBE.


SUBSCRIBE
activemq-transformer: com.example.ContentTypeMapper


Here are the use cases I see:


s/transformer/activemq-transformer/g

I like the namespace.


Client->Server
1) SEND\n...\ntransformer:text (client tells server it's a text  
message)


+1

2) SEND\n...\ntransformer:bytes (client tells server it's a bytes  
message)


+1

3) SEND\n...\ntransformer:default (client tells server to use  
content-length

to make determination)


-1 Give it a descriptive name so that we can change the default  
without breaking these.



4) SEND\n...\n (no transformer specified - same as #3)


+1

5) SEND\n..\ntransformer:bob (client gives server unknown  
transformer - use

default)


Return an error -- do not quietly swallow this.


Server->Client
1) MESSAGE\n...\ntransformer:text (server tells client it's a text  
message)


+1


2) MESSAGE\n...\ntransformer:bytes (server tells client it's a bytes
message)


+1


3) MESSAGE\n...\ntransformer:default (server tells client to use
content-length to make determination)


-1 same as #3 above


4) MESSAGE\n...\n (no transformer specified - same as #3)


+1


5) MESSAGE\n...\ntransformer:bob (server tells client to use unknown
transformer - use default)


-1 same as #5 above


This does highlight that we have two real transform cases, send and  
receive if we support CONNECT or SUBSCRIBE level transformers. We can  
infer the correct direct on MESSAGE and SEND, but not the others. As  
this would make the interface have all of two methods, I am quite  
happy combining it.


Alternately we can have different headers on SUBSCRIBE and CONNECT

-Brian

[jira] Commented: (AMQ-752) fix the uberjar to tidy up the notice/license files to make it absolutely clear whats going on

2006-06-13 Thread robert burrell donkin (JIRA)

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

robert burrell donkin commented on AMQ-752:
---

Uber jar licensing seems like a thorny issue to me and probably one that's 
quite a bit bigger than just ActiveMQ. Once I find some time, I should raise 
this on legal, write up some documentation in the release and then talk to the 
maveneers. If I don't before you're next release, please feel free to kick me 
(gently).

> fix the uberjar to tidy up the notice/license files to make it absolutely 
> clear whats going on
> --
>
>  Key: AMQ-752
>  URL: https://issues.apache.org/activemq/browse/AMQ-752
>  Project: ActiveMQ
> Type: Bug

> Reporter: james strachan
> Priority: Blocker
>  Fix For: 4.1, 4.0.1

>
>
> all the various LICENSEs need to be appended into a single LICENSE and the 
> notices consolidated.
> Also we might want to...
> * the MANIFEST lacks a Implementation-Vendor-Id. not reported harmful but is
> in the spec. suggested value: org.apache.
> * the MANIFEST lacks a Specification-Version but has an
> Implementation-Version. suggested value 4.0.
> * better if the source extracts into a directory with a different name from
> the binary distribution. for example, incubator-activemq-src for the source
> and incubator-activemq for the binary (say.
> * i would prefer the binaries and distributions names to contain apache. for
> example apache-incubator-activemq.

-- 
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: STOMP and JMSType

2006-06-13 Thread Nathan Mittler

Could you guys point me to a place in AMQ where this sort of thing is being
done?  That would save me a lot of searching =)

I'm viewing this problem from the client side - the Stomp C++ client that
Tim Bish and I are writing currently supports text and bytes messages.  So
when I get a stomp frame in, I need to map it back to a text or bytes
message.  We chose to do this for a couple of reasons: 1) to give JMS users
a familiar interface and 2) to provide a simple interface for reading and
writing text messages (e.g. xml).

With that said, I'm not seeing how I can do that mapping if the transformer
is provided only in the SUBSCRIBE.  A client could potentially get a variety
of message types from a single subscription.  I think it would have to be
part of the MESSAGE frame, rather than the SUBSCRIBE.

Here are the use cases I see:

Client->Server
1) SEND\n...\ntransformer:text (client tells server it's a text message)
2) SEND\n...\ntransformer:bytes (client tells server it's a bytes message)
3) SEND\n...\ntransformer:default (client tells server to use content-length
to make determination)
4) SEND\n...\n (no transformer specified - same as #3)
5) SEND\n..\ntransformer:bob (client gives server unknown transformer - use
default)

Server->Client
1) MESSAGE\n...\ntransformer:text (server tells client it's a text message)
2) MESSAGE\n...\ntransformer:bytes (server tells client it's a bytes
message)
3) MESSAGE\n...\ntransformer:default (server tells client to use
content-length to make determination)
4) MESSAGE\n...\n (no transformer specified - same as #3)
5) MESSAGE\n...\ntransformer:bob (server tells client to use unknown
transformer - use default)

Does this make sense, or am I missing something?

Thanks,
Nate

On 6/13/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:

> I would suggest that we use a weak form of specification encoding.
> ActiveMQ already uses pseudo-urls in a lot of places, and named
> transforms trump class names, usually:
>

yeah! URI style configuration rocks!

> -Brian
>
>
>
>
>

--
Regards,
Hiram

[jira] Commented: (GERONIMO-2098) Application migration to Maven 2: remote-deploy

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

Prasad Kashyap commented on GERONIMO-2098:
--

RTC vote thread.

http://www.mail-archive.com/dev@geronimo.apache.org/msg23947.html

> Application migration to Maven 2: remote-deploy
> ---
>
>  Key: GERONIMO-2098
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2098
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: application client
> Versions: 1.2
> Reporter: Prasad Kashyap
> Assignee: David Jencks
>  Fix For: 1.2
>  Attachments: remote-deploy-v2.patch, remote-deploy-v3.patch, 
> remote-deploy.patch
>
> Merge remote-deploy-lib with remote-deploy
> Migrate remote-deploy to M2.

-- 
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: rc1 Status and Next Steps

This jar: http://dist.codehaus.org/stax/jars/stax-api-1.0.1.jardoes not contain anything and is licensed under ASL 2.I guess you are refering to the stax RI from BEA, but this one
is not licensed under ASL and is not reditributable.Cheers,Guillaume NodetOn 6/13/06, Donald Woods <
[EMAIL PROTECTED]> wrote:If you look at the NOTICES-Draft1.txt file I attached before Dave's,
you'll see the Stax source contains the following License/Notices whichneed to be mentioned -(i) Indiana University Extreme!  LabSoftware License V1.1  Indiana University Extreme! Lab Software License, Version 
1.1.1   Copyright (c) 2002 Extreme! Lab, Indiana University. All rights reserved.   Redistribution and use in source and binary forms, with or withoutmodification, are permitted provided that the following conditions are met:
   1. Redistributions of source code must retain the above copyrightnotice, this list of conditions and the following disclaimer.   2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in thedocumentation and/or other materials provided with the distribution.   3. The end-user documentation included with the redistribution, ifany, must include the following acknowledgment:  "This product includes
software developed by the Indiana University Extreme! Lab(http://www.extreme.indiana.edu/)."  Alternately, this acknowledgmentmay appear in the software itself, if and wherever such third-party
acknowledgments normally appear.   4. The names "Indiana University" and "Indiana University Extreme!Lab" must not be used to endorse or promote products derived from thissoftware without prior written permission. For written permission,
please contact http://www.extreme.indiana.edu/.   5. Products derived from this software may not use "IndianaUniversity" name nor may "Indiana University" appear in their name,
without prior written permission of the Indiana University.   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIEDWARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BELIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, ORCONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OFSUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND  ON ANY THEORY OF LIABILITY, WHETHER INCONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.  (ii)The Apache Software License, Version 1.1   Copyright (c) 2000 The Apache Software Foundation.  All rights reserved.
  Redistribution and use in source and binary forms, with or withoutmodification, are permitted provided that the following conditions are met:   1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.   2. Redistributions in binary form must reproduce the above copyrightnotice, this list of conditions and the following disclaimer in thedocumentation and/or other materials provided with the distribution.
   3. The end-user documentation included with the redistribution, ifany, must include the following acknowledgment:  "This product includessoftware developed by the Apache Software Foundation(
http://www.apache.org/)."  Alternately, this acknowledgment may appearin the software itself, if and wherever such third-party acknowledgmentsnormally appear.   4. The names "Crimson" and "Apache Software Foundation" must not be
used to endorse or promote products derived from this software withoutprior written permission. For written permission, please contact[EMAIL PROTECTED].   5. Products derived from this software may not be called "Apache",
nor may "Apache" appear in their name, without prior written permissionof the Apache Software Foundation.   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIEDWARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  INNO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BELIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OFSUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESSINTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OFTHE POSSIBILITY OF SUCH DAMAGE.  
(iii) Miscellaneous Notices  This software consists of voluntary contributions mad

Re: rc1 Status and Next Steps

2006-06-13 Thread Donald Woods

If you look at the NOTICES-Draft1.txt file I attached before Dave's, 
you'll see the Stax source contains the following License/Notices which 
need to be mentioned -



(i) Indiana University Extreme!  LabSoftware License V1.1

 Indiana University Extreme! Lab Software License, Version 1.1.1

  Copyright (c) 2002 Extreme! Lab, Indiana University. All rights reserved.

  Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions are met:


  1. Redistributions of source code must retain the above copyright 
notice, this list of conditions and the following disclaimer.


  2. Redistributions in binary form must reproduce the above copyright 
notice, this list of conditions and the following disclaimer in the 
documentation and/or other materials provided with the distribution.


  3. The end-user documentation included with the redistribution, if 
any, must include the following acknowledgment:  "This product includes 
software developed by the Indiana University Extreme! Lab 
(http://www.extreme.indiana.edu/)."  Alternately, this acknowledgment 
may appear in the software itself, if and wherever such third-party 
acknowledgments normally appear.


  4. The names "Indiana University" and "Indiana University Extreme! 
Lab" must not be used to endorse or promote products derived from this 
software without prior written permission. For written permission, 
please contact http://www.extreme.indiana.edu/.


  5. Products derived from this software may not use "Indiana 
University" name nor may "Indiana University" appear in their name, 
without prior written permission of the Indiana University.



  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN 
NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE 
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND  ON ANY THEORY OF LIABILITY, WHETHER IN 
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
THE POSSIBILITY OF SUCH DAMAGE.



 

(ii)The Apache Software License, Version 1.1


  Copyright (c) 2000 The Apache Software Foundation.  All rights reserved.

 Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions are met:


  1. Redistributions of source code must retain the above copyright 
notice, this list of conditions and the following disclaimer.


  2. Redistributions in binary form must reproduce the above copyright 
notice, this list of conditions and the following disclaimer in the 
documentation and/or other materials provided with the distribution.


  3. The end-user documentation included with the redistribution, if 
any, must include the following acknowledgment:  "This product includes 
software developed by the Apache Software Foundation 
(http://www.apache.org/)."  Alternately, this acknowledgment may appear 
in the software itself, if and wherever such third-party acknowledgments 
normally appear.


  4. The names "Crimson" and "Apache Software Foundation" must not be 
used to endorse or promote products derived from this software without 
prior written permission. For written permission, please contact 
[EMAIL PROTECTED]


  5. Products derived from this software may not be called "Apache", 
nor may "Apache" appear in their name, without prior written permission 
of the Apache Software Foundation.


  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED 
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN 
NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE 
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
THE POSSIBILITY OF SUCH DAMAGE.


 

(iii) Miscellaneous Notices

 This software consists of voluntary contributions made by many 
individuals on behalf of the Apache Software Foundation and was

 originally based on software copyright (c) 1999, Sun Microsystems, Inc.,
 http://www.sun.com.  For more in

Re: rc1 Status and Next Steps

The stax api which is hosted at codehaus is ASL 2 and does not have anyNOTICE file included, so my best guess is that there is nothing to do for this one.Cheers,Guillaume Nodet
On 6/13/06, Dave Colasurdo <[EMAIL PROTECTED]> wrote:
Dave Colasurdo wrote:> John Sisson wrote: 6. Third Party Licenses.  This needs to be reviewed and the>>> appropriate licenses compiled. Volunteers?  We did not have one in>>> the 
1.0 stream so I'd like clarification if this is a requirement or>>> something that can be deferred.>> IMO this is a requirement.  Just have a look at some of the licenses>> for components we are redistributing.
 I have collated a list of components attached to a file in>> http://issues.apache.org/jira/browse/GERONIMO-2112 indicating whether
>> IMHO they require an attribution in the NOTICES.txt file or a license>> included in the LICENSE.txt file and where to get the information from.>> There are some that require further investigation as IMNAL.  Can
>> people please look at the file attached to GERONIMO-2112 and see if>> there are any obvious omissions/errors and comment on the items>> requiring further investigation. If someone has time to pick it up from and start assembling the
>> LICENSE.txt and NOTICE.txt files, please do, otherwise I'll continue>> in the morning (Sydney time). John,> I am also investigating.  I suspect jdom and castor may also need to be
> added to the list..  Will make an initial pass at the files and attach> them to GERONIMO-2112.. Of course IANAL.. :)>Have attached LICENSE.txt and NOTICE.txt to the JIRA:
http://issues.apache.org/jira/browse/GERONIMO-2112I still need some input on openejb and stax-api..  David Blevins andJames Strachan.. Are there any license terms or notices that need to beadded  for these projects?
Thanks-Dave-

[jira] Commented: (GERONIMO-2114) Timer already cancelled error when attempting to grab a connection from a pool

2006-06-13 Thread Kevan Miller (JIRA)

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

Kevan Miller commented on GERONIMO-2114:


Jay, thanks for your help with this issue!

Seems to be memory-related. Jay reported that Increasing the heap size seems to 
avoid the problem.

A RuntimeException or Error (e.g. an OutOfMemoryError) could cause a Timer to 
appear to be "cancelled". We should try to give some indication in 
AbstractSinglePoolConnectionInterceptor.FillTask.run() if an error occurs... 

> Timer already cancelled error when attempting to grab a connection from a pool
> --
>
>  Key: GERONIMO-2114
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2114
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: databases
> Versions: 1.1
>  Environment: Linux w/ 2.6 kernel
> mySQL 5.0 w/ connector/j
> Geronimo 1.1-rc1
> Reporter: Jay D. McHugh
>  Attachments: PaLM.war, build_plc.sql, plc_db.deploy.g1.1.xml
>
> After a relatively small number of connections to the database, a 'timer 
> already cancelled' error comes up and the server no longer functions properly.

-- 
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-2098) Application migration to Maven 2: remote-deploy

2006-06-13 Thread David Jencks (JIRA)

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

Resolution: Fixed

Thanks to the +1 vote from myself, Aaron, and Guillaume I've applied the final 
patch in rev 413963

> Application migration to Maven 2: remote-deploy
> ---
>
>  Key: GERONIMO-2098
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2098
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: application client
> Versions: 1.2
> Reporter: Prasad Kashyap
> Assignee: David Jencks
>  Fix For: 1.2
>  Attachments: remote-deploy-v2.patch, remote-deploy-v3.patch, 
> remote-deploy.patch
>
> Merge remote-deploy-lib with remote-deploy
> Migrate remote-deploy to M2.

-- 
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: RELEASE-NOTES-1.1



On Jun 13, 2006, at 3:11 PM, Donald Woods wrote:

2) Eclipse users who deploy the app into the server, test it, stop  
the server and then delete the project and files from Eclipse


Won't be an issue.  For apps running resources directly from the  
workspace/project, these apps will be deployed to a separate config- 
store and will be non-persistant.



-sachin

Re: rc1 Status and Next Steps

2006-06-13 Thread Dave Colasurdo


Dave Colasurdo wrote:

John Sisson wrote:

6. Third Party Licenses.  This needs to be reviewed and the 
appropriate licenses compiled. Volunteers?  We did not have one in 
the 1.0 stream so I'd like clarification if this is a requirement or 
something that can be deferred.
IMO this is a requirement.  Just have a look at some of the licenses 
for components we are redistributing.


I have collated a list of components attached to a file in 
http://issues.apache.org/jira/browse/GERONIMO-2112 indicating whether 
IMHO they require an attribution in the NOTICES.txt file or a license 
included in the LICENSE.txt file and where to get the information from.
There are some that require further investigation as IMNAL.  Can 
people please look at the file attached to GERONIMO-2112 and see if 
there are any obvious omissions/errors and comment on the items 
requiring further investigation.


If someone has time to pick it up from and start assembling the 
LICENSE.txt and NOTICE.txt files, please do, otherwise I'll continue 
in the morning (Sydney time).




John,
I am also investigating.  I suspect jdom and castor may also need to be 
added to the list..  Will make an initial pass at the files and attach 
them to GERONIMO-2112.. Of course IANAL.. :)




Have attached LICENSE.txt and NOTICE.txt to the JIRA:

http://issues.apache.org/jira/browse/GERONIMO-2112

I still need some input on openejb and stax-api..  David Blevins and 
James Strachan.. Are there any license terms or notices that need to be 
added  for these projects?


Thanks
-Dave-

RE: RELEASE-NOTES-1.1

2006-06-13 Thread Lin Sun

Good point!  I shutdown the server and renamed the hello directory.  Then
start the server afterwards.  I saw the following exception when server
attempted to start the hello module.  I didn't see Geronimo server started
at the end but luckily all the important module seemed to be started before
my little hello module, which is the last in var\config\config.xml file.

Module 24/24 hello/1.1/war  Exception in threa
d "main" java.lang.AssertionError: Expected one match for pattern ".", but
got 0
 matches
at
org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanDa
ta(ConfigurationUtil.java:331)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio
nGBeans(ConfigurationUtil.java:359)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke
rnelConfigurationManager.java:187)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:512)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:493)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla
ssByCGLIB$$ce77a924.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java(Inlined
Compil
ed Code))
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod
Invoker.java(Compiled Code))
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
n.java(Inlined Compiled Code))
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
java(Compiled Code))
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java(I
nlined Compiled Code))
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat
ionInvoker.java(Compiled Code))
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro
xyMethodInterceptor.java(Compiled Code))
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$Enhan
cerByCGLIB$$f05707cd.startConfiguration()
at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:297)
at org.apache.geronimo.system.main.Daemon.(Daemon.java:74)
at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377)

I guess this error can be improved in the future releases, but for 1.1 user
needs to be good aware of what inPlace means before they use it for 1.1.

I hope this is less of a problem for scenario #2, as I am not aware of the
in-place option to deploy a project in Eclipse/WTP but Sachin can certainly
correct me as I haven't tried the 1.1 version of the Eclipse plugins yet.

Lin

-Original Message-
From: Donald Woods [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 13, 2006 3:12 PM
To: dev@geronimo.apache.org
Subject: Re: RELEASE-NOTES-1.1

What happens in the case that the files no longer exist on the next 
server startup?  Two scenarios I'm worried about:
1) files were loaded from an NFS/Samba/SMB share which has become 
disconnected
2) Eclipse users who deploy the app into the server, test it, stop the 
server and then delete the project and files from Eclipse

-Donald

Aaron Mulder wrote:
> On 6/13/06, Lin Sun <[EMAIL PROTECTED]> wrote:
> 
>> I am trying to learn what the in-place deployment mean and how to use it.
>> My understanding was that users can update the hot deploy files (for
>> example, update one jsp file) in the Geronimo_home\deploy directory and
>> server will redeploy the change automatically.   This was not working in
>> 1.0, as users need to replace the entire directory in the
>> Geronimo_home\deploy directory.
> 
> 
> That should be true in both 1.0 and 1.1 (if not, I guess it's a bug).
> 
> But in 1.1, there is a separate option, which is to not copy your
> files to the hot deploy directory at all, but instead use the deploy
> tool with a special option to enable an in-place deployment.  This
> means that instead of copying your files into the server directory at
> all, it will deploy and access them from wherever they currently are.
> 
> Thanks,
>Aaron
> 
>> But after reading your note below, I think I am lost.   Please advise.
>>
>> Lin
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron
>> Mulder
>> Sent: Thursday, June 08, 2006 7:23 PM
>> To: dev@geronimo.apache.org
>> Subject: Re: RELEASE-NOTES-1.1
>>
>>  - We should add a point about in-place deployment.  "Geronimo
>> supports in-place deployment, which means an archive or directory can
>> be deployed without being copied into the Geronimo directory tree."
>>
>>
>>
>>
> 
>

[jira] Updated: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file

2006-06-13 Thread Dave Colasurdo (JIRA)

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

Dave Colasurdo updated GERONIMO-2112:
-

Attachment: NOTICE.txt
LICENSE.txt

Here is the initial pass at the LICENSE.TXT and NOTICE.TXT files for Geronimo 
1.1..

Still need input on Openejb and stax-api .. and of course a thorough review of 
all content..

Note that antlr contains two licenses.. I suspect only the first one is needed 
but included both so that you could see them.

Thanks
-Dave-  

> Place required attrtibutions in the NOTICES.txt file or a license included in 
> the LICENSE.txt file
> --
>
>  Key: GERONIMO-2112
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2112
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.1
> Reporter: John Sisson
> Priority: Blocker
>  Fix For: 1.1
>  Attachments: LICENSE.txt, NOTICE.txt, NOTICES-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft1.txt
>
> I have collated a list of components in the attached file indicating whether 
> IMHO they require an attribution in the NOTICES.txt file or a license 
> included in the LICENSE.txt file.  
> See http://www.apache.org/dev/apply-license.html#new for information on 
> license files.
> See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example 
> of a LICENSE file containing other licenses.

-- 
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: RELEASE-NOTES-1.1

2006-06-13 Thread Donald Woods

What happens in the case that the files no longer exist on the next 
server startup?  Two scenarios I'm worried about:
1) files were loaded from an NFS/Samba/SMB share which has become 
disconnected
2) Eclipse users who deploy the app into the server, test it, stop the 
server and then delete the project and files from Eclipse



-Donald


Aaron Mulder wrote:

On 6/13/06, Lin Sun <[EMAIL PROTECTED]> wrote:


I am trying to learn what the in-place deployment mean and how to use it.
My understanding was that users can update the hot deploy files (for
example, update one jsp file) in the Geronimo_home\deploy directory and
server will redeploy the change automatically.   This was not working in
1.0, as users need to replace the entire directory in the
Geronimo_home\deploy directory.



That should be true in both 1.0 and 1.1 (if not, I guess it's a bug).

But in 1.1, there is a separate option, which is to not copy your
files to the hot deploy directory at all, but instead use the deploy
tool with a special option to enable an in-place deployment.  This
means that instead of copying your files into the server directory at
all, it will deploy and access them from wherever they currently are.

Thanks,
   Aaron


But after reading your note below, I think I am lost.   Please advise.

Lin

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron
Mulder
Sent: Thursday, June 08, 2006 7:23 PM
To: dev@geronimo.apache.org
Subject: Re: RELEASE-NOTES-1.1

 - We should add a point about in-place deployment.  "Geronimo
supports in-place deployment, which means an archive or directory can
be deployed without being copied into the Geronimo directory tree."









smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Commented: (GERONIMO-2114) Timer already cancelled error when attempting to grab a connection from a pool

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

Jay D. McHugh commented on GERONIMO-2114:
-

After everything is setup, browse to http://servername:8080/PaLM/

Enter user: jmchugh
password: noise

Hover the mouse over 'system maintenance' and choose 'maintain product 
categories'
Choose one of the categories from the list, it should fill in the remaining 
fields.
Hover the mouse over 'system maintenance' and choose 'maintain product 
categories' again.
Choose one of the categories from the list, it should again fill in the 
remaining fields.

For me right now, it will not even work on the first try - there is already an 
error.

> Timer already cancelled error when attempting to grab a connection from a pool
> --
>
>  Key: GERONIMO-2114
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2114
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: databases
> Versions: 1.1
>  Environment: Linux w/ 2.6 kernel
> mySQL 5.0 w/ connector/j
> Geronimo 1.1-rc1
> Reporter: Jay D. McHugh
>  Attachments: PaLM.war, build_plc.sql, plc_db.deploy.g1.1.xml
>
> After a relatively small number of connections to the database, a 'timer 
> already cancelled' error comes up and the server no longer functions properly.

-- 
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-2114) Timer already cancelled error when attempting to grab a connection from a pool

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

Jay D. McHugh updated GERONIMO-2114:


Attachment: plc_db.deploy.g1.1.xml

After installing the mysql jdbc driver into Geronimo and creating the database -

Deploy a connection pool with this plan.

> Timer already cancelled error when attempting to grab a connection from a pool
> --
>
>  Key: GERONIMO-2114
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2114
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: databases
> Versions: 1.1
>  Environment: Linux w/ 2.6 kernel
> mySQL 5.0 w/ connector/j
> Geronimo 1.1-rc1
> Reporter: Jay D. McHugh
>  Attachments: PaLM.war, build_plc.sql, plc_db.deploy.g1.1.xml
>
> After a relatively small number of connections to the database, a 'timer 
> already cancelled' error comes up and the server no longer functions properly.

-- 
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-2114) Timer already cancelled error when attempting to grab a connection from a pool

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

Jay D. McHugh updated GERONIMO-2114:


Attachment: build_plc.sql

Here is a script that will populate a test database.

Instructions:

1) Create a database called 'plc'
2) Create a user 'plcData' with password 'plcPassword' and grant full rights to 
plc database.
3) Execute the following command from command line to populate the database:
mysql --user=plcData --password=plcPassword plc < build_plc.sql

> Timer already cancelled error when attempting to grab a connection from a pool
> --
>
>  Key: GERONIMO-2114
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2114
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: databases
> Versions: 1.1
>  Environment: Linux w/ 2.6 kernel
> mySQL 5.0 w/ connector/j
> Geronimo 1.1-rc1
> Reporter: Jay D. McHugh
>  Attachments: PaLM.war, build_plc.sql
>
> After a relatively small number of connections to the database, a 'timer 
> already cancelled' error comes up and the server no longer functions properly.

-- 
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-2114) Timer already cancelled error when attempting to grab a connection from a pool

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

Jay D. McHugh updated GERONIMO-2114:


Attachment: PaLM.war

Here is the application war file.

> Timer already cancelled error when attempting to grab a connection from a pool
> --
>
>  Key: GERONIMO-2114
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2114
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: databases
> Versions: 1.1
>  Environment: Linux w/ 2.6 kernel
> mySQL 5.0 w/ connector/j
> Geronimo 1.1-rc1
> Reporter: Jay D. McHugh
>  Attachments: PaLM.war
>
> After a relatively small number of connections to the database, a 'timer 
> already cancelled' error comes up and the server no longer functions properly.

-- 
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-2114) Timer already cancelled error when attempting to grab a connection from a pool

Timer already cancelled error when attempting to grab a connection from a pool
--

 Key: GERONIMO-2114
 URL: http://issues.apache.org/jira/browse/GERONIMO-2114
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: databases  
Versions: 1.1
 Environment: Linux w/ 2.6 kernel
mySQL 5.0 w/ connector/j
Geronimo 1.1-rc1

Reporter: Jay D. McHugh


After a relatively small number of connections to the database, a 'timer 
already cancelled' error comes up and the server no longer functions properly.

-- 
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: [RTC] : Migrate remote-deploy to m2


+1, seems fine to me.

Btw, would it be easier for the m2 migration, to create a branch, where 
the RTC would not apply, and then merge all in trunk ?
I guess this could also apply to some features that requires a 
significant number of patches...


Cheers,
Guillaume Nodet

Prasad Kashyap wrote:


Merged remote-deploy-lib with remote-deploy.
Migrated remote-deploy to M2.

http://issues.apache.org/jira/browse/GERONIMO-2098

Re: [RTC] m2-plugins deployment plugin: PLEASE VOTE

Last (and only, depending on how you count) +1 was 4 days ago, any  
chance 2 more people are willing to review this?


thanks
david jencks



On Jun 9, 2006, at 7:51 AM, Guillaume Nodet wrote:


+1

Cheers,
Guillaume Nodet

David Jencks wrote:


I've uploaded

http://issues.apache.org/jira/secure/attachment/12335128/geronimo-  
deployment-plugin-RTC-VOTE.2.patch


incorporating most of your comments, see below.

Thanks for the review!

david jencks

On Jun 6, 2006, at 11:57 PM, Jacek Laskowski wrote:


On 6/6/06, David Jencks <[EMAIL PROTECTED]> wrote:


Prasad has been working for a long time on an m2 deployment plugin.
I've cleaned up his latest patch a little bit and think its  
ready to

commit.

Please review http://issues.apache.org/jira/secure/attachment/
12335116/geronimo-deployment-plugin-RTC-VOTE.patch



I have taken a look at the patch and the comments are as follows
(they're rather style-centric nor technical, but still valid I  
hope).

No testing was performed.

1/ I was scared to read: "May not have been tested." in one of  
the  classes



You want me to lie :-) ? I don't think anyone has ever used the in- 
vm  startServer command in the m1 plugin, so I doubt prasad has  
tested  this one either.  I still think its worth including as a  
starting  point in case some one wants to try it out.




2/ Copyright 2004-2006 - shouldn't it be Copyright 2006 only?



These are basically copies + modifications of the m1 deployment   
plugin, copyright 2004.  I don't know if any changes happened in   
2005, but 2004 and 2006 are definitely needed.




3/ The javadoc of classes should be consistent. It means that it   
should read:


  /**
   * @goal undeploy (if appropriate)
   *
   * @version $Rev$ $Date$
   */

whereas some contain

  @version $Revision$ $Date$

or no version at all.



They should all have the @version, but only mojos should have the   
@goal in order to not confuse maven.  I've fixed the @version tags  
as  well as I can find them.




4/ Geronimo :: Maven Deployment Plugin using m2 -> Geronimo ::  
Maven 2
Deployment Plugin or alternatively Geronimo :: Maven Deployment  
Plugin

for Maven 2, but I'd prefer the former.



fixed



5/ geronimo-deployment-plugin/pom.xml has no ASF license header.


fixed.  I think its better to include  the asf license in the  
source  even if maven removes it during processing.





So, unless it's corrected I'm -1. If you're swampped with your other
work, I can take care of it and propose the patch corrected again.


Here's my +1.



It doesn't count, though ;-)



Why not?  Because I edited prasad's patch for formatting and  
removed  unused cruft?  Ken's directive requires 3 +1 votes from  
committers  other than the proposer (who apparently does not need  
to be a  committer): although the document he appears to have  
adapted states  only PMC member votes count, that is not in his  
directive.  Since he  hasn't responded to requests for  
clarification I think we have to  take him at his word.


thanks
david jencks






david jencks



Jacek

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

[jira] Updated: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file

2006-06-13 Thread Donald Woods (JIRA)

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

Donald Woods updated GERONIMO-2112:
---

Attachment: NOTICES-draft1.txt

Attaching a modified NOTICES.TXT from our WASCE redistribution of Geronimo, 
which should get you 90+% of what you need.

> Place required attrtibutions in the NOTICES.txt file or a license included in 
> the LICENSE.txt file
> --
>
>  Key: GERONIMO-2112
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2112
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.1
> Reporter: John Sisson
> Priority: Blocker
>  Fix For: 1.1
>  Attachments: NOTICES-draft1.txt, 
> geronimo-1.1-RC-licenses-attributions-draft1.txt
>
> I have collated a list of components in the attached file indicating whether 
> IMHO they require an attribution in the NOTICES.txt file or a license 
> included in the LICENSE.txt file.  
> See http://www.apache.org/dev/apply-license.html#new for information on 
> license files.
> See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example 
> of a LICENSE file containing other licenses.

-- 
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: [RTC] : Migrate remote-deploy to m2: PLEASE VOTE

This is really a pretty simple minded uncontroversial patch that's  
been sitting around for 3 or 4 days now after 2 quick +1's.  I know  
we're trying to get 1.1 out the door but another review would be  
really appreciated to keep the m2 migration moving.

thanks
david jencks

On Jun 10, 2006, at 10:13 AM, Aaron Mulder wrote:

I've read through it and support it, but have not tried it.  Since I
also have mac/linux and trust David J, here's my +1.  :)

Thanks,
  Aaron

On 6/10/06, David Jencks <[EMAIL PROTECTED]> wrote:

To review, in 1.0 we had problems with web app classloaders that
prevented gbeans being loaded from the web app classloader: as a
workaround for remote-deploy we put the gbean classes for the web app
in remote-deploy-lib.  This patch brings everything back into remote-
deploy.

I've provided instructions for a mac/linux system in the jira issue,
applied the patch, and verified it works in m1 and m2 builds.

Here's my +1 to committing it.

thanks
david jencks

On Jun 9, 2006, at 12:52 PM, Prasad Kashyap wrote:

> Sounds good. As per your comments I have attached instructions  
in the
> comments and a patch (remote-deploy-v3.patch) that will also  
take into

> account m1 build.
>
> Please review and vote.
>
> Cheers
> Prasad
>
> On 6/9/06, David Jencks <[EMAIL PROTECTED]> wrote:
>> I don't think this is quite ready for a vote yet, and I'm not
>> convinced it requires a vote.
>>
>> First, it really should include more of a description of what the
>> purpose of the change is, such as:
>>
>> "Due to bugs in the web app classloader in 1.0, the remote  
deploy war

>> was split into 2 modules.  Since that classloader bug has been
>> resolved in 1.1 it's time to merge this stuff back into  one  
module"

>>
>> Second, when a patch moves a file, it should not be applied as a
>> patch.  The patch might be OK to look at, but we have to  
preserve svn
>> history, so whoever is going to "apply the patch" needs to know  
the
>> svn commands that resulted in the patch.  Here we need  
something like

>>
>>
>> "Run these svn commands:
>> svn mv modules/remote-deploy-lib/src/java/..java modules/ 
remote-

>> deploy/src/java/
>> ...
>> svn rm modules/remote-deploy-lib
>> "
>> Other adjustments to make the build work again should be in a  
patch

>> that does not include the effects of the svn commands.
>>
>> Thirdly I don't think this patch fixes the m1 build  
unfortunately

>> we can't throw it out yet.
>>
>> The reason I don't think this requires a vote is that it does not
>> change any java code and is part of the bug fix to the web app
>> classloading.  However I think since you proposed a vote and we
>> haven't had much practice voting yet it would be a good idea to go
>> through the vote process on this small uncontroversial change.
>>
>> Many thanks
>> david jencks
>>
>> On Jun 9, 2006, at 9:23 AM, Prasad Kashyap wrote:
>>
>> > Merged remote-deploy-lib with remote-deploy.
>> > Migrated remote-deploy to M2.
>> >
>> > http://issues.apache.org/jira/browse/GERONIMO-2098
>>
>>

Re: STOMP and JMSType

On 6/13/06, Brian McCallister <[EMAIL PROTECTED]> wrote:

On Jun 13, 2006, at 10:36 AM, Hiram Chirino wrote:

> The think your views are a bit STOMP point of view centric.  bytes
> messages work fine when both end assume you are just moving around
> bytes messages.. and it's true everything can eventually converted
> down to a byte[].

Yes, and no. I want to see ActiveMQ become the de facto standard for
messaging, period. Part of that is supporting non-JMS really well.
So, yes, I am looking at it from a non-Java-centric (but allowing for
Java via JMS) point of view =)

> If you look at it from a JMS point of view, how will a STOMP client
> deal with an existing JMS network?  What if a JMS MapMessage or an
> ObjectMessage is sent to a stomp client?  The question is how will
> that be encoded to bytes[]..  And what if the STOMP client needs to
> talk to an App that expect JMS MapMessages or ObjectMessages??

This seems, to me, to be a strong argument for a pluggable framework
for message transformation. Going from JMS to Stomp for non Text/
Bytes will be quite application specific, I think. In that case
having a single solution applied to the whole messaging system is
pretty ugly, period. If you are bridging from JMS to stomp, and using
things other than bytes or text, it is going to be kind of ugly.

> Yes I guess using a ESB style transformer in the middle would solve
> the issue, but I think it adds complexity in the overall solution.  It
> would be easier if the STOMP client could send a Map or Object message
> directly even if it is an ActiveMQ extension that allows it to do
> that.

For any messaging system used for multiple applications, I think that
mapping as a republishing service

>
> Perhaps we add a header on send:
> activemq-tranformation: org.a.a.transform.StompTextToMapMessage

I like this name better. Stomp is verbose anyway =)

Being able to send a transformation specification is powerful, but
kind of scary. I *really* think this should be a configurable option
on the server, rather than have to have the client know what is
happening on the other end. Allowing the client to specify is good,
requiring the client to specify is bad.

So if the the client does not specifies a transformation, the
'default' transformation will be used, which is hopefully backward
compatible with what we are doing today in 4.0 and 3.x.

And perhaps we allow the 'default' transformation the be configurable
on the server side so that the default can be changed.  But perhaps
this would over complicate things as clients would expect a default
behaviour which we have now allowed the a server admin to change.

> And on subscribe we add another header to covert on the way in.
> activemq-tranformation: org.a.a.transform.MapMessageToStompText

That is a very interesting idea. On subscribe you can specify a
transformer to apply to whole session by default. A step up from per
message, but I still think this should be able to be specified on the
server config as well.

> And if those are just class names, then the  users could implement
> thier own transformation implementations and just add them to the
> broker classpath.

I would suggest that we use a weak form of specification encoding.
ActiveMQ already uses pseudo-urls in a lot of places, and named
transforms trump class names, usually:

activemq-transformer: class:org.example.WombatTransformer

activemq-transformer: named:wombat-transformer

inline: ruby:it.gsub /kangaroos/i, "wombats"

inline is not a good idea =)

-Brian

--
Regards,
Hiram

Re: [RTC] ActiveMQ GBean modules

My first sentence is supposed to mean "I support moving this code to  
geronimo" :-).  I went ahead and reviewed it even without it being  
attached to a jira issue, but I would like there to be a jira issue  
for this for tracking purposes: the patch doesn't need to be attached  
to it.


thanks
david jencks

On Jun 13, 2006, at 11:31 AM, David Jencks wrote:

I think that this gbean adaptation code should be in geronimo  
rather than amq.  I'm OK with applying it as is but would prefer  
some issues to be addressed first or, even better,  immediately  
after the transfer (assuming it is done with svn mv).


1. DataSourceReference should be replaced by the geronimo class  
that does the same thing, ConnectionFactorySource.


2. I think it would be preferable to get the module/configuration  
classloader in the constructor as a magic attribute and use it in  
BrokerServiceGBeanImpl.doStart rather than the classloader of  
BrokerServiceGBeanImpl.


3. Same for TransportConnectorGBeanImpl.

4. This is a question, not really an issue, about this code:
+protected TransportConnector createBrokerConnector(String url)
throws Exception {
+return brokerService.getBrokerContainer().addConnector(url);
+}

To me it seems like this code is combining the functions of factory  
object and container.  Is this necessary and appropriate?  I'd be  
more comfortable with

Connector connector = ConnectorFactory.createConnector(url);
brokerService.getBrokerContainer().addConnector(connector);

I find that the combination style typically creates problems  
whenever trying to extend stuff, say by wrapping the connector.   
What do you think?


5. hardcoding the protocols in ActiveMQManagerGBean seems like a  
temporary expedient at best.


6. javadoc on public JMSConnector addConnector( ... in the manager  
gbean seems wrong... does not appear to return an object name.


7. Typo and innaccuracies in the first package.html... this stuff  
is only going to work in geronimo, jsr77/88 is not enough.


8. I'm not sure exactly what our official policy is but I prefer to  
remove "public" from methods in interfaces since it is the only  
choice and implied.


+1 if the above are addressed before or right after commit.  I only  
insist on (1), the others are more like suggestions.


thanks
david jencks





On Jun 5, 2006, at 4:19 PM, Hiram Chirino wrote:


Howdy folks,

Here's  a patch that brings in the activemq gbean modules into
geronimo.  It's partly what was in activemq 4.x and integrated into
geronimo 1.2-dead merged with the changes in the 3.x branch.

It compiles at least and looks like a reasonable start.  Once further
integration work gets done we may need to tweak a little more.   
here's

my +1 got get this committed.  I guess I just need 3 more.


Index: modules/activemq-gbean/project.properties
===
--- modules/activemq-gbean/project.properties   (revision 0)
+++ modules/activemq-gbean/project.properties   (revision 0)
@@ -0,0 +1,3 @@
+#  
---

+# Build Properties
+#  
---


Property changes on: modules/activemq-gbean/project.properties
___
Name: svn:executable
  + *

Index: modules/activemq-gbean/project.xml
===
--- modules/activemq-gbean/project.xml  (revision 0)
+++ modules/activemq-gbean/project.xml  (revision 0)
@@ -0,0 +1,104 @@
+
+
+

+
+
+3
+../../etc/project.xml
+
+Geronimo :: ActiveMQ :: GBeans
+geronimo-activemq-gbean
+ActiveMQ Geronimo / GBean supportshortDescription>

+ActiveMQ GBeans used for integration into Apache
Geronimo
+
+
+
+
+
+
+  
+incubator-activemq
+activemq-core
+4.0-SNAPSHOT
+  
+
+  
+incubator-activemq
+activeio-core
+3.0-SNAPSHOT
+  
+
+  
+geronimo
+geronimo-activemq-gbean-management
+${pom.currentVersion}
+  
+
+  
+geronimo
+geronimo-kernel
+${pom.currentVersion}
+  
+
+  
+geronimo
+geronimo-system
+${pom.currentVersion}
+  
+
+  
+geronimo
+geronimo-management
+${pom.currentVersion}
+  
+
+  
+geronimo
+geronimo-j2ee
+${pom.currentVersion}
+  
+
+  
+mx4j
+mx4j
+${mx4j_version}
+  
+
+  
+commons-logging
+commons-logging
+${commons_logging_version}
+http://jakarta.apache.org/commons/logging/
+  
+
+
+
+
+
+
+${basedir}/src/main/java
+${basedir}/src/main/testunitTestSourceDirectory>

+
+
+
+**/*Test.java
+
+
+
+
+

Property changes on: modules/a

Re: RELEASE-NOTES-1.1

2006-06-13 Thread Aaron Mulder


On 6/13/06, Lin Sun <[EMAIL PROTECTED]> wrote:

I am trying to learn what the in-place deployment mean and how to use it.
My understanding was that users can update the hot deploy files (for
example, update one jsp file) in the Geronimo_home\deploy directory and
server will redeploy the change automatically.   This was not working in
1.0, as users need to replace the entire directory in the
Geronimo_home\deploy directory.


That should be true in both 1.0 and 1.1 (if not, I guess it's a bug).

But in 1.1, there is a separate option, which is to not copy your
files to the hot deploy directory at all, but instead use the deploy
tool with a special option to enable an in-place deployment.  This
means that instead of copying your files into the server directory at
all, it will deploy and access them from wherever they currently are.

Thanks,
   Aaron


But after reading your note below, I think I am lost.   Please advise.

Lin

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron
Mulder
Sent: Thursday, June 08, 2006 7:23 PM
To: dev@geronimo.apache.org
Subject: Re: RELEASE-NOTES-1.1

 - We should add a point about in-place deployment.  "Geronimo
supports in-place deployment, which means an archive or directory can
be deployed without being copied into the Geronimo directory tree."

Re: 1.1-rc1 Now Available


Hey..

3.2.4 Should be up now on the codehaus repo.


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

I talked with Hiram tonight (before catching up on e-mail so I hadn't seen this 
note) about getting
3.2.4 closed out.  Apparently the Codehaus outage left AMQ in an indeterminent 
state.  We've tested
the existing 3.2.4-SNAPSHOT against CTS.  I would prefer to close out AMQ 3.2.4 
as is and fix this
for 1.1.1.  Small changes can set us back several days if there is some 
secondary effect.

Aaron Mulder wrote:
> As far as I know, the patch is valid, it just needs to be applied to a
> different module than it was created against.  I'm not sure if we're
> waiting for this for the release or not.  I had hoped it would go in.
> Hiram, do you want to look at it or do you want me to?
>
> Thanks,
>Aaron
>
> On 6/12/06, John Sisson <[EMAIL PROTECTED]> wrote:
>> I thought that we were waiting for
>> http://issues.apache.org/jira/browse/GERONIMO-1451 to be fixed.
>>
>> Aaron and Hiram do you know what is happening here?
>>
>> John
>>
>> Kevan Miller wrote:
>> > My first response went to the user list. I'm repeating on dev...
>> >
>> > ActiveMQ 3.2.4 hasn't been released yet? I see we're still including
>> > ActiveMQ 3.2.4-SNAPSHOT in our repository. What's the plan, there?
>> >
>> > I don't think we can release until ActiveMQ has released... Is there
>> > some problem?
>> >
>> > --kevan
>> >
>> > On Jun 11, 2006, at 11:48 PM, Matt Hogstrom wrote:
>> >
>> >> Over the past few days the outstanding issues that were raised about
>> >> the first candidate have been addressed.
>> >>
>> >> They were that we were missing the LICENSE.txt as well as Notices
>> >> from the distribution.  I added them.  Guillaume also pointed out
>> >> that he noted that there should be a Third Party Notices.  This was
>> >> not included in the original 1.0 or previous distributions so I did
>> >> not follow it up.  Thoughts?
>> >>
>> >> Also, the 1.0 release notes were removed and updated the thread
>> >> started by Hernan.  The Wiki has been updated and the wiki was the
>> >> source used to create the RELEASE-NOTES-1.1.txt file you will find in
>> >> the build.
>> >>
>> >> To avoid issues with the version number and the plugins I used rc1
>> >> which Aaron had added in the plugins for supported versions so I
>> >> trust that works here.
>> >>
>> >> JSisson addressed the problem with not being able to run Geronimo
>> >> under CygWin and Kevan worked with Aaron to address a new deployment
>> >> problem that left partially deployed artifacts in the repository.
>> >>
>> >> I have taken this build and run some performance tests on it and we
>> >> are significantly better in 1.1 than we were in 1.0.  We have a lot
>> >> of improvement left for CMP EJBs.  It appears that the performance
>> >> improvements in the EJB tier has changed a race condition when
>> >> running under DB2.  I'm afraid that the only way to address the
>> >> problem is to add a new feature to TranQL and OEJB that allow for the
>> >> specification of Isolation Levels for individual beans.  This is a
>> >> relatively simple change but the build as it stands is specification
>> >> compliant.  I would prefer to let this release go forward since CMP
>> >> 2.1 EJBs are not nearly as common as the other J2EE components.  I
>> >> would like to address this in 1.1.1 however I don't think we've
>> >> locked down whether that would be allowed or not.  The change would
>> >> affect TranQL and OpenEJB so they are really included components so
>> >> I'd be interested in people's feedback.
>> >>
>> >> So please accept a named RC1.  Your voting and feedback are for:
>> >>
>> >> Geronimo 1.1
>> >> DayTrader 1.1
>> >> Specs 1.1
>> >>
>> >> The vote will stand for 72 hours.  Issues raised will be discussed
>> >> and if we conclude that there is a bug that must be addressed then we
>> >> will mitigate the problem and respin a new rc for a 72 hour vote.
>> >>
>> >> If this is accepted all three of the above components will be
>> >> released simultaneously.
>> >>
>> >> Here are the builds for your review and comment:
>> >>
>> >>
>> http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.tar.gz
>> >>
>> >> http://people.apache.org/~hogstrom/rc1/geronimo-jetty-j2ee-1.1-rc1.zip
>> >>
>> http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-j2ee-1.1-rc1.tar.gz
>>
>> >>
>> >>
>> http://people.apache.org/~hogstrom/rc1/geronimo-romcat-j2ee-1.1-rc1.zip
>> >>
>> http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.tar.gz
>>
>> >>
>> >>
>> http://people.apache.org/~hogstrom/rc1/geronimo-jetty-minimal-1.1-rc1.zip
>> >>
>> >>
>> http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.tar.gz
>>
>> >>
>> >>
>> http://people.apache.org/~hogstrom/rc1/geronimo-tomcat-minimal-1.1-rc1.zip
>>
>> >>
>> >>
>> >> http://people.apache.org/~hogstrom/rc1/daytrader-ear-1.1-rc1.zip
>> >>
>> >>
>> >> Looking forward to your comments and feedback.
>> >>
>> >
>> >
>>
>>
>
>
>

[jira] Closed: (GERONIMO-2108) web app deployment fails with strange error if geronimo-web.xml defines a message-destination

2006-06-13 Thread David Jencks (JIRA)

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

Fix Version: 1.2
 Resolution: Fixed

After studying this some more I think my fix is complete.

> web app deployment fails with strange error if geronimo-web.xml defines a 
> message-destination
> -
>
>  Key: GERONIMO-2108
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2108
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1
>  Environment: geronimo 1.1-rc1 on jdk 1.4.2 on osx
> Reporter: Christoph Sturm
> Assignee: David Jencks
>  Fix For: 1.2, 1.1

>
> deploying this geronimo-web.xml: 
> 
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
>xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
>xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1";>
>
>
>   geronimo
>   wtf
>   1.1
>   war
>
>
>
>
>x
>
>
>y
>
>
> 
> results in this error message:
> org.apache.geronimo.common.DeploymentException: xml problem for web app .
>at 
> org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWebApp(TomcatModuleBuilder.java:241)
>at 
> org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModule(TomcatModuleBuilder.java:158)
>at 
> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.createModule(AbstractWebModuleBuilder.java:114)
>at 
> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClassByCGLIB$$459e0cc.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:122)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at 
> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$23aaf839.createModule()
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModule(SwitchingModuleBuilder.java:94)
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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:122)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at 
> org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$23aaf839.createModule()
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:275)
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:122)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at 
> org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$2f9800ab.getDeploymentPlan()
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232)
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
>at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at 
>

Re: [RTC] ActiveMQ GBean modules

I think that this gbean adaptation code should be in geronimo rather  
than amq.  I'm OK with applying it as is but would prefer some issues  
to be addressed first or, even better,  immediately after the  
transfer (assuming it is done with svn mv).


1. DataSourceReference should be replaced by the geronimo class that  
does the same thing, ConnectionFactorySource.


2. I think it would be preferable to get the module/configuration  
classloader in the constructor as a magic attribute and use it in  
BrokerServiceGBeanImpl.doStart rather than the classloader of  
BrokerServiceGBeanImpl.


3. Same for TransportConnectorGBeanImpl.

4. This is a question, not really an issue, about this code:
+protected TransportConnector createBrokerConnector(String url)
throws Exception {
+return brokerService.getBrokerContainer().addConnector(url);
+}

To me it seems like this code is combining the functions of factory  
object and container.  Is this necessary and appropriate?  I'd be  
more comfortable with

Connector connector = ConnectorFactory.createConnector(url);
brokerService.getBrokerContainer().addConnector(connector);

I find that the combination style typically creates problems whenever  
trying to extend stuff, say by wrapping the connector.  What do you  
think?


5. hardcoding the protocols in ActiveMQManagerGBean seems like a  
temporary expedient at best.


6. javadoc on public JMSConnector addConnector( ... in the manager  
gbean seems wrong... does not appear to return an object name.


7. Typo and innaccuracies in the first package.html... this stuff is  
only going to work in geronimo, jsr77/88 is not enough.


8. I'm not sure exactly what our official policy is but I prefer to  
remove "public" from methods in interfaces since it is the only  
choice and implied.


+1 if the above are addressed before or right after commit.  I only  
insist on (1), the others are more like suggestions.


thanks
david jencks





On Jun 5, 2006, at 4:19 PM, Hiram Chirino wrote:


Howdy folks,

Here's  a patch that brings in the activemq gbean modules into
geronimo.  It's partly what was in activemq 4.x and integrated into
geronimo 1.2-dead merged with the changes in the 3.x branch.

It compiles at least and looks like a reasonable start.  Once further
integration work gets done we may need to tweak a little more.  here's
my +1 got get this committed.  I guess I just need 3 more.


Index: modules/activemq-gbean/project.properties
===
--- modules/activemq-gbean/project.properties   (revision 0)
+++ modules/activemq-gbean/project.properties   (revision 0)
@@ -0,0 +1,3 @@
+# ---
+# Build Properties
+# ---

Property changes on: modules/activemq-gbean/project.properties
___
Name: svn:executable
  + *

Index: modules/activemq-gbean/project.xml
===
--- modules/activemq-gbean/project.xml  (revision 0)
+++ modules/activemq-gbean/project.xml  (revision 0)
@@ -0,0 +1,104 @@
+
+
+

+
+
+3
+../../etc/project.xml
+
+Geronimo :: ActiveMQ :: GBeans
+geronimo-activemq-gbean
+ActiveMQ Geronimo / GBean supportshortDescription>

+ActiveMQ GBeans used for integration into Apache
Geronimo
+
+
+
+
+
+
+  
+incubator-activemq
+activemq-core
+4.0-SNAPSHOT
+  
+
+  
+incubator-activemq
+activeio-core
+3.0-SNAPSHOT
+  
+
+  
+geronimo
+geronimo-activemq-gbean-management
+${pom.currentVersion}
+  
+
+  
+geronimo
+geronimo-kernel
+${pom.currentVersion}
+  
+
+  
+geronimo
+geronimo-system
+${pom.currentVersion}
+  
+
+  
+geronimo
+geronimo-management
+${pom.currentVersion}
+  
+
+  
+geronimo
+geronimo-j2ee
+${pom.currentVersion}
+  
+
+  
+mx4j
+mx4j
+${mx4j_version}
+  
+
+  
+commons-logging
+commons-logging
+${commons_logging_version}
+http://jakarta.apache.org/commons/logging/
+  
+
+
+
+
+
+
+${basedir}/src/main/java
+${basedir}/src/main/testunitTestSourceDirectory>

+
+
+
+**/*Test.java
+
+
+
+
+

Property changes on: modules/activemq-gbean/project.xml
___
Name: svn:executable
  + *

Index: modules/activemq-gbean/src/test/java/org/apache/activemq/ 
gbean/ConnectorTest.java

===
--- modules/activemq-gbean/src/test/java/org/apache/activemq/gbean/ 
ConnectorTest.java	(r

RE: RELEASE-NOTES-1.1

2006-06-13 Thread Lin Sun

Hi Aaron,

I am trying to learn what the in-place deployment mean and how to use it.
My understanding was that users can update the hot deploy files (for
example, update one jsp file) in the Geronimo_home\deploy directory and
server will redeploy the change automatically.   This was not working in
1.0, as users need to replace the entire directory in the
Geronimo_home\deploy directory.

But after reading your note below, I think I am lost.   Please advise.

Lin

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron
Mulder
Sent: Thursday, June 08, 2006 7:23 PM
To: dev@geronimo.apache.org
Subject: Re: RELEASE-NOTES-1.1

 - We should add a point about in-place deployment.  "Geronimo
supports in-place deployment, which means an archive or directory can
be deployed without being copied into the Geronimo directory tree."

[jira] Assigned: (GERONIMO-2113) Geronimo doesn't start if restarted using another JDK

2006-06-13 Thread David Jencks (JIRA)

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

David Jencks reassigned GERONIMO-2113:
--

Assign To: David Jencks

> Geronimo doesn't start if restarted using another JDK
> -
>
>  Key: GERONIMO-2113
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2113
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: transaction manager
> Versions: 1.1
> Reporter: Nellya Udovichenko
> Assignee: David Jencks
>  Attachments: HOWLLog.patch
>
> There is a bug in HOWL. At Geronimo launching time the file content control 
> sum is calculated by the function
> java.nio.ByteBuffer.hashCode(). Therefore, if hash code algorithms of various 
> JDKs differ Geronimo doesn't  
> start.
> The bug is repaired in howl-1.0.1 by the introducing of the new parameter 
> adler32Checksum. If the parameter 
> value is false the control sum is calculated by the function 
> java.nio.ByteBuffer.hashCode() otherwise it is calculated using  
> ADLER-32 algorithm. 
> Attached patch adds the parameter to configs/j2ee-server/src/plan/plan.xml 
> and 
> to org.apache.geronimo.transaction.log.HOWLLog gbean with default value 
> 'true'.
>  

-- 
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-2040) MagicGBall application not working in AG 1.1

2006-06-13 Thread Donald Woods (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2040?page=all ]
 
Donald Woods resolved GERONIMO-2040:


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

Fixed by David Jencks on 6/1/06

> MagicGBall application not working in AG 1.1
> 
>
>  Key: GERONIMO-2040
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2040
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: CORBA
> Versions: 1.1
>  Environment: Windows
> Reporter: Ted Kirby
> Assignee: David Jencks
> Priority: Critical
>  Fix For: 1.1

>
> See this thread in user mailing list: 
> http://mail-archives.apache.org/mod_mbox/geronimo-user/200605.mbox/[EMAIL 
> PROTECTED]

-- 
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: STOMP and JMSType

On 6/13/06, Mittler, Nathan <[EMAIL PROTECTED]> wrote:

Just to make clear what the proposed new "hard-coded" logic does:

1) If there is no content-length, it's a text message (same as before)
2) else, if there is no message type, it's a bytes message (same as
before)
3) else use amq-msg-type to determine the message type

So this logic is backward-compatible with the existing logic.  If the
client does not specify "amq-msg-type", the behavior will be the same as
it is now.

The STOMP protocol doesn't define a mapping to a JMS system, so as far
as predictability goes, the users just need to follow our logic for the
mapping.  They wouldn't be able to change the mapping, like they would
with a pluggable framework, but they shouldn't need to.  They just code
their clients against the mapping that we publish online and they'll be
up and running.

I'm getting the feeling that the main reason for leaning toward the
pluggable framework is to support a BytesMessage-only paradigm.  In a
STOMP-only world this probably makes sense.  You're just and receiving
"stuff".  But when you're bridging between Stomp and JMS, I'm not sure
why a client would ever want this restriction.  It seems like if you
want BytesMessages to come out the other end, then you just follow our
mapping logic to make that happen, which really is as simple as
including "content-length" (which you would have to include for a true
bytes message anyway) and leave off "amq-msg-type" (which you would by
default).

Even if you were to implement a pluggable framework, you would still
need to have some sort of application metadata like the "amq-msg-type"
header.  Assuming our framework is comprised of a bunch of message
transformers that go between raw bytes and ActiveMQMessages, the default
transformer for the STOMP transport would do this mapping the way I've
proposed above.  So you wouldn't be eliminating the need for the
"amq-msg-type" header, you'd just be pushing around the logic that uses
it.

So I guess I'm still not seeing the bang for the buck ... it seems like
the "hard-coded" solution works for all cases that we've defined so far.
I'd rather just get this functionality in because I think it's useful
and people have been asking for it.  I'm all for continuing to discuss
the pluggable framework, but it seems that that is a separate issue from
what I'm trying to do here (...and probably literally a separate JIRA
issue).

I agree.  But instead calling the header 'amq-msg-type' (which does
not explicitly convey that a transformation is being used), I'd like
it to be called 'activemq-transformation' set to a class name of the
transformation (or something that maps to a classname, like we do for
our service discovery).

and this would be header that is not carried with the message, it's a
header that controls the send and subscribe operations.

Regards,
Nate

-Original Message-
From: Brian McCallister [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 13, 2006 12:20 PM
To: activemq-dev@geronimo.apache.org
Subject: Re: STOMP and JMSType

On Jun 13, 2006, at 8:11 AM, Mittler, Nathan wrote:

> James,
> I think that's what we're proposing here.  I proposed "amq-msg-type",
> but I suppose "content-type" is just as good.  I think Brian's main
> concern (Brian, correct me if I'm wrong) is that he'd like the mapping
> of stomp message to AMQ message type to be pluggable, not hard-coded.

Actually, my first choice would be hard coded to bytes message,
period, finished =)

We cannot do this without breaking backwards compatibility, which I
have been presuming we don't want to do.

The most important thing, to me, when mapping from Stomp to JMS is to
have it be very predictable. I don't want to ever have someone have a
JMS client listening for stuff from Stomp and having to guess at the
message type. As such, the default should be "it is X." If they need
some other mapping, I would suggest that they look at some kind of
transformer service which republishes messages.

If we are going to have more complicated mapping, I want to either
make it super crippled: a default "compatibility mode" and a strong
recommended "5.0 mode." The next step is to make mapping pluggable,
but don't make a big deal out of it. As ben Laurie would say, a
European style API.

That is the external point of view. For the internal point of view,
the cleanest implementation I can think of is to have an interface
which takes a Send (or something like) and returns an ActiveMQMessage.

I am quite strongly against using using application level metadata
(which content-type is in Stomp and JMSType is in JMS) for mapping
information. I am also quite against every client having to specify
what to map the message to as the client should be able to be
independent of the particular implementation. I think it is a very
bad idea to require the client to add the mapping to every message.

-Brian

--
Regards,
Hiram

Re: STOMP and JMSType

The think your views are a bit STOMP point of view centric.  bytes
messages work fine when both end assume you are just moving around
bytes messages.. and it's true everything can eventually converted
down to a byte[].

If you look at it from a JMS point of view, how will a STOMP client
deal with an existing JMS network?  What if a JMS MapMessage or an
ObjectMessage is sent to a stomp client?  The question is how will
that be encoded to bytes[]..  And what if the STOMP client needs to
talk to an App that expect JMS MapMessages or ObjectMessages??

Yes I guess using a ESB style transformer in the middle would solve
the issue, but I think it adds complexity in the overall solution.  It
would be easier if the STOMP client could send a Map or Object message
directly even if it is an ActiveMQ extension that allows it to do
that.

Perhaps we add a header on send:
activemq-tranformation: org.a.a.transform.StompTextToMapMessage

And on subscribe we add another header to covert on the way in.
activemq-tranformation: org.a.a.transform.MapMessageToStompText

And if those are just class names, then the  users could implement
thier own transformation implementations and just add them to the
broker classpath.

Regards,
Hiram

On 6/13/06, Brian McCallister <[EMAIL PROTECTED]> wrote:

On Jun 13, 2006, at 8:11 AM, Mittler, Nathan wrote:

> James,
> I think that's what we're proposing here.  I proposed "amq-msg-type",
> but I suppose "content-type" is just as good.  I think Brian's main
> concern (Brian, correct me if I'm wrong) is that he'd like the mapping
> of stomp message to AMQ message type to be pluggable, not hard-coded.

Actually, my first choice would be hard coded to bytes message,
period, finished =)

We cannot do this without breaking backwards compatibility, which I
have been presuming we don't want to do.

The most important thing, to me, when mapping from Stomp to JMS is to
have it be very predictable. I don't want to ever have someone have a
JMS client listening for stuff from Stomp and having to guess at the
message type. As such, the default should be "it is X." If they need
some other mapping, I would suggest that they look at some kind of
transformer service which republishes messages.

If we are going to have more complicated mapping, I want to either
make it super crippled: a default "compatibility mode" and a strong
recommended "5.0 mode." The next step is to make mapping pluggable,
but don't make a big deal out of it. As ben Laurie would say, a
European style API.

That is the external point of view. For the internal point of view,
the cleanest implementation I can think of is to have an interface
which takes a Send (or something like) and returns an ActiveMQMessage.

I am quite strongly against using using application level metadata
(which content-type is in Stomp and JMSType is in JMS) for mapping
information. I am also quite against every client having to specify
what to map the message to as the client should be able to be
independent of the particular implementation. I think it is a very
bad idea to require the client to add the mapping to every message.

-Brian

> So if a user wanted to, they could configure the broker to turn all
> stomp messages into bytes messages, rather than using the default
> behavior of handling text and bytes messages differently.
>
> I guess I'm just not sure yet what this pluggable infrastructure
> should
> look like, as I don't think there is currently a framework in
> place.  I
> already have a build with the "hard-coded" approach that is backward
> compatible with clients that don't use the "amq-msg-type" header.  I
> guess I'll leave this as a question of what should be done:
>
> 1) submit what I've got (the hard-coded approach), once it's
> verified to
> be working.
>
> 2) step back and create a pluggable framework.
>
> Regards,
> Nate
>
>
> -Original Message-
> From: James Strachan [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 13, 2006 10:57 AM
> To: activemq-dev@geronimo.apache.org
> Subject: Re: STOMP and JMSType
>
> FWIW I'd like to have content-type header support. Couldn't we then
> use content-type as the standard header that any Stomp-JMS bridge
> would use to decide if something is a TextMessage or a BytesMessage?
>
> On 6/13/06, Nathan Mittler <[EMAIL PROTECTED]> wrote:
>> I think that clears things up for me a bit - what you're proposing
> makes
>> sense.  I'll poke around today and see what I can come up with.
>>
>> Thanks,
>> Nate
>>
>> On 6/12/06, Brian McCallister <[EMAIL PROTECTED]> wrote:
>>>
>>> On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote:
>>>
 Agreed ... using the "type" header is not an option.
>>>
>>> --- From the bug report ---
>>> It isn't possible to reuse the "type" header (JMSType) for the
>>> purpose of sending through the information as to what type of
> message
>>> it is (text or bytes).  So this means that we need to add another
>>> activemq extension header.   I propose "amq-msg-type".
>>> --- / From the bug

Re: [VOTE] Release XBean 2.4

2006-06-13 Thread Jason Dillon

+1--jasonOn Jun 13, 2006, at 1:11 AM, Guillaume Nodet wrote:I have pushed XBean 2.4 binaries in a private repo for review.They are available at    http://people.apache.org/~gnodet/xbean-2.4/m1/org.apache.xbean    http://people.apache.org/~gnodet/xbean-2.4/m2/org/apache/xbean[ ] +1 Release the binary as XBean 2.4 [ ] -1 Veto the release (provide specific comments)  If the vote passes, I will put the binaries in their official distribution repositories. Here is my +1 Cheers, Guillaume Nodet

[jira] Commented: (SM-451) HttpInvoker is losing message properties and attachments

2006-06-13 Thread Guillaume Nodet (JIRA)

[ 
https://issues.apache.org/activemq/browse/SM-451?page=comments#action_36322 ] 

Guillaume Nodet commented on SM-451:


Btw, why do you want attachments and properties to be forwarded this way ?
Imho, attachments should be sent in the http requests, and if attachments are 
send on the http response, they should be put on the out message, but this kind 
of forwarding seems strange to me..
Do you have any specific use case you could describe ?

> HttpInvoker is losing message properties and attachments
> 
>
>  Key: SM-451
>  URL: https://issues.apache.org/activemq/browse/SM-451
>  Project: ServiceMix
> Type: Bug

>   Components: servicemix-components
> Versions: 3.0
>  Environment: Java 5 - not important for this issue.
> Reporter: Mark Swanson
>  Fix For: 3.0
>  Attachments: propAndAttachment.patch
>
>
> copyPropertiesAndAttachments(exchange, in, out) is missing so the component 
> loses properties and attachments.

-- 
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: STOMP and JMSType

2006-06-13 Thread Mittler, Nathan

Just to make clear what the proposed new "hard-coded" logic does:

1) If there is no content-length, it's a text message (same as before)
2) else, if there is no message type, it's a bytes message (same as
before)
3) else use amq-msg-type to determine the message type

So this logic is backward-compatible with the existing logic.  If the
client does not specify "amq-msg-type", the behavior will be the same as
it is now.  

The STOMP protocol doesn't define a mapping to a JMS system, so as far
as predictability goes, the users just need to follow our logic for the
mapping.  They wouldn't be able to change the mapping, like they would
with a pluggable framework, but they shouldn't need to.  They just code
their clients against the mapping that we publish online and they'll be
up and running.  

I'm getting the feeling that the main reason for leaning toward the
pluggable framework is to support a BytesMessage-only paradigm.  In a
STOMP-only world this probably makes sense.  You're just and receiving
"stuff".  But when you're bridging between Stomp and JMS, I'm not sure
why a client would ever want this restriction.  It seems like if you
want BytesMessages to come out the other end, then you just follow our
mapping logic to make that happen, which really is as simple as
including "content-length" (which you would have to include for a true
bytes message anyway) and leave off "amq-msg-type" (which you would by
default).  

Even if you were to implement a pluggable framework, you would still
need to have some sort of application metadata like the "amq-msg-type"
header.  Assuming our framework is comprised of a bunch of message
transformers that go between raw bytes and ActiveMQMessages, the default
transformer for the STOMP transport would do this mapping the way I've
proposed above.  So you wouldn't be eliminating the need for the
"amq-msg-type" header, you'd just be pushing around the logic that uses
it.

So I guess I'm still not seeing the bang for the buck ... it seems like
the "hard-coded" solution works for all cases that we've defined so far.
I'd rather just get this functionality in because I think it's useful
and people have been asking for it.  I'm all for continuing to discuss
the pluggable framework, but it seems that that is a separate issue from
what I'm trying to do here (...and probably literally a separate JIRA
issue).

Regards,
Nate

-Original Message-
From: Brian McCallister [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 13, 2006 12:20 PM
To: activemq-dev@geronimo.apache.org
Subject: Re: STOMP and JMSType

On Jun 13, 2006, at 8:11 AM, Mittler, Nathan wrote:

> James,
> I think that's what we're proposing here.  I proposed "amq-msg-type",
> but I suppose "content-type" is just as good.  I think Brian's main
> concern (Brian, correct me if I'm wrong) is that he'd like the mapping
> of stomp message to AMQ message type to be pluggable, not hard-coded.

Actually, my first choice would be hard coded to bytes message,  
period, finished =)

We cannot do this without breaking backwards compatibility, which I  
have been presuming we don't want to do.

The most important thing, to me, when mapping from Stomp to JMS is to  
have it be very predictable. I don't want to ever have someone have a  
JMS client listening for stuff from Stomp and having to guess at the  
message type. As such, the default should be "it is X." If they need  
some other mapping, I would suggest that they look at some kind of  
transformer service which republishes messages.

If we are going to have more complicated mapping, I want to either  
make it super crippled: a default "compatibility mode" and a strong  
recommended "5.0 mode." The next step is to make mapping pluggable,  
but don't make a big deal out of it. As ben Laurie would say, a  
European style API.

That is the external point of view. For the internal point of view,  
the cleanest implementation I can think of is to have an interface  
which takes a Send (or something like) and returns an ActiveMQMessage.

I am quite strongly against using using application level metadata  
(which content-type is in Stomp and JMSType is in JMS) for mapping  
information. I am also quite against every client having to specify  
what to map the message to as the client should be able to be  
independent of the particular implementation. I think it is a very  
bad idea to require the client to add the mapping to every message.

-Brian

Re: rc1 Status and Next Steps

2006-06-13 Thread Mario Rübsam


Matt Hogstrom wrote:


4. Remaining JIRA Issues
*Needs to be investigated*  _Paul or Aaron_ can you examine this issue 
and recommend a fix?

GERONIMO-2093Console database pool always gets NPE on deploy


The NPE appeared in 1.1-20060607.
The problem is fixed in 1.1-rc1. No more NPE while displaying or saving 
deployment plan.


Thanks,
Mario

[jira] Created: (SM-451) HttpInvoker is losing message properties and attachments

2006-06-13 Thread Mark Swanson (JIRA)

HttpInvoker is losing message properties and attachments


 Key: SM-451
 URL: https://issues.apache.org/activemq/browse/SM-451
 Project: ServiceMix
Type: Bug

  Components: servicemix-components  
Versions: 3.0
 Environment: Java 5 - not important for this issue.
Reporter: Mark Swanson
 Fix For: 3.0
 Attachments: propAndAttachment.patch

copyPropertiesAndAttachments(exchange, in, out) is missing so the component 
loses properties and attachments.


-- 
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: rc1 Status and Next Steps

2006-06-13 Thread Dave Colasurdo


John Sisson wrote:

6. Third Party Licenses.  This needs to be reviewed and the 
appropriate licenses compiled. Volunteers?  We did not have one in the 
1.0 stream so I'd like clarification if this is a requirement or 
something that can be deferred.
IMO this is a requirement.  Just have a look at some of the licenses for 
components we are redistributing.


I have collated a list of components attached to a file in 
http://issues.apache.org/jira/browse/GERONIMO-2112 indicating whether 
IMHO they require an attribution in the NOTICES.txt file or a license 
included in the LICENSE.txt file and where to get the information from.
There are some that require further investigation as IMNAL.  Can people 
please look at the file attached to GERONIMO-2112 and see if there are 
any obvious omissions/errors and comment on the items requiring further 
investigation.


If someone has time to pick it up from and start assembling the 
LICENSE.txt and NOTICE.txt files, please do, otherwise I'll continue in 
the morning (Sydney time).




John,
I am also investigating.  I suspect jdom and castor may also need to be 
added to the list..  Will make an initial pass at the files and attach 
them to GERONIMO-2112.. Of course IANAL.. :)


Thanks
-Dave-

Re: STOMP and JMSType

2006-06-13 Thread James Strachan

BTW I confess to skim reading this thread a little so appologies if I
missed some subtleties along the way :)

So I guess there's 2 things.

(i) Whats the default mapping of stomp content-type <-> JMS Message
that most stomp-jms providers should support by default.

(ii) Allowing folks to customize the mapping of Stomp headers -> JMS Messages.

I'm all for both; I wanna nail down (i) and implement it ASAP. Option
(ii) we can tinker with over time as its probably gonna be a pluggable
strategy we can tweak over time.

e.g. I can imagine use cases where when we see "application/xml" or
"text/xml" or "application/soap" or whatnot to using something like
JAXB/SDO to make an ObjectMessage containing the marshalled body.

On 6/13/06, Mittler, Nathan <[EMAIL PROTECTED]> wrote:

James,
I think that's what we're proposing here.  I proposed "amq-msg-type",
but I suppose "content-type" is just as good.  I think Brian's main
concern (Brian, correct me if I'm wrong) is that he'd like the mapping
of stomp message to AMQ message type to be pluggable, not hard-coded.
So if a user wanted to, they could configure the broker to turn all
stomp messages into bytes messages, rather than using the default
behavior of handling text and bytes messages differently.

I guess I'm just not sure yet what this pluggable infrastructure should
look like, as I don't think there is currently a framework in place.  I
already have a build with the "hard-coded" approach that is backward
compatible with clients that don't use the "amq-msg-type" header.  I
guess I'll leave this as a question of what should be done:

1) submit what I've got (the hard-coded approach), once it's verified to
be working.

2) step back and create a pluggable framework.

Regards,
Nate

-Original Message-
From: James Strachan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 13, 2006 10:57 AM
To: activemq-dev@geronimo.apache.org
Subject: Re: STOMP and JMSType

FWIW I'd like to have content-type header support. Couldn't we then
use content-type as the standard header that any Stomp-JMS bridge
would use to decide if something is a TextMessage or a BytesMessage?

On 6/13/06, Nathan Mittler <[EMAIL PROTECTED]> wrote:
> I think that clears things up for me a bit - what you're proposing
makes
> sense.  I'll poke around today and see what I can come up with.
>
> Thanks,
> Nate
>
> On 6/12/06, Brian McCallister <[EMAIL PROTECTED]> wrote:
> >
> > On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote:
> >
> > > Agreed ... using the "type" header is not an option.
> >
> > --- From the bug report ---
> > It isn't possible to reuse the "type" header (JMSType) for the
> > purpose of sending through the information as to what type of
message
> > it is (text or bytes).  So this means that we need to add another
> > activemq extension header.   I propose "amq-msg-type".
> > --- / From the bug report --
> >
> > I like this a lot better, and think it would be a reasonable default
> > rule for mapping in 4.X.
> >
> > >> I am not convinced we need this, but I much prefer it to a
hardcoded
> > >> transform, as this would allow for much more useful transforms
(ie,
> > >> aplication-aware).
> > >
> > >
> > > Although I agree conceptually, I'm thinking this might be a bit of
an
> > > overkill for the task at hand.
> >
> > Agreed. I just hate to layer on another backwards compatibility
issue
> > beyond what we already have. By designing it to be forward
compatible
> > with an arbitrary mapping we can grow into a future solution more
> > easily. Once we add this header we will need to support it ~forever.
> >
> > > Right now the STOMP transport only works
> > > with bytes and text messages, and creating this transform model
> > > won't change
> > > that.  I think if we one day decide to refactor the transport to
> > > accept
> > > other message types - that would be the time to make this sort of
> > > change.
> >
> > What if I want to switch on "Content-type" to decide between text or
> > bytes? It is a common header to use, but is not part of the spec (as
> > stomp doesn;t care, but is happy to pass it along). This makes more
> > sense to me in terms of mapping between Stomp and JMS, but it is not
> > compatible with switching on a specific content header.
> >
> > The mapping between Stomp and JMS is actually rather important to
get
> > right as it is the low level interop mapping between various
> > platforms and Java. As such, I want to make sure we are building
> > towards a correct solution.
> >
> > Aside from all this, controlling the protocol <--> (semi-)protocol
> > mapping should be a configuration thing, not a flag the client must
> > put on every message it sends.
> >
> > The end goal for me is to have all messages coming in from the Stomp
> > adaptor be bytes messages, unless someone has an overriding need for
> > something else (quote possible). The current behavior is pretty bad
> > as a default, but we just released 4.0 with it, so we are stuck
until
> > we make another backwards

Re: [VOTE] Release XBean 2.4

2006-06-13 Thread Davanum Srinivas


Not sure if i did it already.. here's my +1.

On 6/13/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:

+1

On 6/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> I have pushed XBean 2.4 binaries in a private repo for review.
> They are available at
>
> http://people.apache.org/~gnodet/xbean-2.4/m1/org.apache.xbean
>
> http://people.apache.org/~gnodet/xbean-2.4/m2/org/apache/xbean
>
> [ ] +1 Release the binary as XBean 2.4
> [ ] -1 Veto the release (provide specific comments)
>
> If the vote passes, I will put the binaries in their official distribution
> repositories.
>
> Here is my +1
>
> Cheers,
> Guillaume Nodet
>
>
>


--
Regards,
Hiram




--
Davanum Srinivas : http://wso2.com/blogs/

Re: [VOTE] Release XBean 2.4


+1

On 6/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:

I have pushed XBean 2.4 binaries in a private repo for review.
They are available at

http://people.apache.org/~gnodet/xbean-2.4/m1/org.apache.xbean

http://people.apache.org/~gnodet/xbean-2.4/m2/org/apache/xbean

[ ] +1 Release the binary as XBean 2.4
[ ] -1 Veto the release (provide specific comments)

If the vote passes, I will put the binaries in their official distribution
repositories.

Here is my +1

Cheers,
Guillaume Nodet






--
Regards,
Hiram

[jira] Updated: (GERONIMO-2113) Geronimo doesn't start if restarted using another JDK

2006-06-13 Thread Nellya Udovichenko (JIRA)

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

Nellya Udovichenko updated GERONIMO-2113:
-

Attachment: HOWLLog.patch

> Geronimo doesn't start if restarted using another JDK
> -
>
>  Key: GERONIMO-2113
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2113
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: transaction manager
> Versions: 1.1
> Reporter: Nellya Udovichenko
>  Attachments: HOWLLog.patch
>
> There is a bug in HOWL. At Geronimo launching time the file content control 
> sum is calculated by the function
> java.nio.ByteBuffer.hashCode(). Therefore, if hash code algorithms of various 
> JDKs differ Geronimo doesn't  
> start.
> The bug is repaired in howl-1.0.1 by the introducing of the new parameter 
> adler32Checksum. If the parameter 
> value is false the control sum is calculated by the function 
> java.nio.ByteBuffer.hashCode() otherwise it is calculated using  
> ADLER-32 algorithm. 
> Attached patch adds the parameter to configs/j2ee-server/src/plan/plan.xml 
> and 
> to org.apache.geronimo.transaction.log.HOWLLog gbean with default value 
> 'true'.
>  

-- 
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-2113) Geronimo doesn't start if restarted using another JDK

2006-06-13 Thread Nellya Udovichenko (JIRA)

Geronimo doesn't start if restarted using another JDK
-

 Key: GERONIMO-2113
 URL: http://issues.apache.org/jira/browse/GERONIMO-2113
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: transaction manager  
Versions: 1.1
Reporter: Nellya Udovichenko
 Attachments: HOWLLog.patch

There is a bug in HOWL. At Geronimo launching time the file content control sum 
is calculated by the function
java.nio.ByteBuffer.hashCode(). Therefore, if hash code algorithms of various 
JDKs differ Geronimo doesn't  
start.

The bug is repaired in howl-1.0.1 by the introducing of the new parameter 
adler32Checksum. If the parameter 
value is false the control sum is calculated by the function 
java.nio.ByteBuffer.hashCode() otherwise it is calculated using  
ADLER-32 algorithm. 

Attached patch adds the parameter to configs/j2ee-server/src/plan/plan.xml and 
to org.apache.geronimo.transaction.log.HOWLLog gbean with default value 'true'.

 



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

Re: [VOTE] Release XBean 2.4

2006-06-13 Thread James Strachan


Cool, thanks Ian!

On 6/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Hi James,

I'm not sure if this is what you're after or not, but you can include
source and javadoc jars when you prepare your upload bundle (assuming XBean
is built using M2 and that you are deploying the resulting artifacts to
iBiblio) with the following command:

  mvn source:jar javadoc:jar repository:bundle-create

See http://maven.apache.org/guides/mini/guide-ibiblio-upload.html for
details.


HTH,
Ian

It's better to be hated for who you are
than loved for who you are not

Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078



 "James Strachan"
 <[EMAIL PROTECTED]
 mail.com>  To
   dev@geronimo.apache.org
 06/13/2006 04:18   cc
 AM
   Subject
   Re: [VOTE] Release XBean 2.4
 Please respond to
 [EMAIL PROTECTED]
  he.org







+1.

I didn't see a binary tarball of an entire assembly; at some point we
might wanna make an xbean.zip with all the jars and javadocs inside or
something; but for now I think most users just use the jars directly
in maven anyway :)


On 6/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> I have pushed XBean 2.4 binaries in a private repo for review.
> They are available at
>
> http://people.apache.org/~gnodet/xbean-2.4/m1/org.apache.xbean
>
> http://people.apache.org/~gnodet/xbean-2.4/m2/org/apache/xbean
>
> [ ] +1 Release the binary as XBean 2.4
> [ ] -1 Veto the release (provide specific comments)
>
> If the vote passes, I will put the binaries in their official
distribution
> repositories.
>
> Here is my +1
>
> Cheers,
> Guillaume Nodet
>
>
>


--

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






--

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

[jira] Updated: (GERONIMO-1945) Console's web application list does not show WARs that are deployed inside EARs

2006-06-13 Thread Erin Mulder (JIRA)

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

Erin Mulder updated GERONIMO-1945:
--

Assign To: (was: Erin Mulder)

> Console's web application list does not show WARs that are deployed inside 
> EARs
> ---
>
>  Key: GERONIMO-1945
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1945
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.0
> Reporter: Erin Mulder
>  Fix For: 1.2

>
> In the console, click on "Applications -> Web App WARs".   The resulting list 
> of web applications does not include any web application that is packaged as 
> part of an EAR.
> (The list is populated inside ConfigManagerPortlet.doView)

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

Re: [VOTE] Release XBean 2.4

2006-06-13 Thread ian . d . stewart

Hi James,

I'm not sure if this is what you're after or not, but you can include
source and javadoc jars when you prepare your upload bundle (assuming XBean
is built using M2 and that you are deploying the resulting artifacts to
iBiblio) with the following command:

  mvn source:jar javadoc:jar repository:bundle-create

See http://maven.apache.org/guides/mini/guide-ibiblio-upload.html for
details.


HTH,
Ian

It's better to be hated for who you are
than loved for who you are not

Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078


   
 "James Strachan"  
 <[EMAIL PROTECTED] 
 mail.com>  To 
   dev@geronimo.apache.org 
 06/13/2006 04:18   cc 
 AM
   Subject 
   Re: [VOTE] Release XBean 2.4
 Please respond to 
 [EMAIL PROTECTED] 
  he.org   
   
   
   




+1.

I didn't see a binary tarball of an entire assembly; at some point we
might wanna make an xbean.zip with all the jars and javadocs inside or
something; but for now I think most users just use the jars directly
in maven anyway :)


On 6/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> I have pushed XBean 2.4 binaries in a private repo for review.
> They are available at
>
> http://people.apache.org/~gnodet/xbean-2.4/m1/org.apache.xbean
>
> http://people.apache.org/~gnodet/xbean-2.4/m2/org/apache/xbean
>
> [ ] +1 Release the binary as XBean 2.4
> [ ] -1 Veto the release (provide specific comments)
>
> If the vote passes, I will put the binaries in their official
distribution
> repositories.
>
> Here is my +1
>
> Cheers,
> Guillaume Nodet
>
>
>


--

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

Re: Eclipse Plugin V1.1.0 unstable driver now available

Ah found the problem, the bundle manifest was missing a "." entry for  
bundle-classpath.  I'm uploading a new driver right now.


On Jun 13, 2006, at 9:07 AM, Sachin Patel wrote:

Ok, my bad, you're right, the distribution is in fact bad.  I'll  
remove it so other people don't report the same problem.  Not sure  
what is wrong since everything works when self hosting... I'll dig  
into it..


thanks.


On Jun 13, 2006, at 8:38 AM, Sachin Patel wrote:

The 1.1 support should work.  I gave a demo on it at the Rational  
Conference last week.  But of course I was launching from within a  
self-hosted environment, so let me double check the actual  
distribution this morning.  In the meantime, could you try as well  
installing over a clean WTP image, rather then overlaying, it  
could be there was an issue with doing that.


So let me verify the image right now, and I'll get let u know.

On Jun 12, 2006, at 11:38 PM, Neal Sanche wrote:

You mention, here, that there is a driver available that we can  
test with, is that the one released on June 6th? I am still  
finding it impossible to get that version to start up an deploy  
to a Geronimo 1.1 server. It does nearly everything else  
wonderfully. I've been forced to Export .EAR files to the  
Geronimo 1.1 /deploy directory to test my application. Is there  
anything we can do to get something that at least deploys before  
you get the EMF team to fix a bug in 1.5? I'm perfectly happy  
using 1.0.2 WTP since I tried 1.5 WTP and found that the CMP EJB  
creation is not finished yet. So, since it's the only reason I'd  
consider moving on, I don't see why the Geronimo Eclipse plugin  
should need to yet either.


I haven't seen any movement in the Devtools SVN repository  
either, so if there's a 1.0.2 working version, I don't see it. Am  
I looking in the wrong place?


Thanks Sachin!

Cheers.

-Neal

Sachin Patel wrote:
They are going fine. The driver that is available should be a  
good driver to start testing on.  I've been working on moving up  
to WTP 1.5, EMF 2.2, etc... and have run across a build breaking  
EMF bug I'm awaiting a fix for.  Hopefully we'll get the fix  
before EMF 2.2 is released.


On Jun 12, 2006, at 6:43 PM, Jay D. McHugh wrote:


How are the Eclipse plugin changes going?

Jay

Sachin Patel wrote:
Hold off on the V11 testing, as I'm finding issues you may run  
into. I'm working on resolving the issues this morning and  
will let u know when I'm done.


On Jun 7, 2006, at 12:02 AM, Neal Sanche wrote:


Okay Sachin,

I have found what I believe to be the main problem. I looked  
in my Eclipse configuration settings, and found that the  
Geronimo plugin had a little red X on it indicating it was  
unhappy. So I looked into why that could be ant found a small  
complaint it was making:


Plug-in "org.apache.geronimo.st.v11.ui" version "1.0.0"  
referenced by this feature is missing.


I looked all over and sure enough I do not have a copy of  
this Jarfile anywhere in my Eclipse directory. Where would I  
find such a thing? I'm not brave enough to try this build  
myself at the moment otherwise I would try and make my own  
version of this. I will see if maybe one of the distributions  
you posted has it.


-Neal

Sachin Patel wrote:
I just posted a new driver. Could you verify that the  
problem is fixed?


You should be able to just extract over your existing image.  
Be sure to re-invoke eclipse with "-clean".


Thanks.

On Jun 6, 2006, at 9:53 PM, Neal Sanche wrote:


Fair enough,

I have put in a JIRA, let me know (though the JIRA) what  
else you need from me. I am trying out the other features  
and will see if I get stuck. I can't start the server from  
inside Eclipse, but maybe I can still develop a small  
application.


-Neal

Sachin Patel wrote:
I'd have to dig into it, I'm not quite sure looking at  
just the stack trace.


On Jun 6, 2006, at 9:32 PM, Neal Sanche wrote:

I will put in a JIRA, for sure. Can you tell me what  
might be going on?


-Neal

Sachin Patel wrote:

Ah shoot, can you open a jira? I can investigate.

On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or 1.5.  
It should be run with WTP 1.0x and will eventually but  
not currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/ 
unstable/g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip


-sachin


Hi Sachin,

I am currently trying to get Eclipse 1.0.2 All In One  
bundle to run your new eclipse plugin with the  
following result. I have installed the plugin, and set  
up a Geronimo 1.1 server that I compiled myself about a  
week ago. I am going to try a recompile in the  
meantime, but what do you think the following means?


Thanks.

-Neal


!ENTRY org.eclipse.osgi 2006-06-05 21:44:07.125
!MESSAGE An error occurred while automatically  
activating bundle org.apache.geronimo.st.jmxagent (14).

!STACK 0
org.osgi.framework.BundleException: The activator  
org.apache.geronim

Re: Eclipse Plugin V1.1.0 unstable driver now available

Ok, my bad, you're right, the distribution is in fact bad.  I'll  
remove it so other people don't report the same problem.  Not sure  
what is wrong since everything works when self hosting... I'll dig  
into it..


thanks.


On Jun 13, 2006, at 8:38 AM, Sachin Patel wrote:

The 1.1 support should work.  I gave a demo on it at the Rational  
Conference last week.  But of course I was launching from within a  
self-hosted environment, so let me double check the actual  
distribution this morning.  In the meantime, could you try as well  
installing over a clean WTP image, rather then overlaying, it could  
be there was an issue with doing that.


So let me verify the image right now, and I'll get let u know.

On Jun 12, 2006, at 11:38 PM, Neal Sanche wrote:

You mention, here, that there is a driver available that we can  
test with, is that the one released on June 6th? I am still  
finding it impossible to get that version to start up an deploy to  
a Geronimo 1.1 server. It does nearly everything else wonderfully.  
I've been forced to Export .EAR files to the Geronimo 1.1 /deploy  
directory to test my application. Is there anything we can do to  
get something that at least deploys before you get the EMF team to  
fix a bug in 1.5? I'm perfectly happy using 1.0.2 WTP since I  
tried 1.5 WTP and found that the CMP EJB creation is not finished  
yet. So, since it's the only reason I'd consider moving on, I  
don't see why the Geronimo Eclipse plugin should need to yet either.


I haven't seen any movement in the Devtools SVN repository either,  
so if there's a 1.0.2 working version, I don't see it. Am I  
looking in the wrong place?


Thanks Sachin!

Cheers.

-Neal

Sachin Patel wrote:
They are going fine. The driver that is available should be a  
good driver to start testing on.  I've been working on moving up  
to WTP 1.5, EMF 2.2, etc... and have run across a build breaking  
EMF bug I'm awaiting a fix for.  Hopefully we'll get the fix  
before EMF 2.2 is released.


On Jun 12, 2006, at 6:43 PM, Jay D. McHugh wrote:


How are the Eclipse plugin changes going?

Jay

Sachin Patel wrote:
Hold off on the V11 testing, as I'm finding issues you may run  
into. I'm working on resolving the issues this morning and will  
let u know when I'm done.


On Jun 7, 2006, at 12:02 AM, Neal Sanche wrote:


Okay Sachin,

I have found what I believe to be the main problem. I looked  
in my Eclipse configuration settings, and found that the  
Geronimo plugin had a little red X on it indicating it was  
unhappy. So I looked into why that could be ant found a small  
complaint it was making:


Plug-in "org.apache.geronimo.st.v11.ui" version "1.0.0"  
referenced by this feature is missing.


I looked all over and sure enough I do not have a copy of this  
Jarfile anywhere in my Eclipse directory. Where would I find  
such a thing? I'm not brave enough to try this build myself at  
the moment otherwise I would try and make my own version of  
this. I will see if maybe one of the distributions you posted  
has it.


-Neal

Sachin Patel wrote:
I just posted a new driver. Could you verify that the problem  
is fixed?


You should be able to just extract over your existing image.  
Be sure to re-invoke eclipse with "-clean".


Thanks.

On Jun 6, 2006, at 9:53 PM, Neal Sanche wrote:


Fair enough,

I have put in a JIRA, let me know (though the JIRA) what  
else you need from me. I am trying out the other features  
and will see if I get stuck. I can't start the server from  
inside Eclipse, but maybe I can still develop a small  
application.


-Neal

Sachin Patel wrote:
I'd have to dig into it, I'm not quite sure looking at just  
the stack trace.


On Jun 6, 2006, at 9:32 PM, Neal Sanche wrote:

I will put in a JIRA, for sure. Can you tell me what might  
be going on?


-Neal

Sachin Patel wrote:

Ah shoot, can you open a jira? I can investigate.

On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or 1.5. It  
should be run with WTP 1.0x and will eventually but not  
currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/unstable/ 
g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip


-sachin


Hi Sachin,

I am currently trying to get Eclipse 1.0.2 All In One  
bundle to run your new eclipse plugin with the following  
result. I have installed the plugin, and set up a  
Geronimo 1.1 server that I compiled myself about a week  
ago. I am going to try a recompile in the meantime, but  
what do you think the following means?


Thanks.

-Neal


!ENTRY org.eclipse.osgi 2006-06-05 21:44:07.125
!MESSAGE An error occurred while automatically  
activating bundle org.apache.geronimo.st.jmxagent (14).

!STACK 0
org.osgi.framework.BundleException: The activator  
org.apache.geronimo.st.jmxagent.Activator for bundle  
org.apache.geronimo.st.jmxagent is invalid
at  
org.eclipse.osgi.framework.internal.core.AbstractBundle.loa 
dBundleActivator(AbstractBundle.java:

Re: rc1 Status and Next Steps


Matt Hogstrom wrote:

All,

Good feedback on the release and each successive build we have less 
issues.


Based on the feedback from people I have taken the following actions:

1. Updated the builds (both 1.1 and trunk) to include the LICENSE.txt 
file for the server.


2. Modified and tested the Tomcat configuration in both branches/1.1 
and trunk to enable logging. There was an inconsistency between Jetty 
and Tomcat WRT to access logging; in Jetty it was enabled and in 
Tomcat it was not.  I have changed both to be enabled as I am unaware 
of any testing on Jetty to disable access logging.


3. An error in viewing access logs from the console.   This is a bug 
that needs to be addressed but is mitigated by number 2 above.


4. Remaining JIRA Issues
*Needs to be investigated*  _Paul or Aaron_ can you examine this issue 
and recommend a fix?

GERONIMO-2093Console database pool always gets NPE on deploy

*I believe these are completed...need review* _Assignees include 
DJencks, AMMulder, JGenender, Dain_

GERONIMO-1924Need to register the tomcat jndi url handler somehow
GERONIMO-1865Add ability to restart and reload configurations
GERONIMO-1874synthetic ears should allow use of modules outside 
the g repository
GERONIMO-1781FileSystemRepository not able to handle entry with 
version number which is a single digit


*Need Status*  _I believe this will be deferred.  Hiram will need to 
comment_
GERONIMO-1451A new TCP listener for ActiveMQ is not persisting 
across server startups


5. We are waiting for the remaining ActiveMQ SNAPSHOT (3.2.4) to be 
released.  Hiram indicted he would look after this today.


6. Third Party Licenses.  This needs to be reviewed and the 
appropriate licenses compiled. Volunteers?  We did not have one in the 
1.0 stream so I'd like clarification if this is a requirement or 
something that can be deferred.
IMO this is a requirement.  Just have a look at some of the licenses for 
components we are redistributing.


I have collated a list of components attached to a file in 
http://issues.apache.org/jira/browse/GERONIMO-2112 indicating whether 
IMHO they require an attribution in the NOTICES.txt file or a license 
included in the LICENSE.txt file and where to get the information from. 

There are some that require further investigation as IMNAL.  Can people 
please look at the file attached to GERONIMO-2112 and see if there are 
any obvious omissions/errors and comment on the items requiring further 
investigation.


If someone has time to pick it up from and start assembling the 
LICENSE.txt and NOTICE.txt files, please do, otherwise I'll continue in 
the morning (Sydney time).


Regards,

John



I will be travelling today so I will address these issues tonight and 
cut a final RC tonight assuming all the above issues are resolved.


I have moved 49 JIRAs into 1.1.1 that I plan to address and respin a 
1.1.1 within 3 weeks.  Schedule to be determined.


Thanks for everyone's help and feedback.  I believe once we have 
addressed the above we are good to go for 1.1.  It's been a long road 
to get here.  Only a few more inches and we're in the end zone.


Matt

[jira] Updated: (GERONIMO-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file

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

John Sisson updated GERONIMO-2112:
--

Attachment: geronimo-1.1-RC-licenses-attributions-draft1.txt

> Place required attrtibutions in the NOTICES.txt file or a license included in 
> the LICENSE.txt file
> --
>
>  Key: GERONIMO-2112
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2112
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>   Components: documentation
> Versions: 1.1
> Reporter: John Sisson
> Priority: Blocker
>  Fix For: 1.1
>  Attachments: geronimo-1.1-RC-licenses-attributions-draft1.txt
>
> I have collated a list of components in the attached file indicating whether 
> IMHO they require an attribution in the NOTICES.txt file or a license 
> included in the LICENSE.txt file.  
> See http://www.apache.org/dev/apply-license.html#new for information on 
> license files.
> See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example 
> of a LICENSE file containing other licenses.

-- 
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-2112) Place required attrtibutions in the NOTICES.txt file or a license included in the LICENSE.txt file

Place required attrtibutions in the NOTICES.txt file or a license included in 
the LICENSE.txt file
--

 Key: GERONIMO-2112
 URL: http://issues.apache.org/jira/browse/GERONIMO-2112
 Project: Geronimo
Type: Task
Security: public (Regular issues) 
  Components: documentation  
Versions: 1.1
Reporter: John Sisson
Priority: Blocker
 Fix For: 1.1


I have collated a list of components in the attached file indicating whether 
IMHO they require an attribution in the NOTICES.txt file or a license included 
in the LICENSE.txt file.  

See http://www.apache.org/dev/apply-license.html#new for information on license 
files.
See http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE for an example of 
a LICENSE file containing other licenses.


-- 
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: Eclipse Plugin V1.1.0 unstable driver now available

The 1.1 support should work.  I gave a demo on it at the Rational  
Conference last week.  But of course I was launching from within a  
self-hosted environment, so let me double check the actual  
distribution this morning.  In the meantime, could you try as well  
installing over a clean WTP image, rather then overlaying, it could  
be there was an issue with doing that.


So let me verify the image right now, and I'll get let u know.

On Jun 12, 2006, at 11:38 PM, Neal Sanche wrote:

You mention, here, that there is a driver available that we can  
test with, is that the one released on June 6th? I am still finding  
it impossible to get that version to start up an deploy to a  
Geronimo 1.1 server. It does nearly everything else wonderfully.  
I've been forced to Export .EAR files to the Geronimo 1.1 /deploy  
directory to test my application. Is there anything we can do to  
get something that at least deploys before you get the EMF team to  
fix a bug in 1.5? I'm perfectly happy using 1.0.2 WTP since I tried  
1.5 WTP and found that the CMP EJB creation is not finished yet.  
So, since it's the only reason I'd consider moving on, I don't see  
why the Geronimo Eclipse plugin should need to yet either.


I haven't seen any movement in the Devtools SVN repository either,  
so if there's a 1.0.2 working version, I don't see it. Am I looking  
in the wrong place?


Thanks Sachin!

Cheers.

-Neal

Sachin Patel wrote:
They are going fine. The driver that is available should be a good  
driver to start testing on.  I've been working on moving up to WTP  
1.5, EMF 2.2, etc... and have run across a build breaking EMF bug  
I'm awaiting a fix for.  Hopefully we'll get the fix before EMF  
2.2 is released.


On Jun 12, 2006, at 6:43 PM, Jay D. McHugh wrote:


How are the Eclipse plugin changes going?

Jay

Sachin Patel wrote:
Hold off on the V11 testing, as I'm finding issues you may run  
into. I'm working on resolving the issues this morning and will  
let u know when I'm done.


On Jun 7, 2006, at 12:02 AM, Neal Sanche wrote:


Okay Sachin,

I have found what I believe to be the main problem. I looked in  
my Eclipse configuration settings, and found that the Geronimo  
plugin had a little red X on it indicating it was unhappy. So I  
looked into why that could be ant found a small complaint it  
was making:


Plug-in "org.apache.geronimo.st.v11.ui" version "1.0.0"  
referenced by this feature is missing.


I looked all over and sure enough I do not have a copy of this  
Jarfile anywhere in my Eclipse directory. Where would I find  
such a thing? I'm not brave enough to try this build myself at  
the moment otherwise I would try and make my own version of  
this. I will see if maybe one of the distributions you posted  
has it.


-Neal

Sachin Patel wrote:
I just posted a new driver. Could you verify that the problem  
is fixed?


You should be able to just extract over your existing image.  
Be sure to re-invoke eclipse with "-clean".


Thanks.

On Jun 6, 2006, at 9:53 PM, Neal Sanche wrote:


Fair enough,

I have put in a JIRA, let me know (though the JIRA) what else  
you need from me. I am trying out the other features and will  
see if I get stuck. I can't start the server from inside  
Eclipse, but maybe I can still develop a small application.


-Neal

Sachin Patel wrote:
I'd have to dig into it, I'm not quite sure looking at just  
the stack trace.


On Jun 6, 2006, at 9:32 PM, Neal Sanche wrote:

I will put in a JIRA, for sure. Can you tell me what might  
be going on?


-Neal

Sachin Patel wrote:

Ah shoot, can you open a jira? I can investigate.

On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or 1.5. It  
should be run with WTP 1.0x and will eventually but not  
currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/unstable/ 
g-eclipse-plugin-1.1-SNAPSHOT-deployable.zip


-sachin


Hi Sachin,

I am currently trying to get Eclipse 1.0.2 All In One  
bundle to run your new eclipse plugin with the following  
result. I have installed the plugin, and set up a  
Geronimo 1.1 server that I compiled myself about a week  
ago. I am going to try a recompile in the meantime, but  
what do you think the following means?


Thanks.

-Neal


!ENTRY org.eclipse.osgi 2006-06-05 21:44:07.125
!MESSAGE An error occurred while automatically activating  
bundle org.apache.geronimo.st.jmxagent (14).

!STACK 0
org.osgi.framework.BundleException: The activator  
org.apache.geronimo.st.jmxagent.Activator for bundle  
org.apache.geronimo.st.jmxagent is invalid
at  
org.eclipse.osgi.framework.internal.core.AbstractBundle.load 
BundleActivator(AbstractBundle.java:149)
at  
org.eclipse.osgi.framework.internal.core.BundleContextImpl.s 
tart(BundleContextImpl.java:965)
at  
org.eclipse.osgi.framework.internal.core.BundleHost.startWor 
ker(BundleHost.java:316)
at  
org.eclipse.osgi.framework.internal.core.AbstractBundle.star 
t(AbstractBundl

[jira] Updated: (GERONIMO-1865) Add ability to restart and reload configurations

2006-06-13 Thread Aaron Mulder (JIRA)

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

Aaron Mulder updated GERONIMO-1865:
---

Fix Version: 1.1.1
 (was: 1.1)

We need to provide a restart link in the console and through the command-line 
tool.

> Add ability to restart and reload configurations
> 
>
>  Key: GERONIMO-1865
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1865
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: kernel, console
> Versions: 1.1
> Reporter: Dain Sundstrom
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1

>
> Add the ability to restart and reload configurations.  The core feature has 
> been added to the ConfigurationManager, and now we just need to expose it via 
> the CLI and web 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: Key Generator Questions

2006-06-13 Thread Aaron Mulder


There's some documentation on key generators here:

http://chariotsolutions.com/geronimo/ejb-structure.html#ejb-structure-entity-cmp-pkgen

It could probably use some examples, though.  :)

Thanks,
   Aaron

On 6/12/06, Neal Sanche <[EMAIL PROTECTED]> wrote:

Hi All,

Yesterday I had some fun with the sequence-table key generator. I had
this fragment at the end of my Entity deployment plan.

  

  sequence
  reminder
  1

  

I know, I should increase my batch-size, but really I am only doing one
at a time. But that's not my problem. Why doesn't the key-generator
create the table if it doesn't already exist? It took me quite some time
to figure out that it was looking for a table with two columns, one
called 'name' and one called 'value'. Yeah, I know, it's pretty easy to
guess it, but I couldn't find it documented. I'm sure I didn't look
everywhere, and could have looked in the source code to find the columns.

Once I created my table, the application started throwing exceptions
like crazy! It turned out the misleading 'Transaction already rolled
back' errors were because the record in the table didn't exist. I'm sure
it would be super easy to create the record if it wasn't already there,
and start the numbering at 1. I'm just so surprised it doesn't already
have this ability. I'm sure I'm missing something, right?

So, as far as I know, in order to get the key generator to work, I have
to create the sequence table:

create table sequence (name varchar(240) not null primary key, value
integer);

And then add the sequence key:

insert into sequence values ('reminder',1);

And then it'll go. Before that it just complains loudly and rolls back
my transaction.

What am I missing?

Cheers.

-Neal

Re: Key Generator Questions

2006-06-13 Thread Gianny Damour


Hi Neal,

Thanks for this feedabck. You are correct: it is pretty easy to write 
some initialization code to create a sequence table and insert a value. 
As a matter of fact, if you have a look to 
org.tranql.pkgenerator.SequenceTablePrimaryKeyGenerator.initSequenceTable() 
you can see that is is indeed super easy.


At some point, the sequence table was systematically initialized. As 
reported by GERONIMO-682 - "Automatic key generators too restrictive" 
(http://issues.apache.org/jira/browse/GERONIMO-682), this approach was 
not considered as appropriate. I think that when the primary key 
generators have been refactored this problem has been partially fixed.


Could you please open a JIRA to track the need of an optional element 
enabling sequence table generation?


Thanks,
Gianny

Neal Sanche wrote:


Hi All,

Yesterday I had some fun with the sequence-table key generator. I had 
this fragment at the end of my Entity deployment plan.


 
   
 sequence
 reminder
 1
   
 

I know, I should increase my batch-size, but really I am only doing 
one at a time. But that's not my problem. Why doesn't the 
key-generator create the table if it doesn't already exist? It took me 
quite some time to figure out that it was looking for a table with two 
columns, one called 'name' and one called 'value'. Yeah, I know, it's 
pretty easy to guess it, but I couldn't find it documented. I'm sure I 
didn't look everywhere, and could have looked in the source code to 
find the columns.


Once I created my table, the application started throwing exceptions 
like crazy! It turned out the misleading 'Transaction already rolled 
back' errors were because the record in the table didn't exist. I'm 
sure it would be super easy to create the record if it wasn't already 
there, and start the numbering at 1. I'm just so surprised it doesn't 
already have this ability. I'm sure I'm missing something, right?


So, as far as I know, in order to get the key generator to work, I 
have to create the sequence table:


create table sequence (name varchar(240) not null primary key, value 
integer);


And then add the sequence key:

insert into sequence values ('reminder',1);

And then it'll go. Before that it just complains loudly and rolls back 
my transaction.


What am I missing?

Cheers.

-Neal

[jira] Commented: (GERONIMO-2093) Console database pool always gets NPE on deploy

2006-06-13 Thread Mario Ruebsam (JIRA)

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

Mario Ruebsam commented on GERONIMO-2093:
-

The NPE appeared in 1.1-20060607.
The problem is fixed in 1.1-rc1. No more NPE while displaying or saving 
deployment plan.

> Console database pool always gets NPE on deploy
> ---
>
>  Key: GERONIMO-2093
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2093
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
>  Environment: Release Candidate 6/7/2006
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Blocker
>  Fix For: 1.1

>
> Reported on the user mailing list:
> 09:40:40,375 ERROR [DatabasePoolPortlet] Unable to save connection pool
> java.lang.NullPointerException
>at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876)
>at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338)
> ...
> Looks like perhaps rarFile is null?

-- 
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: Linking error for compiling CMS code

2006-06-13 Thread Mittler, Nathan

CMS is dependent on UNIX pthreads, so in your linker options you'll need


-lpthread


-Original Message-
From: Arshad Ahamad [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 13, 2006 7:26 AM
To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED]
Subject: Linking error for compiling CMS code

Hi all, 

   I am compiling cmd code on SuSe(Linux machine-> i686-suse-linux, 
version 2.6.13-15.8-default) , I am able to create the object file of
this 
code but when I make a executable file it gives the following error 

/stomp/StompTransport.cpp:147: undefined reference to 
`pthreadpthread_join
collect2: ld returned 1 exit status 

Please help me


 Thanks in advance


 Regards
 Arashad Ahamad

Linking error for compiling CMS code

2006-06-13 Thread Arshad Ahamad

Hi all, 

  I am compiling cmd code on SuSe(Linux machine-> i686-suse-linux, 
version 2.6.13-15.8-default) , I am able to create the object file of this 
code but when I make a executable file it gives the following error 

/stomp/StompTransport.cpp:147: undefined reference to 
`pthreadpthread_join
collect2: ld returned 1 exit status 


   Please help me


Thanks in advance


Regards
Arashad Ahamad

Re: [Vote] 1.1-rc1 Now Available

2006-06-13 Thread Rodent of Unusual Size


Also mentioned in another thread:

Two things:

1. Releases can't be vetoed; they use a consensual vote,
   not the '3 +1s and 0 -1s' mechanism.
2. Since a release bears the Apache name, releasing software
   is an official act of the Foundation, and as a consequence
   only members of the PMC have binding votes.  All others
   are advisory.
--
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist  http://Apache-Server.Com/

"Millennium hand and shrimp!"

Re: [VOTE] Release XBean 2.4

2006-06-13 Thread Rodent of Unusual Size


Guillaume Nodet wrote:

I have pushed XBean 2.4 binaries in a private repo for review.
They are available at
   http://people.apache.org/~gnodet/xbean-2.4/m1/org.apache.xbean 


   http://people.apache.org/~gnodet/xbean-2.4/m2/org/apache/xbean

[ ] +1 Release the binary as XBean 2.4
[ ] -1 Veto the release (provide specific comments)


Two things:

1. Releases can't be vetoed; they use a consensual vote,
   not the '3 +1s and 0 -1s' mechanism.
2. Since a release bears the Apache name, releasing software
   is an official act of the Foundation, and as a consequence
   only members of the PMC have binding votes.  All others
   are advisory.
--
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist  http://Apache-Server.Com/

"Millennium hand and shrimp!"

Re: rc1 Status and Next Steps